W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

RE: Persistent connections: aborting requests in progress.

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
Message-Id: <Pine.SOL.3.91.950911201305.2009A-100000@chivalry>
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. 

Received on Monday, 11 September 1995 20:28:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC