- From: Simon Spero <ses@tipper.oit.unc.edu>
- Date: Mon, 11 Sep 1995 20:24:45 -0700 (PDT)
- To: Paul Leach <paulle@microsoft.com>
- Cc: mogul@pa.dec.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Mon, 11 Sep 1995, Paul Leach wrote: > It also needs a way to interleave responses from the pipelined > requests, else long ones will delay shorter ones. Think about the > concurrent "progressive rendering" of multiple GIF and JPEG files that > currently is done using multiple connections, and what it would take to > do it with pipelining. Sounds like a good idea :-) This is the default transport strategy used for HTTP-NG. Each TCP connection is multiplexed using a very simple SCP (session control protocol). This sticks a 64 bit header in front of data packets containing 1 byte of control flags, 24 bits of session id, and 32 bits of packet length. Each data object uses its own channel, and data from multiple channels can be interleaved. > Well, if you can interleave responses from multiple outstanding > requests, particularly during the transmission of entity-bodies, that > means you can discriminate which request a particular blob of incoming > response data belongs to, and it would seem easy to reserve one > discriminant for "aborted". > This can work, and is the strategy used in HTTP-NG for cancels and suspends; however there are a few problems. The main problem is that due to the ordered delivery of TCP Messages, any outstanding requests must be parsed before you get to the cancel/suspend. A side problem is that any data that has been placed in the send buffer by the server still gets written, even if the data has been delivered. Simon
Received on Monday, 11 September 1995 20:28:25 UTC