Fold client_flood_burst_rate check into MAX_FLOOD_BURST.

The original definition of floodgrace was MAX_FLOOD_BURST lines per second.
A second check for another number of lines per second makes no sense.
This commit is contained in:
Jilles Tjoelker 2011-10-04 00:21:19 +02:00
parent 41ca4cac35
commit c598ff7b04
2 changed files with 2 additions and 5 deletions

View file

@ -39,7 +39,7 @@
/* MAX_FLOOD is the amount of lines in a 'burst' we allow from a client,
* anything beyond MAX_FLOOD is limited to about one line per second.
*
* MAX_FLOOD_CONN is the amount of lines we allow from a client who has
* MAX_FLOOD_BURST is the amount of lines we allow from a client who has
* just connected. this allows clients to rejoin multiple channels
* without being so heavily penalised they excess flood.
*/
@ -47,7 +47,7 @@
* spb: Made these configurable
*/
#define MAX_FLOOD ConfigFileEntry.client_flood_burst_max
#define MAX_FLOOD_BURST MAX_FLOOD * 8
#define MAX_FLOOD_BURST ConfigFileEntry.client_flood_burst_rate
extern PF read_packet;

View file

@ -123,9 +123,6 @@ parse_client_queued(struct Client *client_p)
{
if(client_p->localClient->sent_parsed >= client_p->localClient->allow_read)
break;
/* spb: Add second layer of throttling to n lines per second, even during burst */
if(client_p->localClient->actually_read >= ConfigFileEntry.client_flood_burst_rate)
break;
}
/* allow opers 4 times the amount of messages as users. why 4?