W3C home > Mailing lists > Public > www-ws@w3.org > November 2004

RE: Stateful Web Services...

From: David Orchard <dorchard@bea.com>
Date: Wed, 3 Nov 2004 16:19:25 -0800
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF0B782CF8@ussjex01.amer.bea.com>
To: "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>, <www-ws@w3.org>

That doesn't jive with why stateful services that are pinned at a
particular node still perform substantially better than
stateful/connection-oriented protocols.  And I don't know why it's
hard/impossible to move tpc connections from one node to another.  I've
meant to look into this for some time but never gotten around to it.
Kind of like the air I breathe analogies.


> -----Original Message-----
> From: Savas Parastatidis [mailto:Savas.Parastatidis@newcastle.ac.uk]
> Sent: Wednesday, November 03, 2004 4:12 PM
> To: David Orchard; www-ws@w3.org
> Subject: RE: Stateful Web Services...
> Dave,
> > Even your quotation of stateless interaction doesn't make it clear.
> Roy
> > has said that a cookie with a session id is a stateless interaction
> a
> > stateful service.  This differs from something like ftp in which the
> > connection contains part of the state.  One way that http scales
> better
> > than ftp is because http can tear down the connections because of
> > stateless interactions, and connections are very costly to maintain
> open
> > for potentially large numbers of clients.
> >
> > Now as to what's going on at the plumbing level in tcp/ip stacks I
> > haven't a clue about.  Why ftp creating and keeping large #s of
> > connections open with state being embodied in the ftp/tcp connection
> is
> > soo much more costly and less scalable than an http stateless tcp
> > connection is a mystery to me.  Especially when software can do SSL
> > connections that can be fairly chatty and bandwidth consuming.
> Isn't it the case that because of the stateless connections one can
> the processing of the requests and achieve higher levels of
> even if more bandwidth is consumed?
> .savas.
Received on Thursday, 4 November 2004 00:19:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:11 UTC