Network game - UDP safety concerns?

Posted on 2014-10-28
Medium Priority
Last Modified: 2014-11-09
My Java RTS server skeleton works . . Only UDP movement updates left to do. Are there any gotchas?

It connects with TCP correctly, and can update the game state reliably in TCP also. - moving squares randomly around a window for now (authoritarian server )
All I need to do is consider sending UDP intermediary updates between each TCP update. Is that what Blizzard and Microsoft incorporate? Is Blizzard still client side game-state?
But, what if I omit the UDP updates by encoding the next frame's visible movements into the TCP message? - just an extra x,y vector or location integer pair after the unit's location for its moving?
Would a UDP movement update be for many units? When does the size of a UDP message become a risk?
Question by:beavoid
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 2
  • 2
  • +1
LVL 28

Assisted Solution

dpearson earned 1336 total points
ID: 40408923
The only reason to use UDP is because it's faster than TCP.  So you can send and receive more UDP updates per second than you can send and receive TCP updates (over a given quality of network connection).  So the game should be smoother if you include UDP because of the faster update rate.  But it should work entirely correctly if you just use TCP - because you can't rely on any of the UDP traffic arriving since it's not guaranteed delivery.

That being said, for an RTS you might be fine with just TCP since it actually doesn't need a super high update rate.  You really only need to know when a human issues a new command.  Everything else is deterministic (at least usually that's the case for an RTS - assuming there's no random behaviors like 40% chance to hit etc.), so the client can play out the behavior at 60 fps even if human actions / game state updates are only coming to/from the server at say 15 fps.

However, if human actions at 15 fps (or whatever level you manage to achieve over a real network) aren't sufficient, then you can use UDP to boost that frame rate and make the game a little bit more responsive to player clicks.

Does that make sense?


Author Comment

ID: 40410012
Yes, thanks

In my RTS, it also isn't obvious for me... I keep getting stuck with knotted method calls and tricky if constructs. . Threading dilemmas

What I thought was obvious was,
For each frame of the RTS game,
what does the if statement / loop structure look like
. . To have a listener Thread in the client engine for UDP messages in addition to a TCP Thread for TCP messages, Hopefully, it's UDP that arrives first, as it is the better performance.
My idea is...
The clients send TCP in-game client activity messages to the server (first, for each frame of the game, like a safety net)
This is instantly followed by a UDP, faster send of the same message, hopefully arriving sooner?
A Server Thread that listens for UDP messages
and Server Thread that listens for TCP messages.

How is the run() method of server constructed? How do the receiver Threads intercommunicate, to decide what byte[] to return as the message for that game cycle?
I'm thinking a messageReceived class that is basically a byte[] received holder that can be polled in the run() method until the message is not null, whose Object's byte[] can be updated by the TCP or UDP handler class?
That would work, controlled by either client Engine type.

Are methods in a Threaded class that aren't in the run() method also processed on a Threaded tier, or are they straightforward blocks?

Sound good?
LVL 62

Expert Comment

ID: 40417955
How do you draw screen image without knowing game state on client side?
Get 15 Days FREE Full-Featured Trial

Benefit from a mission critical IT monitoring with Monitis Premium or get it FREE for your entry level monitoring needs.
-Over 200,000 users
-More than 300,000 websites monitored
-Used in 197 countries
-Recommended by 98% of users

LVL 35

Accepted Solution

Gary Patterson earned 664 total points
ID: 40418281
TCP is a "two-way" (and hence, "reliable") transport protocol.  It guarantees delivery of the PDU, but causes more network traffic and is slower than UDP since it has more overhead (larger header) and requires a connection and acknowledgement.  If TCP PDUs go missing, the TCP protocol will (eventually) send it again automatically.  TCP should be used in situations where you can't afford to lose any data.

UDP is a "one way" (and hence "unreliable") transport protocol.  It sends the PDU, and then forgets about it.  If it doesn't make it, it doesn't make it (though you could implement some sort of reliability at the application layer, of course).  UDP is used when you need to send data quickly, and if it is OK if some intermediate data is lost.

One of the tricky things about programming network communication applications is that you don't have control over what happens between the time your sending program sends and a when a receiver receives.  Two IP packets, one sent right after the other, can take two different routes to the same destination, which means they could arrive out of sequence.  

