I'm curious about how ZMQ handles re-connection. I understand that
re-connection is supposed to happen "automagically" under the covers, but that
poses an interesting question.
To make a long story short, the application I'm working on uses pub/sub sockets
over TCP. and works like follows:
At startup:
1. connects to a proxy/broker at a well-known address, using a pub/sub socket
pair ("discovery");
2. subscribes to a well-known topic using the "discovery" sub socket;
3. binds a different pub/sub socket pair ("data") and retrieves the actual
endpoints assigned;
4. publishes the "data" endpoints from step 3 on the "discovery" pub socket;
When the application receives a message on the "discovery" sub socket, it
connects the "data" socket pair to the endpoints specified in the "discovery"
message.
So far, this seems to be working relatively well, and allows the high-volume,
low-latency "data" messages to be sent/received directly between peers,
avoiding the extra hop caused by a proxy/broker connection. The discovery
messages use the proxy/broker, but since these are (very) low-volume the extra
hop doesn't matter. The use of the proxy also eliminates the "slow joiner"
problem that can happen with other configurations.
My question is what happens when one of the "data" peer sockets disconnects.
Since ZMQ (apparently) keeps trying to reconnect, what would prevent another
process from binding to the same ephemeral port?
- Can I assume that if the new application at that port is not a ZMQ
application, that the reconnect will (silently) fail, and continue to be
retried?
- What if the new application at that port *IS* a ZMQ application? Would the
reconnect succeed? And if so, what would happen if it's a *DIFFERENT* ZMQ
application, and the messages that it's sending/receiving don't match what the
original application expects?
It's reasonable for the application to publish a disconnect message when it
terminates normally, and the connected peers can disconnect that endpoint.
But, applications don't always terminate normally ;-)
Any guidance, hints or tips would be much appreciated -- thanks in advance!
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
