On Fri, Mar 22, 2013 at 10:00 AM, guido <[email protected]> wrote: > Felipe Cruz <[email protected]> wrote: >> Maybe this can be done with the monitor api with a new >> ZMQ_EVENT_INACTIVITY_TIMEOUT ? > > I think this is exactly the case where the people > normally yelling "we don't want this to be used by applications" > would chime in.
We can agree on the problem as stated, right? As Joel pointed out there's no way to reject or close a specific client connection today. This does mean a ROUTER can't protect itself against DoS attacks intentional or accidental. We're going to have to address this if we want 0MQ to work on public networks, which I think many of us want. Seems to me the monitor API was designed to observe, it's not a management API. Closing ROUTER peer connections explicitly seems like a fair idea. My feeling is you'd want a message-based approach, as we use with XPUB sockets to receive subscriptions. Receive a message when there's a new peer connection, and send a particular message to close a peer connection. Allow the application to define the rules. I'd also like to investigate automatic closing of idle connections since it would be so simple to use (one socket option). -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
