You don't need any programming experience whatsoever to circumvent the restriction...AF wrote:it's not n# messages, it's volume of traffic.
Also, the people most likely to spam channels, are the people most unlikely to know howto alter and circumvent the restriction. It's a safe bet that 90%+ of flooders dont know how to program, nevermind navigate the maze that is compiling TASClient.
Turn off the retarded spam/flood filter
Moderator: Moderators
-
Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
Depends on what variety of channel flooders we're talking about.AF wrote:99% of channel flooders know nothing about the protocol or how to use telnet or putty.
And as previously stated such an attack would be foiled by the servers traffic limits.
People who manually type spam or copy/paste spam probably aren't intelligent enough to program or to telnet, true.
However, the people who make spambots most certainly do know about telnet, connection protocols, and programming. Just because we don't have them now doesn't mean we'll never have them.
Aren't you talking in circles here now?
First you say the restriction can be clientside, then it is said that serverside is also still needed because clientside is easily circumvented, and then you say it doesn't matter if it's circumvented because there's serverside restriction anyway
All in all this lobby spam discussion is useless... the points are clear:
1) server side restriction is necessary to stop the true spammers (and we have it already, the restriction)
2) client side restriction would be a nice feature to prevent (IMHO pretty stupid) people "unintentionally" (yeah, right ) spamming the server, but it is not necessary at all. (we aren't talking story telling here.. 20KB in 10 seconds is pretty much)
First you say the restriction can be clientside, then it is said that serverside is also still needed because clientside is easily circumvented, and then you say it doesn't matter if it's circumvented because there's serverside restriction anyway
All in all this lobby spam discussion is useless... the points are clear:
1) server side restriction is necessary to stop the true spammers (and we have it already, the restriction)
2) client side restriction would be a nice feature to prevent (IMHO pretty stupid) people "unintentionally" (yeah, right
) spamming the server, but it is not necessary at all. (we aren't talking story telling here.. 20KB in 10 seconds is pretty much)
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
He's asking for both. He wants to keep the current system but add lobby side spam protection as well so users can't get them selfs banned by server for not knowing better and spamming lobby.Tobi wrote:Aren't you talking in circles here now?
First you say the restriction can be clientside, then it is said that serverside is also still needed because clientside is easily circumvented, and then you say it doesn't matter if it's circumvented because there's serverside restriction anyway
All in all this lobby spam discussion is useless... the points are clear:
1) server side restriction is necessary to stop the true spammers (and we have it already, the restriction)
2) client side restriction would be a nice feature to prevent (IMHO pretty stupid) people "unintentionally" (yeah, right
As a side note, chanserv and the lobby run on the same machien i believe, and it is possible to crash chanserv without filling the 20kb buffer very easily because of the way it is built.
Since cookiebot is a very ehavily modified version fo chanserv I had to do a lot of architectural desing changes internally, as Zenka was reporting 100% usage on an AMD 3500+, and the program ran at a snails pace for me. In the end the sheer traffic backlog made it timeout and disconnect frequently.
Sending a command a second for 2 minutes from 3 users should be enough to timeout most instances of chanserv,a nd give a sizeable delay in finsihing the backlog and reconenction if ti ahs been implemented yet.
Since cookiebot is a very ehavily modified version fo chanserv I had to do a lot of architectural desing changes internally, as Zenka was reporting 100% usage on an AMD 3500+, and the program ran at a snails pace for me. In the end the sheer traffic backlog made it timeout and disconnect frequently.
Sending a command a second for 2 minutes from 3 users should be enough to timeout most instances of chanserv,a nd give a sizeable delay in finsihing the backlog and reconenction if ti ahs been implemented yet.
Not really since ChanServ has administrative access and anti-flood protection does not apply for administrators, so you can't really "crash" it.AF wrote:As a side note, chanserv and the lobby run on the same machien i believe, and it is possible to crash chanserv without filling the 20kb buffer very easily because of the way it is built.
Since cookiebot is a very ehavily modified version fo chanserv I had to do a lot of architectural desing changes internally, as Zenka was reporting 100% usage on an AMD 3500+, and the program ran at a snails pace for me. In the end the sheer traffic backlog made it timeout and disconnect frequently.
Sending a command a second for 2 minutes from 3 users should be enough to timeout most instances of chanserv,a nd give a sizeable delay in finsihing the backlog and reconenction if ti ahs been implemented yet.
Also I just checked for CPU time, ChanServ spent 2 hours of CPU time in last 20 days, utilizing 0.4% of CPU in total. I guess your "redesign" wasn't so good afterall? :)
I guess I could add some warning pm from chanserv in case it detects repeating lines too fast for example. The 2KB/s limit is only to avoid people trying to crash the server since that happened in the past as well (not really crash, but more like DOS attack)Tobi wrote:2) client side restriction would be a nice feature to prevent (IMHO pretty stupid) people "unintentionally" (yeah, right Rolling Eyes ) spamming the server, but it is not necessary at all. (we aren't talking story telling here.. 20KB in 10 seconds is pretty much)
Chanserv isnt so perfect.
My redesign dropped cpu usage on my computer from 100% to 0.006%, and sped up my copy of chansev by a huge factor.
The chanserv I took from the svn parsed commands it recieved at a rate of 2 per second, which is a snails pace considering that fact it took 15 minutes to finish going through the backlog of messages.
If you had actually read my post you would realize I did not say it would overload through the 20kb barrier. I instead said that it would timeout because of the delayed pings.
Once chanserv is finsihed going through the backlog it processes very little cpu untill given a torrent of commands, giving it the illusion of very low cpu usage. Afterall we could run spring for hundreds of days with minimal resource usage if we told our units to do absolutely nothing and gave no commands at all, doesnt mean we can run spring on a pentium 2....
Also the itnernal setup fo chanserv is only stable because fo the way you're using it, just as metalmaker AI doesnt crash ebcause the way it's sued means the crash events never get the chance to occur. As soon as I started work on getting chanserv->cookiebot I got allsorts of errors todo with channel handling, so much so i totally removed the system.
The message loop itself is bad coding practice for java imo and once replaced gave a big speed icnrease for me.
Also I gave you a single line of code int he past that improved chanservs speed by a factor of 4 when I tested it and you did nothing. aka when you go to get the next line out the bfufered reader, check to see if it's ready to be read first.
Also chanserv is case sensitive, the lobby is not. For one I can have KoBS and kobs registered to different people. I cant kick UsEr I have to kick the one with different case but the same spelling. We have to stick to the silly #channel convention too, when it should ignore the # so we can do either.
Since chanserv and the server where so similar in the core design at the beginning I'm astounded that you didnt upgrade chanserv nd the server simultaneously when it came to how they connected. Chanserv would have benefited enormously from nonbloblocking sockets, and if you had continued correctly, it would have been a copy paste affair when you added it to the server, as it has been between AFLobby and the new design for cookiebot
My redesign dropped cpu usage on my computer from 100% to 0.006%, and sped up my copy of chansev by a huge factor.
The chanserv I took from the svn parsed commands it recieved at a rate of 2 per second, which is a snails pace considering that fact it took 15 minutes to finish going through the backlog of messages.
If you had actually read my post you would realize I did not say it would overload through the 20kb barrier. I instead said that it would timeout because of the delayed pings.
Once chanserv is finsihed going through the backlog it processes very little cpu untill given a torrent of commands, giving it the illusion of very low cpu usage. Afterall we could run spring for hundreds of days with minimal resource usage if we told our units to do absolutely nothing and gave no commands at all, doesnt mean we can run spring on a pentium 2....
Also the itnernal setup fo chanserv is only stable because fo the way you're using it, just as metalmaker AI doesnt crash ebcause the way it's sued means the crash events never get the chance to occur. As soon as I started work on getting chanserv->cookiebot I got allsorts of errors todo with channel handling, so much so i totally removed the system.
The message loop itself is bad coding practice for java imo and once replaced gave a big speed icnrease for me.
Also I gave you a single line of code int he past that improved chanservs speed by a factor of 4 when I tested it and you did nothing. aka when you go to get the next line out the bfufered reader, check to see if it's ready to be read first.
Also chanserv is case sensitive, the lobby is not. For one I can have KoBS and kobs registered to different people. I cant kick UsEr I have to kick the one with different case but the same spelling. We have to stick to the silly #channel convention too, when it should ignore the # so we can do either.
Since chanserv and the server where so similar in the core design at the beginning I'm astounded that you didnt upgrade chanserv nd the server simultaneously when it came to how they connected. Chanserv would have benefited enormously from nonbloblocking sockets, and if you had continued correctly, it would have been a copy paste affair when you added it to the server, as it has been between AFLobby and the new design for cookiebot
-
hollowsoul
- Posts: 665
- Joined: 06 Jun 2006, 19:49
You are welcome to write your own code rather than use mine then.
I am locking this thread ...
eh I couldn't resist:
I am locking this thread ...
eh I couldn't resist:
Like I said, you did a bad fork. It works fine here, processing thousands of command per second withouth a problem (tested).The chanserv I took from the svn parsed commands it recieved at a rate of 2 per second, which is a snails pace considering that fact it took 15 minutes to finish going through the backlog of messages.
I detected no "spikes" during execution, only at the beginning (for the first second or so) when java virtual machine is still loading and program is parsing settings.xml and establishing a connection etc.It doesnt matter if windows has an hour long spike of 100% cpu usage per day if its average cpu time is only 4.1%?
Wrong, using threads for each connection is a bad practice, not message loop. Google it up a bit and you'll see.The message loop itself is bad coding practice for java imo and once replaced gave a big speed icnrease for me.