I'm prototyping some single machine, single user software with a client-server model; the first client for which will be a CLI, but I expect a (local) webapp/GUI to come later.

For the CLI, I'd like to be able to either connect to an existing server instance to run whatever commands, or start one up for the duration of the command if it doesn't exist. The GUI would start a longer-running server, i.e. until it was closed.

What are the good options for messaging (transport) between client(s) and server here?

Unix sockets? HTTP? AMQP? ZeroMQ? Something else?

I'd like to use protobuf/cap'n proto, so it's the transport I'm asking about really - unless there's some all in one solution to recommend perhaps. I'd also like not to rule Windows support out by this decision.

  • 2
    The close request seems not justified: OP doesn't ask to find resources, but asks about which kind of communication protocol is the most suitable.
    – Christophe
    Commented Sep 9, 2018 at 13:04

1 Answer 1


You compare very different kind of communication protocols:

  • POSIX Sockets are available on all TCP/IP enabled platforms (e.g. linux, windows) and not only unix. It's a flexible communication protocol. It offers among other possibilities, reliable bidirectional streams or packets. It suits your needs.
    But it's low level (level 5 of the OSI model), so you'll have to ensure the security (level 6) and to take care of the assembly/disasembly of your variable length messages (level 7).
  • HTTP(S) is request/response, so very well suited for your client/server purpose (level 7 of OSI, so security and packaging of data is already in). There is a small overhead for the header data, but the body can be binary protobuf if you want. Security is handled by the lower levels. However, http is connectionless, so you'll have to organize the session management.
  • Message queues (aka AMQP protocol, ZeroMQ library) are not meant to be bidirectional by nature. So it's fine to send commands and data to the server, but how to send a response with data back to client ? Via another queue ? So I don't think it's the best approach for your use case.

If your protocol is for a system running on a local network, for example for learning purpose, the sockets would be a very good start. If the scope is larger, http(s) could be more appropriate.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.