Flood Protection

The new message queueing mechanism is a good step in this direction. If not else, bot-flooding in one channel doesn't hurt all other channels, or at least hurts a lot less. Rather than actually ignoring flooding users, I would suggest delaying responses directed at them.

Section 5.8 of RFC 2813 reads:

5.8 Flood control of clients

   With a large network of interconnected IRC servers, it is quite easy
   for any single client attached to the network to supply a continuous
   stream of messages that result in not only flooding the network, but
   also degrading the level of service provided to others.  Rather than
   require every 'victim' to provide their own protection, flood
   protection was written into the server and is applied to all clients
   except services.  The current algorithm is as follows:

   * check to see if client's `message timer' is less than current time
     (set to be equal if it is);

   * read any data present from the client;

   * while the timer is less than ten (10) seconds ahead of the current
     time, parse any present messages and penalize the client by two (2)
     seconds for each message;

   * additional penalties MAY be used for specific commands which
     generate a lot of traffic across the network.

   This in essence means that the client may send one (1) message every
   two (2) seconds without being adversely affected.  Services MAY also
   be subject to this mechanism.

I'll look into implementing it this way.

Proper global flood protection has been implemented in [551].

I'm leaving this ticket open because of the suggestion of per-user flood protection.