• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
lgapontes

Sending and receiving UDP packets to character status need be encrypted?

6 posts in this topic

Hi, 
In a MMPOG, I need to send and receive actions of the players (moving map, attack, open door, etc). Today I am sending this data in UDP datagrams encrypted with AES 128-bit and checksum CRC32. The problem is that on average I spend about 150ms to send and receive a single UDP packet. It is a performance very close to what I get traveling with TCP (200ms). I suppose I'm having a very large overhead because of the encryption/decryption AES. 
 
Do you know if the games MMPOG sends UDP packets to status of players encrypted?
 
Thanks...
0

Share this post


Link to post
Share on other sites

You should consider a different strategy as encryption as you discovered is not the most efficient.

 

Send data unencrypted but the server needs to decide if the action the client sent fits within the rules of the game world. For example a player sending movement data, over a given time can a character cover the distance between p1 and p2, if the move is legal the server now tells other clients the character is at p2, if not the server keeps the player at p1. The aim is to not trust the client, you will also have to account for packets arriving out of order or lost.

1

Share this post


Link to post
Share on other sites


 I suppose I'm having a very large overhead because of the encryption/decryption AES. 

You should measure first, before deciding what the issue is.

2

Share this post


Link to post
Share on other sites
rip-off is correct. You should profile your code. Guessing is worse than useless, it can be actively damaging - whether it's your guesses or ours.
2

Share this post


Link to post
Share on other sites
Thanks guys ... I'll do some more tests that measure performance of the methods of encryption and decryption and also involve in a poor performance, try to do what ExcessNeo suggested (UDP without encryption). 
 
I think similarly: now with encryption I just avoid someone else do commands going by the player, but still susceptible if a malicious player modify the client and send wrong commands to the server.
 
If I put the validation rule commands on the server, protect me against the two situations, even without encryption. 
 
Another thing I have left is to put a validation hash to the executable of the game from time to time - to avoid the client to change its executable. 
 
Thank you very much! may be force be with you ...
0

Share this post


Link to post
Share on other sites
To register: did the tests and the cost of encryption is very small ... 
 
...
 
Encrypt time: 0 ms 
Send package: 7efbfbb623d21a65ff3d6a4ee6d19bcea8965d59f9c41bf34d010be3c917232f4753d722c6010b86071b93b13da331674ecf1ac9142c664f3041d88c
Decrypt time: 0 ms 
Time calculed: 20140723215945558 to 20140723215945712 = 154 ms 
SEND AND RECIEVE TIME: 154 ms 
correctMessages: 81 - wrongMessages 18 
 
Encrypt time: 0 ms 
Send package: b3b0bbc937b5a9d68063effd3adb15fb268b1cf338baf8d5a599cb25b6721cdbe04ccffb3e9c483b4cc651e44eab8a32219b78da9f187e46a83de735
Decrypt time: 0 ms 
SEND AND RECIEVE TIME: 201 ms 
correctMessages: 81 - wrongMessages 19 
...
 
I will do more tests, but I'll probably keep them encrypted. 
Thank you!
0

Share this post


Link to post
Share on other sites

Since you are encrypting the packets in the client you have to include the encryption-keys in the client too.

With this you are giving a malicious and knowledgeable player everything he needs to capture, unencrypt, modify and re-encrypt the packets before they leave his computer. He just has to extract your keys from your program! (which is not that hard to do)

He doesn't even have to modify your *.exe! So while checking the checksum of the *.exe might hinder a malicious player, it won't stop him from tinkering with your program. (he could modify the program on-the-fly in-memory after the program loaded)

 

So do what the others say and discard your encryption and don't trust you clients.

(this has the added benefit that you "could" intercept the packets yourself to aid you in debugging some problems)

0

Share this post


Link to post
Share on other sites

Even without measuring it is clear that AES cannot possibly be the reason for that delay. Typical AES software implementations run at speeds upwards of 150 MB/s, optimized implementations using special CPU instructions run about 4 times as fast. Thus, unless you have the most pathetic AES implementation in the universe, 150ms delay is equivalent to encrypting megabytes of data. Encrypting 120 bytes will take, as you have measured, more or less zero time (means under a microsecond, not hundreds of milliseconds).

 

Did you make sure that no application level firewall is running on either of the machines (which maybe does realtime scanning on traffic)? This is on a LAN, I suppose? Routers in between causing delay?

 

Also, can you describe how you measure that sending and receiving takes 150 or 200 milliseconds, and what it means exactly? Measuring what time it takes to send is (naively) easy, although in reality you can only measure the time it takes to push the data to the network stack. You do also display a number for receiving, though.

 

Receiving can only be measured on the other computer, but it is not meaningful to measure that. The receive will block forever as long as no packets come in, and unless the two computers are in perfect sync (which is impossible) there is no way of knowing when to start counting. Even doing this over loopback on the same computer could be troublesome due to scheduling.

 

You should measure complete round trips (and divide by two for one-way). That way, it's the same clock everywhere, and there are no synchronization issues.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0