Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium


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
  • 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?
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

LVL 36

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 36

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

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

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

Recently, in one of the tech-blogs I usually read, I saw a post about the best-selling video games through history. The first place in the list is for the classic, extremely addictive Tetris. Well, a long time ago, in a galaxy far far away, I was…
Java functions are among the best things for programmers to work with as Java sites can be very easy to read and prepare. Java especially simplifies many processes in the coding industry as it helps integrate many forms of technology and different d…
This video teaches viewers about errors in exception handling.
Viewers will learn how to properly install Eclipse with the necessary JDK, and will take a look at an introductory Java program. Download Eclipse installation zip file: Extract files from zip file: Download and install JDK 8: Open Eclipse and …
Suggested Courses
Course of the Month14 days, 22 hours left to enroll

577 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