[ee122] The terminating characters

[Richard Schmidt]

The server should consider both requests (ending in CRLF) as individual
requests. Thus both are error-filled. Still, I think that the server should
observe that there is 2 messages in the buffer on one recv() from the same
fileDescriptor.

I think this aspect (however much complexity it adds and I haven't been able
to test it cause my messages aren't big enough... yet) adds to the
resilience of the server.

Imagine the client was automated and relayed requests coming from different
parts of the program. It would make sense to pack in the messages as tightly
as possible so that you aren't wasting packets on the tail ends of a
message. In that sense, having the server (and client) be able to identify
multiple messages in one recv() would be crucial.

However, I did put in a check saying (if there's only one end of message
here, and it's at the end of the recv() amount) then the server should close
the connection.

I think multple messages in one packet kind of defines the idea of TCP
packet streaming, but again, I haven't got messages that I'm able to stack
into a send().
Rick


On 9/22/07, Simon Tan <simtan at berkeley.edu> wrote:
>
> 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
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/ee122/attachments/20070922/b2fc4b28/attachment.html