[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: flood nets



>>>>> "Christophe" == Christophe Kalt <kalt@xxxxxxxxxxx> writes:

  Christophe> Over a month ago I realized that it was fairly simple
  Christophe> (and costless) to add a user protection against flood
  Christophe> nets (won't protect you if you have a dumb client
  Christophe> replying too all CTCP requests you get).

Alas many clients are dumb. Of the people I see on regular channels
that are flooded, not many exit with sendq exceeded.

  Christophe> Basically, when the server thinks you're in trouble, it
  Christophe> stops sending the client private msg/notices coming from
  Christophe> other clients. (toggled on/off with a user mode)

  Christophe> A side effect to the feature is that it's then easy to
  Christophe> detect flood nets (when they are in action).

  Christophe> Since I wrote the patch, I've been wondering what to do
  Christophe> with it.  It might sound weird to you, but I don't think
  Christophe> it has any real use.

I presume this is where your lists of fludnet bots sent to ircnet
operlist came from.

I think it's a bad idea to use the patch to detect fludnet bots since
when the protection is activated the victim will no doubt be receiving
privmsgs/notices from both the flooders and legitimate users/channels
as a general part of IRC conversing. As such a few ordinary people
(who are not fludnet bots) will appear on the list of "detected"
fludnet bots.

I do think the patch is useful though in that it prevents another
condition whereby a user can be forced off IRC by others. If a fludnet
cannot kill a client's connection (which it currently can) the
incentive to flood people is reduced (although not removed).

Not having seen the patch, I assume the protection kicks in when a
client's sendq isn't totally full, and has some hysteresis[0] so the
protection isn't turned off until the sendq falls a bit? If it's not
obvious, this is so that legitimate "status" information not being
blocked doesn't trip the client over the sendq limit, and so that the
protection isn't being flicked on and off as the client slowly
processes the sendq.

 - Andrew "Earthpig" Snare
[0] For the last few years I've thought hysteresis was evil but
    unavoidable in EM theory. A week or so ago I realised it's
    desirable in multivibrators for the same reason it's desirable
    here. :) Sorry... I've got Elec Eng exams on right now :-/
-- 
#!/usr/bin/env python
print(lambda s:s+"("+`s`+")")\
('#!/usr/bin/env python\012print(lambda s:s+"("+`s`+")")\\\012')
print(lambda x:x%`x`)('print(lambda x:x%%`x`)(%s)')

Attachment: pgp00008.pgp
Description: PGP signature