   Flood prevention/detection
  I'm tinkering with a multiplayer game at the moment, 2-13 players [1 -12 players, and a dungeon master], in as strict of a D&D setting as i can get [i'm pulling maps/monsters ect.. straight from a dungeon book that i purchased, and am trying to make as accurate a representation as i can, as practice].... Anyway, I'm sorta bumping my head against a certain problem.  The 'server' part, which is actually just a seperate thread on the dungeon master's computer, runs great under nearly all typical conditions.  I recently began tinkering with the idea of rule enforcement between untrusted clients, in other words, doing what i can to make my game hack-resistant [since before, the clients were trusted completely, but not anymore] and there is a certain kind of problem i'm having a lot of trouble even contemplating how to deflect.  The title of the thread makes it obvious what this problem is.... Flooding.  A given client spams the <explicative deleted> out of my server thread, and fills the incoming buffer [which is using UDP] between reads from the network [which occur about 10 times a second].  I'm doing my testing on a Gigabit lan, which may very well be one of the reasons this problem can be so easily brought to light...Anyway, It seems like simply throwing out bad packets isn't sufficient, since if the volume is great enough, i'll be recieving packets nearly as fast as i can discard them, and on UDP, there isn't much of a sheild for just disconnecting a certain host.  Am i going to get stuck switching to TCP? [really don't wana do that... the word 'tcp' and the word 'slow' go too hand in hand :P]Am i throwing software at a hardware problem, and instead should be getting my router to just deny certain hosts that are seen as spammers?Any other solutions? [or should i just consider that the likelyhood of my game EVER being run on a network this damn fast in reality, is silly, and in reality i'd have time to filter through dirty packets.]Even a single host can spam so rapidly on my current setup, that i can continuously read from the network, and the spammer will gain buffer ground:P [and eventually max it out]   
  tcp != slow.  WoW uses TCP for a lot of stuff, if not all of their networking.  There is also an Ultima Online server written I do believe in C# using TCP that handles 3000+ connections on one PC (its a nice box but still shows what you can do with decent coding).   ;  Floods should be taken care of by your router, they are desinged to do this sort of thing.  At least good routers are.  They are also optimized so that they would not have the huge perfrmance hit that you would get trying to take care of it.theTroll   ;  I know TCP can do things well, just mean to say that its slowER, when compared to udp for predictable packet sizes on a connection that does not require assure delivery. 3000 connections is obviously more than i need, and TCP would certainly work for this application, but I'm trying to gain experience for when i actually get around to encountering things of that size, so I'll know what needs to be done when i encounter problems that are a bit more elaborate and critical than my little D&D thing.  Frankly, i could do with putting no checking whatsoever and it works just fine, but i'm doing this for the sake of practice... with that said....I had a feeling that i was throwing software at a hardware problem.  My router doesn't seem to stop the storming, but i know i can configure it to, and I'm going to look into guides on how to configure it on-the-fly to restrict access from blah blah.Thanks for the input though :D   ;  DOS is annoying. Basically, anyone with a bigger pipe than you can put you out of service, and there's nothing you can do about it (except detect it and start calling network management people).When we talk about routers dropping DOS packets, we're talking about high-powered corporate routers, not the $100 bits of plastic you get at home. Because the packet already traveled over your cable or DSL link, throwing it out does nothing to improve available bandwidth.If your current client is sending too many packets, then make it send less. If you're worried about a theoretical DOS attack, then stop worrying about that, and start worrying about some problem you can actually solve instead :-);  Oh the client sends a reasonable amount, but just for the sake of practice, i'm playing around with different methods of rule enforcement, and defenses against users trying to not play nice.  The problem I'm running into moreso is buffers filling up and causing huge numbers of packets to just be dropped on the ground, but i'm concluding that its moreso because my network connection is so much faster than my ability to sift through the data :PRather gather though that my router just isn't capable of such programmable filtering, not that i've given up yet though!  At the very least, this is turning into quite the interesting learning experience as now i'm attempting to get the server to program the router on-the-fly to block junk transmissions from clients who have demonstrated that they intend to be troublesome, and expanded the buffer size as to lessen the chance of being outwardly overwhelmed before being able to react.All in all, this isn't a problem i'm going to be able to solve with my current setup, but its still interesting to consider the problem, and ponder how it should be solved, and how it would best be solved.   ;Quote:Original post by Peachy keenRather gather though that my router just isn't capable of such programmable filtering, not that i've given up yet though!  At the very least, this is turning into quite the interesting learning experience as now i'm attempting to get the server to program the router on-the-fly to block junk transmissions from clients who have demonstrated that they intend to be troublesomeYou understand that that won't actually help you, right? Your network connection is already flooded by the packets; even if your router discards the packets, that doesn't make your link less clogged. You have to program the router on the OTHER side of the link for it to be effective.Something you should watch out for, though: don't let your server make your client an instrument of a DDOS; make sure that the address that you're sending to is actually the address that the other end is at. Don't accept lots of connection attempts (say, more than 3 in a minute) from the same IP, for example -- it could be a spoofed packet, wanting your reply to the other end to "flood" the indicated return address.