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

[Justin Karneges]

Sounds mostly right.

Indeed there is a queue per "known" ZeroMQ connection. For clients, this
means a queue is created the moment zmq_connect() is called and the
queue persists regardless of whether or not the underlying transport
(e.g. TCP) is actually connected. For servers, this means a queue only
exists while a client is connected and is destroyed afterwards. Note
that the ZeroMQ socket objects themselves only have queues in the
context of connections. If a ZeroMQ socket has three known connections,
then there are three queues. If it has no known connections, then there
are no queues. This is why writing to a server socket with no clients
connected to it may block, because there is no queue yet. The
ZMQ_IMMEDIATE option can be used to make clients only have queues when a
connection is established, similar to server behavior.

As for when underlying transport connections are made, it is my
understanding that this is done automatically regardless of whether
or not you try to write or read on the socket. So you should not need
to call recv to force a reconnect or anything, but I could be wrong
about this.

One gotcha to be aware of with reconnections is that ZeroMQ may not
detect a dead connection unless it has data to write. In this case,
sending data may induce a reconnect. However, this is not possible to do
with all socket types (e.g. PULL). Best to use ZMQ_TCP_KEEPALIVE if you
want to ensure all connections will get automatically repaired.

On Tue, Feb 9, 2016, at 05:46 AM, Tom Quarendon wrote:
> 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.


> _________________________________________________
> zeromq-dev mailing list zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160209/46a713ed/attachment.htm>