[zeromq-dev] Zeromq behaviour on tcp reconnection, and socket IDs

[Tom Quarendon]

Hi,
I’m trying to get clear in my mind how the reconnection logic works in zeromq. It doesn’t seem to be explained anywhere that I can find, but apologies if I’ve missed something.

I think that the behaviour must be something like follows. I’m considering “request/reply” flows here, don’t know whether the situation is different for pub/sub types, haven’t considered those yet. I’m also specifically considering tcp, but I guess ipc would be the same (being another disconnected transport in zeromq).

The “client” (being the one who connects) will attempt to reconnect the tcp socket when it has a message in the output buffer that it needs to send. The fact that the connection is lost doesn’t affect the output buffer, if I’ve done a zmq_msg_send that message won’t be lost inside zmq if the tcp connection is lost. Zeromq just tried to remake the connection, and once it has it can send the next message on the output buffer. The client CAN reconnect, because it did the original connection.

The “client” will also attempt to reconnect if it does a recv and the connection is broken. Again, it CAN connect. This doesn’t affect the buffers in which zeromq holds the incoming messages that it reads from the socket before they get passed to the application. Once a message is received from the tcp socket and put on the internal buffers, it isn’t lost just because the socket needs reconnecting.

If the “server” detects a lost connection, it just closes down the socket, throws away the buffers and so on. The server CAN’T initiate a reconnect, it wouldn’t know where to connect to. In an environment where clients come and go frequently, say, in a public Wi-Fi environment, it would soon run out of resources otherwise. Since there’s nothing it can use to correlate a client reconnecting (the source port may be different, the IP address may have even changed), there’s nothing it could usefully do with the messages anyway, outbound ones especially (possibly it could keep the inbound queue and throw that away once empty). When the client reconnects, then as far as zeromq is concerned, it’s just another new connection.

The client setting an identity on the socket would allow the *application* code in the server to correlate messages, to tell that these two apparently unrelated connections are actually from the same source, but essentially means nothing to zeromq itself.

Is that a reasonable description, or do I have it wrong somewhere?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160209/a41ff3e9/attachment.htm>