[zeromq-dev] ZMQ reconnect/ephemeral ports

Luca Boccassi luca.boccassi at gmail.com
Fri Sep 1 23:30:18 CEST 2017

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
> 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?

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
> expects?

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
> advance!

Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20170901/4f94464a/attachment.sig>

More information about the zeromq-dev mailing list