On Sun, 2009-01-18 at 12:54 +0900, Curt Sampson wrote:
On 2009-01-17 17:16 +0000 (Sat), Duncan Coutts wrote:
On Wed, 2009-01-14 at 00:09 +0900, Curt Sampson wrote:
..parallel downloads are a very happy thing; in some circumstances I can run a dozen downloads in parallel, without any individual one being slower than it would be running alone.
Presumably to different servers though right?
No; to a single server. There still appear to be a lot of TCP implementations out there not supporting the extensions necessary to increase window size beyond 64K, meaning that at any time only 64K of unacknowledged data can be outstanding on the connection. For me, a 250 ms. round-trip-time (RTT) is not unusual, meaning that the minimum amount of time between the server sending a segment and getting my client's acknowledgement of receipt is 250 ms. That means that, no matter how much bandwidth is available, I'll never see more than 256 KB/sec, or so, which is a small fraction (1/40th) of the available bandwidth between me and a server in the US with at least a 100 Mbps connection.
I was also under the impression that most web servers kind of frowned on more than one or two connections from the same client and some would take active measures to prevent it.
Not that I'm aware of. Most have this capability, and some people chose to use it when they it solves a problem for them, but I haven't found it to be that terribly common.
And of course there's also the case where the files one downloads are on different servers, either because the one "server" from which you're downloading is actually a cluster (a common case with larger sites) or because the things your downloading are actually hosted by different entities.
Fair enough. I'm rather jealous. My ADSL is only 0.5Mbit/s :-( So we'd need to establish multiple Network.HTTP.Browser sessions (though with a way to control the maximum number of them for people with DSL like mine). Another thing to bear in mind for the redesign of the cabal-install download component. http://hackage.haskell.org/trac/hackage/ticket/448 Duncan