Quote Originally Posted by MikeAThon View Post
Another thing to be aware of, when using TCP:

TCP is a stream-based protocol, which means that it simply sends a stream of bytes and receives a stream of bytes, which can be received in chunks as short as a single byte. It's up to you, as the application-writer, to give meaning to the stream of bytes. If you want the stream of bytes to represent a NULL-terminated Unicode text string, you need to code the architecture to realize this effect.

The important part is that calls to send and receive are not somehow magically corellated. A single call to send() 100 bytes will not automatically result in a single call to recv() that receives exactly 100 bytes. In the toy application that you are using now, in which the client and server are probably running on the same machine, you probably get that result accidentally by chance (since the loopback mechanism skips the step of writing bits onto the real-world network wire). But once you implement your code on the Internet, you will immediately see situations where one peer calls send() with 100 bytes, but the other peer only gets a few of those bytes in a single call to recv().

When you see this happen, you might think that data is being lost, but in fact the data is there. Some or all of it will be received the next time that recv() is called.

So, what does all this mean? It means that you, as the application-write, must impose an application-specific protocol to give meaning to the stream of bytes.

One commonly-used protocol with strings is to pre-pend each sending of a string with an integer that represents the count of characters being sent. Armed with that knowledge, the recipient will know exactly how many characters to process before concluding that the end of the string has been encountered.

Mike
This is so enlightful and I really appreciate it.