Why use sockets instead of another application protocol?

Question

Another team at my company is starting a new project where a few entities will need to communicate across the network. I overheard that they were going to implement the communication layer by making entities send messages to each other via sockets.

I asked them why. Why not send over HTTP or XMPP? A discussion followed where my arguments in favor of using another estabilished protocol were, basically:

• not having to open/close streams.
• demultiplexing of messages is already implemented.
• passing parameters and values is easier (no need to create a micro-language to serialize values).

All this, however, was not enough to convince them. Some thought that "our messages are too small and simple, there's no need to add this complexity". Other just thought that this was plain rubbish.

I'd like to know from you your opinion on this subject. Do you consider using other application protocols to implement your communication layer on top of? Or do you prefer sending custom messages through sockets?

Answer 1

Those higher level protocols will still use sockets as their transport.

Answer 2

If you're shipping a small amount of data between two processes that already know and agree on a given way of doing things, using sockets is simpler and faster than implementing an HTTP server, parsing XML, and all that. In fact, since both sides agree on the format of the data and how it gets transferred, what you actually have is a custom application-layer protocol of sorts. Generic application-layer protocols like HTTP, and generic data formats like XML, were designed for interoperability, and aren't as necessary when you control both ends of the connection.

On top of all that, the HTTP server or whatever you use...would still be using sockets to communicate -- you just don't have to deal with them as much.

Answer 3

There are many criteria to consider. You aren't explaining many of them for the use case in question. To mention but a few

1. Frequency of messages
2. Size of messages
3. Content of messages
4. Amount of peers
5. Peer location
6. Platform
7. Performance requirements

Your point seems to be: why use a lower level protocol if there are ready made higher level solutions?

In general you might prefer to build directly on top a lower level network protocol instead of using a well known higher level protocol if you need very high throughput or very low latency.

Also, platform considerations might come into play, if the app is simple and the platform does not provide libraries to produce and consume the higher level protocols it might be faster/easier to build directly on top of the lower level the platform does provide.

In addition, markup languages tend to be very, very wasteful and are designed to ease interoperability, which might not be the best option for an application where the need to interoperate with different processes/machines doesn't exist.

Finally, solutions are already available to serialize content that can be directly sent over sockets without the overhead of a higher level protocol. See, for example, protobuf.

Oh, and multiplexing is handled by the OS TCP/IP stack.