> On Aug 11, 2015, at 3:16 PM, Chris Knipe <sav...@savage.za.org> wrote: > > Lastly, you're reading from a socket so there's no guarantee that > the buffer string is going to necessarily end at the termination > boundary. Perhaps the protocol guarantees that, but the socket > surely doesn't. You may need to look for that terminating > sequence in the middle of the buffer. > > > But isn't that exactly why we set things like autoflush(1) or $|=1? After > the data stream has been sent from the server (i.e. CRLF.CRLF) the server > stops transmitting data and waits for the next command, so there's no chance > that a second data stream may be received by the client socket, at least not > until the client socket issues a new command.
The TCP transmission protocol is not line-oriented, so, depending upon how the remote node has their socket configured, each buffer of data from the server could possibly contain multiple lines and may not end with a complete line. The packet containing the end of the partial line could be delayed or never arrive if the connection is broken. Transmit and receive are asynchronous, so can be going on simultaneously. Your application protocol may require the server to wait for a command from the client before resuming transmission of the next packet, but that is not required by the TCP protocol. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
