Do you know the protocols you're working with?

I never worked directly with the TCP protocol. As everyone with a CS degree I knew the 3-way handshake, it’s place in the OSI-layers and had an idea of the segment structure.

But then came the unexpected time where I needed to build up a service which communicates via TCP to another service and sends data to it.

For a successful implementation I needed to develop an application which follows a protocol over TCP.

So I needed to connect, send heartbeat messages and send messages in a specific format to a TCP endpoint.

After I got all things together I started the implementation and stumbled upon the problem that the receiver got a line break after every message. Like e.g.:

Message 1

Message 2

Message 3

Message 4

I searched nearly a whole day for the problem until I found the solution: The documentation stated the endpoint expects a new line after every message, so I added the newline character ‘\n’ after every message. Thinking of classes I rewrote the toString() method:

public String toString() {
    return String.format("%s\n", message);
}

But the TCP client library I used for this also added per default a newline (crlf) when data has been send.

So I didn’t get the things correctly together: I thought the new line marker was part of the message. Which was false. The custom protocol stated how every message needs to look like. The end of the send process should be marked by a new line, so that the receiver knew when to stop reading the message. And this is the responsibility of the communication protocol and not part of the message format.

Example: HTTP headers

Comparable things can happen when you implement an API. You surely know most of the existing HTTP codes, but a closer look at the headers can give you a little help in developing a faster application.

One thing that comes here into my mind is the If-Modified-Since header. Consuming this header on the server side and sending it on client side can help you to reduce bandwidth and make your application faster.

Also you won’t need to implement logic on client side with checks if the file changed.

To summarize it: Keeping an eye open on the protocol can help you sometimes in saving time, confusion and maybe also frustration