NetMQ / ZeroMQ network traffic
These days I was playing with NetMQ. It appeared immediately as extremely fast. This triggered my curiosity about the network traffic it generates. So I wrote a very simple client-server demo, using PushSocket and PullSocket, perhaps the simplest possible configuration. Then I used Wireshark to capture the network packets and analyze them. Source code available here: https://github.com/fhtino/stuff/tree/main/NetMQtests
NetMQ is the official porting to .NET of ZeroMQ, a high-performance asynchronous messaging library:
NetMQ extends the standard socket interfaces with features traditionally provided by specialized messaging middleware products. NetMQ sockets provide an abstraction of asynchronous message queues, multiple messaging patterns, message filtering (subscriptions), seamless access to multiple transport protocols, and more. (NetMQ documentation)
NetMQ uses the network very efficiently, with a very low overhead, implementing its own protocol ZMQ Protocol on top of TCP. Before starting to capture and analyze traffic with Wireshark, activate the “ZMQ Protocol” decoder in Wireshark, specifying the port number used by the demo, 7777 in this case. This allows Wireshark to recognize ZMQ messages and display their contents in a more readable format.
In the demo, the server opens a PullSocket and waits for messages, while the client opens a PushSocket and sends them. The server binds a socket to a specific TCP port (7777 in this example). When the client starts, it connects and begins sending messages. Below is the traffic between client and server when sending five messages, plus the details of one data packet.
If the server is down or unreachable, the client keeps trying to connect and will send messages as soon as the server becomes available. To reduce network traffic, multiple messages are automatically bundled into a single data packet. Below is the traffic when the client starts before the server, and then the server starts and receives the buffered messages.
We observe the same behavior when the server is up but suddenly becomes unreachable: the client stores messages in the output queue and keeps trying to send them.
If both client and server use CURVE encryption, the handshake phase is more complex: additional messages (HELLO, WELCOME, INITIATE, READY) are exchanged to establish the secure connection. Below is the traffic between client and server when sending five messages with encryption enabled.
