Client and Server Applications
Option 1 is a good choice for very simple protocols. It's easy to implement and it
doesn't require any special handling of the received stream. However, it requires
the setting up and tearing down of a socket for every message, and this can impact
performance when a server is handling many messages at once.
Option 2 is again simple to implement, but it only makes efficient use of the network
when our data comes in neat, fixed-length blocks. For example in a chat server the
message lengths are variable, so we will have to use a special character, such as the
null byte, to pad messages to the block size. This only works where we know for sure
that the padding character will never appear in the actual message data. There is also
the additional issue of how to handle messages longer than the block length.
Option 3 is usually considered as one of the best approaches. Although it can
be more complex to code than the other options, the implementations are still
reasonably straightforward, and it makes efficient use of bandwidth. The overhead
imposed by including the length of each message is usually minimal as compared
to the message length. It also avoids the need for any additional processing of the
received data, which may be needed by certain implementations of option 4.
Option 4 is the most bandwidth-efficient option, and is a good choice when we know
that only a limited set of characters, such as the ASCII alphanumeric characters, will
be used in messages. If this is the case, then we can choose a delimiter character,
such as the null byte, which will never appear in the message data, and then the
received data can be easily broken into messages as this character is encountered.
Implementations are usually simpler than option 3. Although it is possible to employ
this method for arbitrary data, that is, where the delimiter could also appear as a
valid character in a message, this requires the use of character escaping, which needs
an additional round of processing of the data. Hence in these situations, it's usually
simpler to use length-prefixing.
For our echo and chat applications, we'll be using the UTF-8 character set to send
messages. The null byte isn't used in any character in UTF-8 except for the null byte
itself, so it makes a good delimiter. Thus, we'll be using method 4 with the null byte
as the delimiter to frame our messages.
So, our rule number 8 will become:
Messages will be encoded in the UTF-8 character set for transmission, and they
will be terminated by the null byte.Now, let's write our echo programs.