Solved

Network game - UDP safety concerns?

Posted on 2014-10-28
10
254 Views
Last Modified: 2014-11-09
Hi
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?
Thanks
0
Comment
Question by:beavoid
  • 3
  • 2
  • 2
  • +1
10 Comments
 
LVL 26

Assisted Solution

by:dpearson
dpearson earned 334 total points
Comment Utility
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?

Doug
0
 

Author Comment

by:beavoid
Comment Utility
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?
Thanks
0
 
LVL 61

Expert Comment

by:gheist
Comment Utility
How do you draw screen image without knowing game state on client side?
0
 
LVL 34

Accepted Solution

by:
Gary Patterson earned 166 total points
Comment Utility
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:

http://www.ase.md/~aursu/ClientServerThreads.html
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 
LVL 61

Expert Comment

by:gheist
Comment Utility
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.
0
 
LVL 34

Expert Comment

by:Gary Patterson
Comment Utility
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.
0
 
LVL 61

Expert Comment

by:gheist
Comment Utility
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.
0
 
LVL 26

Assisted Solution

by:dpearson
dpearson earned 334 total points
Comment Utility
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:
http://karanbalkar.com/2014/02/tutorial-76-implement-aes-256-encryptiondecryption-using-java/

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 :)
0
 

Author Closing Comment

by:beavoid
Comment Utility
Thank you.
0

Featured Post

Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

Join & Write a Comment

Java contains several comparison operators (e.g., <, <=, >, >=, ==, !=) that allow you to compare primitive values. However, these operators cannot be used to compare the contents of objects. Interface Comparable is used to allow objects of a cl…
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…
This tutorial covers a step-by-step guide to install VisualVM launcher in eclipse.
This tutorial will introduce the viewer to VisualVM for the Java platform application. This video explains an example program and covers the Overview, Monitor, and Heap Dump tabs.

772 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

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now