[zeromq-dev] cleaning up TCP sockets

[guido]

Hi!

On Fri, 22 Mar 2013 10:23:36 +0100
  Pieter Hintjens <ph at imatix.com> wrote:
> On Fri, Mar 22, 2013 at 10:00 AM, guido <dropbox at a-nugget.de> wrote:
>
>>   Felipe Cruz <felipecruz at loogica.net> 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.

Same with TCP.
The application can only check and close the socket.
After some iterations one will run out of available sockets, if the open
requests come in fast enough.

All other solutions make use of external information and functions.
Like packet filters (iptables and friends).

> We're going to have to address this if we want 0MQ to work on public
> networks, which I think many of us want.

This sounds like there *must* be a solution for ØMQ to work on the internets.
TCP doesn't provide a decent solution and is used quite successfully on the net.
Wouldn't a *should* be sufficent?

> Seems to me the monitor API was designed to observe, it's not a management API.

Full ack.

> 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.

This is something that can be done with the current API, as far as I can see.
We have the monitoring which signals new connections and we have the also new
zmq_disconnect method.
Of course this needs some more investigation.

Otoh, a management interface for ØMQ sounds really nice.

> I'd also like to investigate automatic closing of idle connections
> since it would be so simple to use (one socket option).

This would also be very useful for cases where a very high number of
connections are concentrated on one host (ip address).
Very high here means close to the max. available number of ports.

Given ØMQ's reconnect ability this could be done w/o the application
layer noticing it.
So an application could allow ØMQ to throw away an unused connection and
re-open it when the need arises.

On the implementation side we would need a timer per connection, which
is reset when data is transferred on this connection and a function to
be called periodically to clean up the idle connections.

Ahh... already to much time spent on fun things, back to work. :)

Cheers
  Guido