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 _______________________________________________ cabal-devel mailing list [email protected] http://www.haskell.org/mailman/listinfo/cabal-devel
