[zeromq-dev] Detecting abandoned clients (ie, half closed sockets)

Chuck Price chuck at peloton-tech.com
Tue Jul 25 19:44:01 CEST 2017


Thanks Justin, I'll look into that.

-chuck

On Tue, Jul 25, 2017 at 8:48 AM Justin Karneges <justin at karneges.com> wrote:

> Hi Chuck,
>
> libzmq doesn't allow setting an activity timeout as far as I know, so the
> nearest way to solve this is with TCP keep alives. You can configure them
> using zmq_setsockopt and the ZMQ_TCP_KEEPALIVE* options. With TCP keep
> alives turned on, the TCP subsystem will close the socket if it doesn't
> receive special keep alive packets from the client after awhile. This
> ensures libzmq will always properly clean up the socket. If you're using
> PULL or SUB sockets this is essential.
>
> One issue to be aware is that TCP keep alives allegedly may not be
> supported by some mobile devices/networks. I've never done any
> investigation myself about this, it's just something I've heard. However, I
> don't think this actually matters too much. If the server is unable to
> receive keep alives from a client, then it'll just always timeout the
> client after awhile, forcing the client to reconnect. You could set a long
> keep alive timeout so this doesn't happen very often (which is already
> standard practice, the default on Linux is something like 4 hours).
>
> Hope that helps.
>
> Justin
>
> On Tue, Jul 25, 2017, at 06:35 AM, Chuck Price wrote:
>
> I have a service processing periodic messages (periodic could be every 1
> to 10 seconds or so per client) from mobile clients connecting over
> intermittent LTE connections. The server is using a PULL socket. It is
> written in Go, using goczmq.
>
> The communication is one way, no reply is ever sent to the client. There
> can be many clients per server. The connection is encrypted.
>
> The server only cares about the latest messages from the client. If the
> LTE connection drops, the client does not queue messages, but instead just
> eats the error and waits for connectivity to resume.
>
> On the server side, the result appears to be a socket (file descriptor)
> leak. When the client reconnects, the server side doesn't notice that the
> old connection is defunct, and doesn't have any way to destroy the socket.
> The server is running on Linux (Debian).
>
> Is there a way to track when a client connects to a PULL socket and record
> the socket? With some sort of hook like that, I could attach a timer and
> garbage collect abandoned sockets.
>
> Thanks,
>
> -chuck
>
> *_______________________________________________*
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20170725/cb73d38a/attachment.htm>


More information about the zeromq-dev mailing list