View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002111 | unreal | ircd | public | 2004-10-05 23:55 | 2013-05-07 07:23 |
Reporter | White_Magic | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | resolved | Resolution | wont fix | ||
Summary | 0002111: Flood protection (umode +f) for webtvs | ||||
Description | some webtv users have complanted about getting mass floods in there whisper and they cant react to stop it, even setting mode +R before the flood often doesnt help as they use registered nicknames. Once the flood starts they must disconnect from the net in order to escape the flood. this umode would allow them to set Xlines in Y seconds (or sumthing like that) if it triigers it would throttle / add them to silence list to prevent the webtv from being flooded too much. | ||||
Tags | No tags attached. | ||||
3rd party modules | |||||
|
Since we have all kinds of usermodes for blocking things, silence doesn't have to be the only option... /mode mynick +f [5c#T30,5t#b]:10 for example, 5 ctcps from anyone in 10 seconds makes me usermode +T (no ctcps) for 30 minutes. 5 messages from a single user in 10 seconds makes me automatically add a SILENCE entry. (Could even use the remove time.) I guess, when you add the noctcp and privdeaf modules you could have type d for DCC, and m for message (a global version of t, like with channel +f). I guess m could just SILENCE *!*@* for whatever time you want, but it should be able to use the privdeaf +D mode if it's available :p . |
|
yup that would be better aquanight - it would provide good protection for anyone really if it was put in, i think for messages just silencing the IP would be the best idea rather than using *!*@* or umode +D the user mite start complaining... <someuser> i was talking to my friends in whisper and i got flooded now i cant talk to anyone in whisper at all <someircop> thats becoz it set +D on you, you need to do either X Y or Z so i recon silence is the better option for that, but Ctcps / notices / messages is defently a good idea in my eyes |
|
Well, I do support making Unreal WebTV friendly. However, I'm skeptical about certain things. Anytime we add such things, we use more memory. For example, the "X lines" and the "Y seconds" needs to be stored somewhere. Whether the user uses the umode or not, we still need to allocate memory for the possibility that they might. So I'm often reluctant to add these things because most users wouldn't use it. Most "real" IRC clients have some kind of built in flood protection. However, we are planning to add an enhanced version of Hybrid +g system. http://bugs.unrealircd.org/view.php?id=92 Basically I think this would deal with your situation. Basically, it's a "silence exception" system. What that means is, You ignore everyone, then you add exceptions for your friends. You will likely be able to add exceptions for specific things. For example, you might only want to receive privmsgs, not notices, from a particular user. I think that would also be able to address the issue of WebTV users being flooded. |
|
I agree. I think doing this would be a bit too insane, and indeed +g would be able to semi-cover this. |
|
Anyway, since this particular bug seems to affect specifically WebTV users, I figured, maybe make +V also make the IRCd queue up messages waiting to go into the client. Sorta like make the sendq slower. Naturally we start running into fun sendq things ending up them getting diconnected anyway, which means there must be a workaround for this without giving normal users the ability to flood without punishment. Maybe a seperate queue for PRIVMSG messages going to them, which is slower than the normal sendq... naturally this throws off CTCP PING etc but who cares about that anyway? :p *edit* crap maybe scratch that, since it'll be memory not used for normal people :( even if it's only 4 bytes for a pointer... */edit* edited on: 2004-10-07 05:04 |
|
the hybrid +g sounds good to cover it, just 1 question, which takes up more memory? |
|
Well, that's kind of hard to answer. The Hybrid +g would take more memory, if it is used. However, if it is not used, it would use less. But the thing is, we were planning to implement +g anyway, so it's not an additional memory increase. |
|
Well you could do a generic setting for +f which wouldn't use memory. Perhaps make it a conf settable thing? Actually what I'm saying here could probably be done as a module... edit: Or make the WebTV users automatically have a generic flood protection? If they constantly have problems with floods, this might even be the best thing to do. edited on: 2004-10-08 06:48 |
|
[quote]edit: Or make the WebTV users automatically have a generic flood protection? If they constantly have problems with floods, this might even be the best thing to do.[/quote] That's still more memory usage. How do we know whether they are being flooded? We have to keep track of who is msging them, and how many times, in how long of a period, just like we do for channels. Storing all of that takes memory. |
|
webtv support is gone |
Date Modified | Username | Field | Change |
---|---|---|---|
2004-10-05 23:55 | White_Magic | New Issue | |
2004-10-06 00:13 | aquanight | Note Added: 0007882 | |
2004-10-06 09:13 | White_Magic | Note Added: 0007884 | |
2004-10-06 18:08 |
|
Note Added: 0007885 | |
2004-10-06 20:44 | syzop | Note Added: 0007886 | |
2004-10-07 05:03 | aquanight | Note Added: 0007897 | |
2004-10-07 05:04 | aquanight | Note Edited: 0007897 | |
2004-10-07 12:08 | White_Magic | Note Added: 0007900 | |
2004-10-07 19:38 |
|
Note Added: 0007902 | |
2004-10-07 19:38 |
|
Relationship added | related to 0000092 |
2004-10-08 06:46 | al5001 | Note Added: 0007911 | |
2004-10-08 06:48 | al5001 | Note Edited: 0007911 | |
2004-10-08 14:28 |
|
Note Added: 0007920 | |
2007-04-27 06:32 |
|
Status | new => feedback |
2013-05-07 07:23 |
|
Note Added: 0017528 | |
2013-05-07 07:23 |
|
Status | feedback => resolved |
2013-05-07 07:23 |
|
Resolution | open => wont fix |
2013-05-07 07:23 |
|
Assigned To | => nenolod |