Net transfers stall, but appear when cancelled

[Julian Vrieslander]

Very often I find myself waiting for a web page to display, or for a
usenet news article to display. The window is blank, and the connection
appears to be stalled. But if I cancel the connection (command-period),
the window displays most or all of the data.

A possibly related issue: I start to load a web page (clicking a link)
or a news article (double-clicking a header) and nothing happens for
several seconds or several minutes. I cancel the connection and try the
same thing again. This time it transfers immediately.

I have seen this on several Macs running various OS versions and
clients, on dialup and broadband connections. Currently I am running
Mac OS X 10.2.6, Internet Explorer 5.2.2, Safari 1.0, MT-Newswatcher
3.3b1.

Can someone explain what is happening here? Is this an indication of
something broken or misconfigured in the client computer? Something
flaky in the upstream stuff? Overloaded servers? Or just normal
fluctuations in net congestion?

If the problem is upstream, why do I often see a full window of data
when I force a cancellation of the connection? Was my client stalled
waiting for some sort of acknowledgment that the connection terminated
normally?

--
Julian Vrieslander

[Matthew Kirkcaldie]

In article
<julianvREMOVE_THIS_PART-1F4488.23373115092003@news01.west.earthlink.net

>,

Julian Vrieslander <julianvREMOVE_THIS_PART@mindspring.com> wrote:

> If the problem is upstream, why do I often see a full window of data
> when I force a cancellation of the connection? Was my client stalled
> waiting for some sort of acknowledgment that the connection terminated
> normally?

Generally it's because it hasn't been able to download every element of
a page, and hence the final layout isn't known. When you cancel it, it
does a layout of the things it did receive. If you reload, it's often
only got one or two things left to receive, so it uses the local cache
for the rest and it's quicker.

Also the connections for the individual items may be active separately,
and one or more of them needs to be reset, holding up the whole bunch.
This is especially applicable if some items come from other servers,
e.g. an ad.

Cheers,

Matthew.

[Julian Vrieslander]

In article
<Matthew.Kirkcaldie-F9F392.17083316092003@seagoon.newcastle.edu.au>,
Matthew Kirkcaldie <Matthew.Kirkcaldie@newcastle.edu.au> wrote:

> In article
> <julianvREMOVE_THIS_PART-1F4488.23373115092003@news01.west.earthlink.net

> >,

> Julian Vrieslander <julianvREMOVE_THIS_PART@mindspring.com> wrote:
>

> > If the problem is upstream, why do I often see a full window of data
> > when I force a cancellation of the connection? Was my client stalled
> > waiting for some sort of acknowledgment that the connection terminated
> > normally?

>
> Generally it's because it hasn't been able to download every element of
> a page, and hence the final layout isn't known. When you cancel it, it
> does a layout of the things it did receive. If you reload, it's often
> only got one or two things left to receive, so it uses the local cache
> for the rest and it's quicker.
>
> Also the connections for the individual items may be active separately,
> and one or more of them needs to be reset, holding up the whole bunch.
> This is especially applicable if some items come from other servers,
> e.g. an ad.

The scenario you describe occurs in some of the cases I am describing.
But I also see a fair number where the connection is stalled at the
beginning, even if there is only one item coming from one server (like a
long page of text, or a single large graphic). I start the transfer,
and a throughput display (e.g., Net Monitor) shows the outgoing request,
but no incoming data. I cancel the connection, try again, and the
transfer starts and comes over quickly.

I guess there are probably several different causes for these stalls.

--
Julian Vrieslander

[sam grey]

In article
<julianvREMOVE_THIS_PART-C08A38.01101416092003@news01.west.earthl
ink.net>,
Julian Vrieslander <julianvREMOVE_THIS_PART@mindspring.com>
wrote:

> The scenario you describe occurs in some of the cases I am describing.
> But I also see a fair number where the connection is stalled at the
> beginning, even if there is only one item coming from one server (like a
> long page of text, or a single large graphic). I start the transfer,
> and a throughput display (e.g., Net Monitor) shows the outgoing request,
> but no incoming data. I cancel the connection, try again, and the
> transfer starts and comes over quickly.
>
> I guess there are probably several different causes for these stalls.

Yes. In the scenario you describe above, your connection attempt
to the web server may never have been successful in the first
place because of--who knows? some network problem. there are lots
of reasons why your http request would not receive a response. a
busy server, a broken fiber connection; the causes can be major
or minor, local or remote.

I assume that after a certain amount of time your connection will
time out. In any case, when you click again, you successfully
make the connection that time, and--ouila.

If it were my computer we're talking about, it would most likely
be an intermittant ISP problem. But it could be lots of stuff.