TCP takes care of packet sequencing:  it will only deliver data in sequence to the application layer.  UDP doesn't.  The application layer just gets whatever UDP PDUs arrive, in the sequence that they arrive.  

In a multithreaded application that is doing communications to the same endpoint, you should not make any assumptions about receive timing based on send timing between the two threads.

Another thing to consider when designing communications-dependent applications is firewalls.  TCP is "firewall friendly", when the flow is initiated by a client behind a firewall, since firewalls can generally follow the flow of a TCP conversation, and will allow a conversation that is initiated from behind the firewall to progress.

UDP, on the other hand, is "connectionless", so a firewall generally has no way to follow the flow of a two-way conversation using UDP.  As a result, in common firewall configurations, outbound UDP traffic generally goes out OK, but inbound UDP traffic is discarded unless there is a specific exception configured in the firewall to permit inbound UDP connections to specific UDP ports.  UDP is even more tricky when both endpoints sit behind different firewalls - then exceptions are typically required at both ends to permit two-way communications over UDP, or you have to use tricks like hole-punching or firewall features like UPNP to get around firewall restrictions.

If you need to have simultaneous communications streams running in a java application, the best way to do it is to spawn one thread per data stream, and synchronize between the threads as needed.  

And here's an article that includes a multithreaded chat client that I think will answer a lot of your questions about how the core code in a multithreaded Java application should function:

LVL 62

Expert Comment

ID: 40418380
If you are concerned about security you need to encrypt and sign packets in UDP, also you should consider that each of packets may not reach the destination.
e.g. Forging UDP packet takes just 16bit port number, while TCP has much more information embedded to track the connection and prevent forgery.
Why dont you just use SSL like OpenSSL or whatever you get your hands on and not worry about 1) safety 2) packet loss.
LVL 35

Expert Comment

by:Gary Patterson
ID: 40418551
gheist said

Why dont you just use SSL like OpenSSL or whatever you get your hands on and not worry about 1) safety 2) packet loss.

I can think of two good reasons in a client/server to NOT use SSL:  performance and cost.  SSL burns a lot of bandwidth and CPU cycles - both of which add up to big infrastructure dollars in a large multi-player game environment.  If security is your number one concern, then yes, use SSL.  But a lot of games value performance over security.  That is a design trade-off decision that you'll have to make.
LVL 62

Expert Comment

ID: 40418632
As a minimum some per-session cryptographically strong counter should be included in UDP packets. Sounds complex...
I'd say start with darn SSL, then evolve into something more efficient.
LVL 28

Assisted Solution

dpearson earned 1336 total points
ID: 40418780
To get network security, I think the UDP/TCP game packets themselves don't need to use SSL.  SSL can be used one time to pass a secure key (which can just be a random value of some reasonable length like 256 bits) between client and server and then use that key to encrypt the packets over TCP/UDP that are sent using any of a number of fast encryption algorithms.

The requirement for security is just that the key is passed securely and that can be slow since it's one time only (per game session).  So it can use SSL.

E.g. You could use AES for the actual encryption of the TCP/UDP messages which Java supports directly and is very strong.  There's sample code here:

But I think we may be running before we're walking here.  I think first up is just having a working UDP implementation, then you can worry about making it secure :)

Author Closing Comment

ID: 40432010
Thank you.

Featured Post

On Demand Webinar: Networking for the Cloud Era

Did you know SD-WANs can improve network connectivity? Check out this webinar to learn how an SD-WAN simplified, one-click tool can help you migrate and manage data in the cloud.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This was posted to the Netbeans forum a Feb, 2010 and I also sent it to Verisign. Who didn't help much in my struggles to get my application signed. ------------------------- Start The idea here is to target your cell phones with the correct…
Introduction Java can be integrated with native programs using an interface called JNI(Java Native Interface). Native programs are programs which can directly run on the processor. JNI is simply a naming and calling convention so that the JVM (Java…
Viewers will learn about basic arrays, how to declare them, and how to use them. Introduction and definition: Declare an array and cover the syntax of declaring them: Initialize every index in the created array: Example/Features of a basic arr…
This video teaches viewers about errors in exception handling.
Suggested Courses
Course of the Month11 days, 2 hours left to enroll

770 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question