RE: Sticky stuff.

Phill -- you are talking about a different granularity of connection
multiplexing than the draft intended. It was a bad choice of
terminology, and I'm going to change it in the next rev.

A better analogy is "serial reuse" -- the proxy will keep a persistent
connection to a server, using for one client at a time, until it goes
idle for "long enough" and the proxy closes it. It wouldn't actually
ever use it for multiple outstanding requests for different clients.

>----------
>From: 	hallam@Etna.ai.mit.edu[SMTP:hallam@Etna.ai.mit.edu]
>Sent: 	Friday, August 09, 1996 11:09 AM
>To: 	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Cc: 	hallam@Etna.ai.mit.edu
>Subject: 	Re: Sticky stuff.  
>
>
>>The normal operation for a group-to-organizational proxy or a
>>regional-to-national proxy will be one of interleaved requests on
>>a small number of persistent connections, with the possiblility of
>>high performance requirements on those connections due to the bursty
>>nature of web traffic.  I do not consider that to be "typical",
>>but it is part of the design of HTTP/1.1 and cannot be ignored without
>>breaking the protocol.  Such applications are not typical today, but
>>they will be typical in the future (the near future given the rate
>>at which demand is approaching network bandwidth capacity).
>
>I really object to the use of this language. To my knowledge
>nobody has every produced such a server. I suspect that very
>few such servers if any will ever be built.
>
>I don't regard it as part of the "design" of HTTP/1.1 it is
>simply a side effect of other considerations. At this point I
>am interested in how far we can travel from our existing installed
>base to where it would be nice to be. I don't think it is helpfull
>to start from a theoretical projection from the existing protocol
>and start complaining that software that nobody has written and
>might never be written will break.
>
>If we want to support such a mode then lets do it in a principled
>way. It would be a simple matter for such a proxy to add in stream
>ids.
>
>Even more to the point such a convergence/multiplexing protocol
>will suck eggs performance wise unless something like Jim 'n
>Henrik's MUX layer is implemented. The requests and responses
>will have to be serialized. That does not appear to me to be a 
>good thing!
>
>
>>> I would like to suggest that we consider making HTTP a non-idempotent
>>> protocol and introduce methods to provide transaction semantics.
>>
>>HTTP is already non-idempotent (POST). Do you mean stateful?
>
>Actually as implemented GET is non-idempotent. And idempotence is
>mathematically equivalent to statefull. I would like the protocol
>to admit what it has been for three years and drop the idempotence
>language in favour of "non-contractual" which is closer to what
>Tim actually meant. 
>
>[transaction semantics stuff]
>
>>However, this is no longer relevant to the subject under discussion.
>
>I think the general topic we should be addressing is the space of 
>TCP/IP improvements that we can make.
>
>I personally favour functional improvements over performance tweaks.
>The Web lets me do very little of what it was originally meant to
>provide. 1.1 was slated as the performance "save the net edition".
>I think that we should catch up on the backlog of making the Web
>a usefull tool and address functional limitations.
>
>
>		Phill
>
>
>
>		Phill
>
>
>
>
>

Received on Friday, 9 August 1996 11:51:59 UTC