[ee122] The terminating characters

[Simon Tan]

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  
> chunks
> 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.
>
> 		Vern
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122



-- 
~Simon Tan >> undergraduate at UC Berkeley
Source: simtan at berkeley.edu