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