In a previous episode Phil Howard said... :: :: Marc Slemko writes: :: :: > Once again, HTTP/1.1 does _not_ allow multiplexing multiple transfers :: > simlultaneously in a single TCP connection. Multiple responses are :: > serialized. :: :: I think the confusion here is due to Paul's use of the term "serial :: multiplexing" where he qualified it with "serial" to indicate that :: one-at-a-time situation. When I read it I wasn't sure if "serial" :: meant to be that or meant to describe a kind of multiplexing over a :: serial stream. But given the HTTP 1.1 that I knew had a persistent :: connection that allowed additional requests, I suspected that he was :: referring to this. But the term "multiplexing" by itself implies :: concurrency. While at the microsecond level it is one at a time, :: but each channel isn't completed in those short durations. My worry :: was that others might have assumed there was some new true multiplexing :: protocol for HTTP. I've not heard of one, but even I wondered of one :: I might have not heard of (and I don't keep track of all the protocols :: out there). At the risk of introducing meaningful background literature: ftp://ds.internic.net/rfc/rfc2068.txt I direct folks to 14.36.1 "Byte Ranges" which when interleaved with pipelined requests comes very close to achieving client-driven multiplexing that I'd suggest from a UI pov will behave much better than the multiple connections method (eliminating the cost of tcp congestion control but at the cost of some application protocol overhead). -P