[zeromq-dev] cleaning up TCP sockets

[Doron Somech]

what about adding another monitor event called socket identified, the event
will include the identity of the remote socket and the file descriptor
(socket handle), now the developer will be able to manage a dictionary of
identities to file descriptor, in case the system recognize dead client it
close the file descriptor of that identity and freeing the resource for
that identity.

On Tue, Mar 26, 2013 at 4:14 PM, Joel Lauener <Joel.Lauener at cern.ch> wrote:

>  >> So we're going to provide a way to a ROUTER closes clients by
> Identity?****
>
> ** **
>
> >I'll discuss this with Martin Hurton. There will be protocol changes
> (client needs to know not to reconnect immediately).****
>
> ** **
>
> For us (at CERN) we mostly need this for the case where the client is so
> broken that he is not going to try to reconnect. However its TCP stack is
> still alive and he is keeping the socket open. In such case we want to have
> a mean to clean the socket resource on the server side. So simply closing a
> ROUTER’s underlying socket by client identity is enough. No protocol change
> needed, at least for us ;)****
>
> ** **
>
> If we want to close a client and prevent it from reconnecting, we use our
> high level protocol. Server send a CLOSE message to the client. Client
> close the socket (which in turn close the socket on the server’s side) and
> mark the connection (it will be disabled until server re-enable it). This
> is an high level behaviour that can be triggered programmatically from the
> server or through an administrative GUI.****
>
> ** **
>
> In any case, we are very interested by any progress in this area so please
> keep me informed (issue tracking?).****
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130326/b3c52e4c/attachment.htm>