[ee122] The terminating characters
simtan at berkeley.edu
Sat Sep 22 18:39:58 PDT 2007
If this situation happens from the server -> client, as described, but the
server closes its connection when it is done (as we expect it should in
this project), the client should have no problem, right? It would just
echo whatever it got (messages A+B) to STDOUT and move on.
But what if this happens from client -> server? Granted, this is really
shouldn't be possible in this project (because each client sends only one
request then waits for a response before acting again), but let's think it
hypothetically does. Do we have to include logic in our server to handle
unusually streamed messages from a single client? An example would be:
* Server receives "GET / HTT". Client is obviously not done, so we wait
until the next select.
* Server receives "P/1.0
GET / HT". Server thinks: Hrm, there's a CRLF there; this should count as
a complete request. But there seems to be another request starting to
build up... should I save it and *not* close the connection with the
client after I process this? Or should I forget the extra stuff and close
the connection as I normally do?
I realize this is very similar to Richard Schmidt's question (in this same
thread). I would think to scan the message for the CRLF, move the extra
stuff to the front of the buffer, and not close the connection. But I
think that this goes against the idea that the server should always close
the connection after each 'request', thereby throwing away whatever else
was in the buffer. Also, I would think that if the server was lenient like
this, garbage could build up in the buffer and the server would never
close the connection. Please advise.
On Tue, 18 Sep 2007 15:16:47 -0700, Vern Paxson <vern at icir.org> wrote:
>> Is it possible for the server to somehow send an entire message and then
>> some of a possible next message to the client?
>> sent[2/3 A]
>> sent[1/3 A + 1/2 B]
>> sent[1/2 B]
> In general, yes. TCP can deliver in-sequence data in whatever sized
> it likes. This can be a source of nasty bugs, since it can be the case
> that only rarely does a message get split in an unanticipated way.
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
~Simon Tan >> undergraduate at UC Berkeley
Source: simtan at berkeley.edu
More information about the ee122