[zeromq-dev] ZMQ reconnect/ephemeral ports
wallstprog at gmail.com
Sat Sep 2 00:03:48 CEST 2017
Thanks Luca! That was very helpful.
Although it leads to a couple of other questions:
- Can I assume that a ZMQ disconnect of a tcp endpoint would only occur if the underlying TCP socket is closed by the OS? Or are there conditions in which ZMQ will proactively disconnect the TCP socket and try to reconnect?
- I see that there is a sockopt (ZMQ_RECONNECT_IVL) that can be set to -1 to disable reconnection entirely. In my case, the the “data” socket pair will *always* connect to an ephemeral port, so I *never* want to reconnect. Would this be a reasonable option in my case, do you think?
- Would there be any interest in a patch that would disable reconnects (controlled by sockopt) for ephemeral ports only? I’m guessing that reconnecting mostly makes sense with well-known ports, so something like this may be of general interest?
> On Sep 1, 2017, at 5:30 PM, Luca Boccassi <luca.boccassi at gmail.com> wrote:
> On Fri, 2017-09-01 at 16:59 -0400, Bill Torpey wrote:
>> 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
>> 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
>> 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
>> - 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?
> The ZMTP handshake would fail, so yes.
>> - 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
> Depends on how you handle it in your application. If you have security
> concerns, then use CURVE with authentication so that only authorised
> peers can connect.
>> 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 ;-)
> That's a common pattern. But the application needs to handle unexpected
> data somewhat gracefully. What that means is entirely up to the
> application - as far as the library is concerned, if the handshake
> succeeds then it's all good (hence the use case for CURVE).
>> Any guidance, hints or tips would be much appreciated -- thanks in
> Kind regards,
> Luca Boccassi_______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev <https://lists.zeromq.org/mailman/listinfo/zeromq-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev