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
> [email protected]
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

_______________________________________________
zeromq-dev mailing list
[email protected]
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to