2 added 416 characters in body
source | link

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 packetpackets exchange. It suits your needs. But
    But it's low level (level 5 of the OSI model), so youyou'll have to ensure the security (level 6) and to take care of properly writingthe assembly/disasembly of your variable length messages, and of course, you have to ensure the security(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 thea 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.

  • 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 packet exchange. It suits your needs. But it's low level, so you have to take care of properly writing your variable length messages, and of course, you have to ensure the security.
  • HTTP(S) is request/response, so very well suited for your client/server purpose. 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, ZeroMQ) are not bidirectional. So it's fine to send commands and data to the server, but how to send the data back to client ? Via another queue ? So I don't think it's the best approach for your use case.

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.

1
source | link

  • 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 packet exchange. It suits your needs. But it's low level, so you have to take care of properly writing your variable length messages, and of course, you have to ensure the security.
  • HTTP(S) is request/response, so very well suited for your client/server purpose. 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, ZeroMQ) are not bidirectional. So it's fine to send commands and data to the server, but how to send the data back to client ? Via another queue ? So I don't think it's the best approach for your use case.