a stateful internet ?

Errors-To: listmaster@www0.cern.ch
Date: Thu, 16 Jun 1994 15:36:03 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406161305.AA23795@dxmint.cern.ch>
Errors-To: listmaster@www0.cern.ch
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: a stateful internet ?
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Jon P. Knight writes @ Thu, 16 Jun 1994 10:24:18 +0200

>On Wed, 15 Jun 1994, Alan (Miburi-san) Wexelblat wrote:
>> What's the advantage of a state-less protocol?  It makes server writing
>> easier.  But that throws the burden off onto clients, onto the net, and onto
>> information providers.  You don't solve problems by shifting them around.

>But you do stop the servers from tying up resources waiting for clients to
>make the next move in a stateful protocol.  On a heavily used server,
>having the connections die between client requests can be a big win.  IMHO
>HTTP has been successful partly because it is easy to implement a basic
>server and it doesn't rapidly overload the machine.  If people feel they
>need a stateful protocol, I think they should come up with something new
>rather than subvert the statelessness of HTTP.

Pardon my ignorance but isn't one enormous advantage of stateless protocols
a handshake free internet?  Other comms systems are burdened by the
requirement on the client and the server to constantly verify each other's
continuing connection.  If stateful protocols (ftp aside) start to
proliferate on the internet, along with the explosion BLOB transfers from
Mosaic clients, then isn't there a danger of a massive and permanent traffic

I watched the start of this discussion with the CMPlayer request and I
agree with whoever said that it is the client's responsibility to ensure
sufficient local storage space to process whatever is requested.

Al. <-:< (zpalastair@grid.unl.ac.uk)