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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
