Further on this topic: - Martin points out that the calling thread is sleeping, not processing commands, so it's normal that the mailbox backs up. - One option that this should be treated as an application error, the parent socket should be killed when the mailbox hits its limit, and further access on that socket return an error like EBROKEN. - Thus, apps which don't do I/O often enough will still be vulnerable to rogue clients.
There are some other possibilities here: - Do a disconnection backoff in the server (not just the client), i.e. do not disconnect immediately but after a delay which grows. Thus even a hand-crafted rogue client won't be able to DoS an application. - Do not allow new connections at all if the mailbox has exceeded some limit. This may impact honest clients but it will catch the situation upfront. - Do not allow new connections from known rogue clients. This could be generalized in future to include other definitions of "rogue" such as clients sending malformed frames, incomplete envelopes, etc. "Client" in this case could be an IP address. Hope this helps. Cheers, Pieter On Thu, Feb 17, 2011 at 11:02 AM, Pieter Hintjens <[email protected]> wrote: > On Thu, Feb 17, 2011 at 11:01 AM, Pieter Hintjens <[email protected]> wrote: > >> It happens after 604 reconnections... > > FWIW I count the number of disconnections by inserting a print > statement into src/session.cpp at line 238: > > // If the session already has an engine attached, destroy new one. > // Note new engine is not plugged in yet, we don't have to unplug it. > if (engine) { > delete engine_; > puts ("disconnect peer"); > return; > } > > -Pieter > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
