[ProgSoc] Thought for the day

Michael F mike_net at exemail.com.au
Sat Nov 7 17:50:06 EST 2009


On Sat, Nov 7, 2009 at 4:23 PM, John Elliot <jj5 at jj5.net> wrote:

>
> Michael F wrote:
> > I think this confuses the application of the protocol with the abstract
> > concept of the protocol itself, however.
>
> You can keep within the bounds of "the abstract concept of the protocol
> itself" by assuming that it applies to at least two existing parties and
> still argue that the communication is stateful (or stateless).
>
> A protocol for communication  describes the rules under which information
can be communicated, or what procedures the parties involved need to carry
out to communicate to each other. It exists completely independent of the
actual information communicated. Whether or not communicating the same
thing  twice will result is the receiving party doing the same thing twice
is, the way I see it, irrelevant in a discussion of the protocol itself.
Indeed the communication and the information exchanged may be stateful, but
this says nothing about the protocol used to exchange that information.

>> The term 'stateless' as applied to HTTP is neither correct nor useful.
> >
> > I would argue that any protocol which hides the state of the application
> > isn't useful as there would be no need for communication to take place if
> > the state of the applicaiton didn't change and/or could be determined
> before
> > hand.
>
> There are instances I can think of where the application layer is
> properly 'stateless'. For instance say we had a web-based charting
> application that took an array of numbers as input and turned those into
> a PNG of a bar-chart representation of those numbers. The result of a
> single HTTP GET request to such an application would be fully determined
> by the content of the request (the input array of numbers would go in
> the query string of a URL), and as no state external to the request is
> required in generating output both the request itself and the protocol
> it uses could be said to be 'stateless'. However, when I take a request
> and dereference a component of its content to get at some other state
> then it's no longer possible to claim statelessness.
>
> Even in this example HTTP wouldn't be considered stateless by your use of
the term. The server took the URL and dereferenced it to find the code which
should be executed using the parameters in the query string. It is quite
possible to change that code, in which case the response of the server would
change. The process of converting a request into a response is dependent on
the state of the server.


> > This would mean that HTTP is only useful because it possesses your
> > statefulness property.
>
> No, HTTP could still be stateless and useful (in some circumstances),
> it's just that many HTTP requests aren't stateless in that they are made
> based on the results of previous requests (i.e. what's known about the
> previous state of the server).
>
> If the process and data involved in converting a request into a response
doesn't change then there is no reason to have to communicate with the
server, except to obtain that information for the first time. HTTP isn't
nessisary for that. Once the process and data (which are really about the
same thing) have been obtained the client could apply the process itself
without having to communicate with the server ever again.


> > The term 'stateless' when applied to a communication protocol is
> generally
> > taken to mean that in order to communicate using the protocol those
> > communicating do not need to be aware of any previous communications
> between
> > each other.
>
> Right, and in this case the server needed to be aware of the change of
> state to the file permissions that occurred between two identical requests.
>
> The fact of the matter is that the server didn't need to be aware of the
state of file permissions to respond to the client, nor did the client need
to know the state of file permissions to make the request. Both the client
and server were able to communicate in spite of that (even though the
information communicated changed).
In contrast if you don't know the sequence number for the next TCP segment
you can't communicate to the server at all. This is what most people mean
when they say a protocol is stateful, you have to know about previous
communication (the ack number) in order to communicate with the server. It
says nothing about the actual information communicated using the protocol
and what to expect from the responding party.


> > You could take an alternate definition in which the
> > stateful/less property of a protocol is dependent on the actual data sent
> > and received over it, but such a definition would, as you said, lead the
> > terms stateful and stateless to be useless.
>
> It wouldn't make the terms useless at all. It would make them correct!
>
> Wouldn't it be correct to say that HTTP is a stateless protocol over which
stateful communication can take place?
If you were to say that a stateless protocol is one which only allows
stateless communication then I think you would find very few useful
stateless protocols. Futhurmore such protocols would only be useful for
obtaining information once, as the response for any given request would
never change. There would be, therefore, a limit to the use of such a
protocol as once all of the information required by an application had been
obtained there would no longer be any reason to communicate.

-Michael F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://progsoc.org/pipermail/progsoc/attachments/20091107/43b9ed4f/attachment-0001.htm 


More information about the Progsoc mailing list