Network game - UDP safety concerns?

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?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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?

beavoidAuthor Commented:
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?
How do you draw screen image without knowing game state on client side?
OWASP Proactive Controls

Learn the most important control and control categories that every architect and developer should include in their projects.

Gary PattersonVP Technology / Senior Consultant Commented:
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:

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
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.
Gary PattersonVP Technology / Senior Consultant Commented:
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.
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.
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 :)
beavoidAuthor Commented:
Thank you.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Game Programming

From novice to tech pro — start learning today.