Anti key spamming

Discussion in 'Game Development (Technical)' started by e_barroga, Jun 9, 2008.

  1. e_barroga

    e_barroga New Member

    Joined:
    Feb 13, 2008
    Messages:
    17
    Likes Received:
    0
    I am working on a movement system, which is key-based (using WASD), for an MMORPG barebones framework. A problem that I have come across is key spamming for the movement.

    For the system, I am simply sending keystrokes to define when the client starts/stops moving (to minimize packet size and sending intervals substantiallly).

    Everything runs smooth until a malicious client wishes to perform DDoS action (mainly key spamming). For this reason, I am forced to implement an anti-key-spam system.

    My first thought for a solution was to limit the keypresses via timers (disallowing the client to send a movement packet for a miniscule timeframe). However, this would introduce movement bugs, which is byfar worse than key spamming.

    I wasn't able to think of anything else.

    Could anyone help me out?
     
  2. Nikos Beck

    Nikos Beck New Member

    Joined:
    Jun 14, 2007
    Messages:
    321
    Likes Received:
    0
    Are you sending each keypress (down and up)? You could poll keypresses instead. On a timer the game checks if a key is being pressed. If so, either send "key is down" or "key is still down". When it polls the key is up it sends "key is up" unless it was already up where it sends no message to the server. That way you're throttling the messages sent to the server. It's harder for DDoS because no matter how fast they press a key, you'll only send a maximum of 30 messages per second.

    For movement, it's also on a timer so tht the character moves if the key is pressed. That would also give you finer motion.
     
  3. e_barroga

    e_barroga New Member

    Joined:
    Feb 13, 2008
    Messages:
    17
    Likes Received:
    0
    Thank you for the suggestion.
     
  4. Backov

    Original Member

    Joined:
    Oct 23, 2005
    Messages:
    812
    Likes Received:
    0
    You should be abstracting that on the client side. Rather than send a keypress to a server (which is a really bad idea) - you should be sending a message like "movement start->Vector" or whatever. There's more to that of course, but don't send player input directly to the server for interpretation.
     
  5. e_barroga

    e_barroga New Member

    Joined:
    Feb 13, 2008
    Messages:
    17
    Likes Received:
    0
    Could you please explain more? Sorry, I do not understand that.

    Emmanuel Barroga
     
  6. Parthon

    Parthon New Member

    Joined:
    Mar 2, 2008
    Messages:
    23
    Likes Received:
    0
    I think most online games don't send keypresses, they send client position and velocity. This happens about 10 times a second and is verified by the server for accuracy.

    Spells and similar however can be sent as single events, but you wouldn't send keypresses, you'd send one event then disable spells for a small amount of time.
     
  7. vjvj

    Indie Author

    Joined:
    Sep 25, 2004
    Messages:
    1,732
    Likes Received:
    0
    Backov and Parthon are right. At least, in my limited experience developing MMOs.

    Also, I haven't encountered an MMO that sends player movement updates faster than one per second... So ten per second seems a bit fast to me. But again, I haven't touched MMO dev since the Everquest 1 days.
     
  8. e_barroga

    e_barroga New Member

    Joined:
    Feb 13, 2008
    Messages:
    17
    Likes Received:
    0
    You are actually right; they usually don't. However, I thought about sending keypresses instead to reduce bandwidth substantially. Sending client position would also be sent to maintain accuracy.
     
  9. bengarney

    bengarney New Member

    Joined:
    Jun 10, 2008
    Messages:
    20
    Likes Received:
    0
    If you're doing an MMO sending the goal position and having the server verify that it's valid is fine.

    If you're doing a fast action game, the best approach is to send snapshots of input state. So instead of sending key up/down info, just send info about all the keys that are down at that moment. Typically you can pack them into a single byte (depending on how many inputs you have) to keep bandwidth down. You can send multiple move snapshots, too, for instance, depending on how frequently you process networking. It might be a smart idea to sample input at 32Hz and send packets at 10Hz - meaning you're putting about 3 movement snapshots in each packet.

    That's for the important, movement related input. For other stuff (chat, menus, switching spells/abilities) you can send it via a less high-frequency channel and maintain high flexibility.
     
  10. ChrisP

    Indie Author

    Joined:
    Feb 5, 2007
    Messages:
    971
    Likes Received:
    0
    Hmm, really? A friend and I tried a similar approach (for a silly little test game involving hovercraft) a while back and found huge out-of-sync problems, especially in high-latency situations. If you do some tricky stuff to make sure the inputs get injected at exactly the right point in time then perhaps it'd work, but we found it much easier to just send position/velocity/acceleration data. It allowed us to be a bit sloppier about timing and still have everything working pretty well. And the received wisdom I've read seems to indicate that this is the more stable approach.

    If you've had different experiences I'd be glad to hear them. :)
     
  11. bengarney

    bengarney New Member

    Joined:
    Jun 10, 2008
    Messages:
    20
    Likes Received:
    0
    So the client is telling the server where it is in the world..?

    Certainly when the server is sending out updates you want that info. But for sending client movement up to the server, sending input snapshots makes a lot of sense.

    That's how Tribes 1/Tribes 2/Torque Game Engine/OpenTNL all do their networking and it works pretty well. In those cases you're dealing with a system that does a lot more than just the input snapshots, but just the snapshots helps quite a bit.

    No matter what technique you use to upload client movement you have to deal with desynchs. In the above products they just send a full update of the object the client is controlling in every packet to that client. Small bandwidth cost, adds a lot to responsiveness and accuracy.

    Networking is hard, you won't get good results without some work. :(
     
  12. ChrisP

    Indie Author

    Joined:
    Feb 5, 2007
    Messages:
    971
    Likes Received:
    0
    Yes. Obviously this has cheating implications. :) Some server-side work is necessary to make sure the client isn't teleporting themselves in impossible ways.

    That sounds pretty reasonable too.

    It's been quite a while since we made that hovercraft game, and I forget exactly what we were doing - possibly we were neglecting to do something important. It was the first attempt at a real-time networked game for both of us, so that seems likely. :)

    Ain't that the truth.
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer