3 ms·

Strong recommendation for ZeroMQ as well. It's a thin layer on TCP, is very fast, offers bindings in many languages, and is fairly flexible as well. https://ze

by pkage 7y ago

Strong recommendation for ZeroMQ as well. It's a thin layer on TCP, is very fast, offers bindings in many languages, and is fairly flexible as well. https://zeromq.org/ https://zeromq.org/

nurettin 7y ago
especially when you use the router pattern on server side in order to have multiple sessions on the same socket.
- nerdponx 7y ago
  Got any references on the router pattern? I searched but came up with a lot of IT related articles.
  - nurettin 7y ago
    https://netmq.readthedocs.io/en/latest/router-dealer/ https://netmq.readthedocs.io/en/latest/router-dealer/
alfalfasprout 7y ago
ZeroMQ and its bindings are well-proven, extremely well written, and the ZeroMQ guide is a work of art. That said, the bindings are not created equal. We've seen some unreliability with the Java package even though the official C/C++ and Python bindings work perfectly (the Go package too).
hhas01 7y ago
Surprised article didn’t include this in its comparison. Seems an obvious contender.
- pjc50 7y ago
  Marketing, I guess: message queueing and RPC are conceptually quite different, although it looks like zeromq has a request-response mode designed for this.
excerionsforte 7y ago
I second this recommendation. I use MsgPack over ZeroMQ with a custom RPC protocol. Protobuf, Capn Proto, Flatbuffers are good serialization mechanisms as well. Can't wait until the new Socket Types are out of draft stage. I believe GRPC is pluggable so if one wanted to invest time in building a GRPC ZeroMQ Transport then that is a feasible route. GRPC bring really good RPC mechanisms to the table.
X-Istence 7y ago
The thin layer on TCP leaves a lot of things to be desired. Such as knowing if the other end has disappeared and won't ever come back. Last time I used ZeroMQ was ~7 months ago at my previous job, so maybe things have changed since then, but having to write hacks to see if the other side is still there or not is absolutely terrible. Also, the Python bindings did not like fork() without exec, which yes is bad and all, but is still something that is done every so often in real world large programs.

by pkage 7y ago

Strong recommendation for ZeroMQ as well. It's a thin layer on TCP, is very fast, offers bindings in many languages, and is fairly flexible as well. https://zeromq.org/ https://zeromq.org/

nurettin 7y ago

especially when you use the router pattern on server side in order to have multiple sessions on the same socket.

nerdponx 7y ago
Got any references on the router pattern? I searched but came up with a lot of IT related articles.
- nurettin 7y ago
  https://netmq.readthedocs.io/en/latest/router-dealer/ https://netmq.readthedocs.io/en/latest/router-dealer/

alfalfasprout 7y ago

ZeroMQ and its bindings are well-proven, extremely well written, and the ZeroMQ guide is a work of art. That said, the bindings are not created equal. We've seen some unreliability with the Java package even though the official C/C++ and Python bindings work perfectly (the Go package too).

hhas01 7y ago

Surprised article didn’t include this in its comparison. Seems an obvious contender.

pjc50 7y ago
Marketing, I guess: message queueing and RPC are conceptually quite different, although it looks like zeromq has a request-response mode designed for this.

excerionsforte 7y ago

I second this recommendation. I use MsgPack over ZeroMQ with a custom RPC protocol. Protobuf, Capn Proto, Flatbuffers are good serialization mechanisms as well. Can't wait until the new Socket Types are out of draft stage. I believe GRPC is pluggable so if one wanted to invest time in building a GRPC ZeroMQ Transport then that is a feasible route. GRPC bring really good RPC mechanisms to the table.

X-Istence 7y ago

The thin layer on TCP leaves a lot of things to be desired. Such as knowing if the other end has disappeared and won't ever come back. Last time I used ZeroMQ was ~7 months ago at my previous job, so maybe things have changed since then, but having to write hacks to see if the other side is still there or not is absolutely terrible. Also, the Python bindings did not like fork() without exec, which yes is bad and all, but is still something that is done every so often in real world large programs.