[zeromq-dev] Automatic reconnection, blessing or curse?

[Pieter Hintjens]

ZeroMQ does indeed hide some things which we're used to seeing with TCP.

Even with TCP, if you want to maintain a connection for any length of
time, you need heartbeating. Otherwise you will hit cases where TCP
reports no error, yet the connection is effectively dead.

We don't usually use REQ/REP in practice. Any realistic client-server
work runs over DEALER/ROUTER.

-Pieter

On Tue, Sep 9, 2014 at 11:37 AM, Tom Quarendon
<tom.quarendon at teamwpc.co.uk> wrote:
> I’m trying to get a handle on zeroMQ, and the when I read chapter 4 of the
> guide, thing I keep thinking is “isn’t all that complexity just a by-product
> of the fact that sockets automatically reconnect after failure”?
>
>
>
> I want to do a very simple RPC application between two endpoints. Let’s say
> I want to something a bit like SSH or SFTP (it’s on my mind and I’m trying
> to understand whether zeroMQ would be a good fit for such an application).
> I can do this in raw TCP fairly easily, or at least I think I can, and if
> the connection goes down, then any attempt to read or write from the socket
> gives an error (the socket can survive the disconnection if you don’t
> actually try to send any data), so I know when either the server process
> crashes, the client crashes or the network cable gets unplugged while I’m
> trying to send traffic.
>
>
>
> Now in zeroMQ, using REQ/REP in a simplistic fashion, a number of things
> might happen. If the network cable is unplugged, then either the client will
> be unaware (if control is with it, that is it’s not waiting for a response),
> which is probably good, or the client will hang forever, definitely bad.
> Similarly if the server crashes when processing a request, the client will
> hang forever. If the client crashes, the server will never know.
>
> So you have to get into complications of polling the socket, applying
> timeouts, performing heart beating, adding serial numbers and retrying
> requests and so on, really to get round the fact that the connection will be
> automatically reconnected if the network is interrupted. Once you’ve done
> all of those things, how is what you end up with better than plain TCP/IP?
>
>
>
> So I suppose my question is, why is this a good idea? Is TCP actually less
> reliable than I think it is? Do I just not understand TCP enough? Am I just
> trying to think about zeroMQ too much like normal sockets? Maybe zeroMQ is
> just not appropriate for an application such as an SFTP server?
>
>
>
> Thanks.
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>