UDP and TCP

Newbie & Debugging Questions
#1

So I was thinking of beginning to develop a multiplayer game. I have done it before, so it’s not the code I need help with. It’s UDP and TCP. My idea is to use both.

TCP, would take care of player commands, and important information. Such as; logging in, logging out, chat, and commands. With “commands” I mean things like order a unit to move, attack, defend, collect and so on.

UDP, would send where all the units are, updating the map, upgrades, and unit health.

For example:
Player 1 uses an ability to send a meteor strike. (TCP)
The server sends the meteor’s; Coordinates, velocity, and direction to all clients. (UDP, since it will be updated quite often.)
The meteor hit the ground, and the server send the terrain deformation to all clients (UDP, the map is updated regularly)
Player 2 get’s angry since he gets hit, and leaves the game (TCP)

Is that a good way to use TCP and UDP? or am I missing something?

#2

There’s basically three ways to approach it:

  1. Use tcp everywhere and just put up with the (potential) extra latency added.
  2. Use udp everywhere and write your own transmission protocol to guarantee delivery when required.
  3. Use both at the same time.

I’ve previously done all three, and they all basically work. Option 3 is nicer if you want to avoid writing a reliability layer over udp, but can make the initial connecting and handshaking more of a pain since you’ve got two connections to manage instead of one. What you’ve described is completely valid if that’s the way you want to go.

If you’re only concerned with minimising latency, then 2 can be good as you can theoretically get a faster reliable protocol than TCP if you bend some of the rules TCP adheres to.

However if this is your first multiplayer game, or if you’re just trying out some ideas, totally go for 1. You can focus on your mechanics and gameplay much quicker, and you probably won’t notice the difference in latency unless you’ve got players in different countries or across mobile networks. I’m doing 1 right now to prove some gameplay and latency is completely not an issue.

Also, consider Kryonet: https://code.google.com/p/kryonet/

#3

This would be my 2nd multiplayer game, I did one sometime ago that only used TCP, and I’m just trying to get lower latency. The map can get deformed, and all the units coordinates needs to be updated quite often (I think). I would go for all UDP, since I like it more. But I have no experience in coding UDP, and what to do when it loses data.

#4

I’ve made a multiplayer game using both UDP and TCP and it works very nicely (as long as you don’t saturate the TCP connection, but use it sparingly for data that must be sent reliably).

#5

Read these:



In fact, just read all of the connected articles - then make your choice based on what your game needs. The suggestions in this thread are all valid.

#6

I think there is a problem with with using TCP and UDP where using TCP delays or causes UDP packets to drop more frequently or something. If someone knows what that reason is I would also like to know.

Also, if you have the infrastructure to use acks in your UDP game what benefit does TCP give you?

#7

It doesn’t. UDP packets are only dropped when there is no space in the buffers to store them. Having an extra connection that you only use sparingly for important data will barely affect the UDP packets.

#8

[Characteristics of UDP Packet Loss: Effect of TCP Traffic]
http://www.isoc.org/INET97/proceedings/F3/F3_1.HTM

#9

I haven’t had noticeable troubles myself with this and it probably won’t effect the majority of small games but an expert once said this:

source: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/

#10

Overall, choosing one or the other comes down I think to how much client-side prediction you can do.

In an FPS, you can’t do much. You receive a velocity and acceleration that is probably valid for 200ms until the user presses some other key to accelerate themselves in another direction. Further, in an FPS if the order of these packets are mixed up, you haven’t lost much. If one of them are dropped, no one is going to notice (and they aren’t worth resending)

In an MMO (i.e, WoW uses A LOT of TCP, so do most other MMOs) you can do a lot of client-side prediction. Attacking an enemy for example is very straight forward. You initiate an attack, and you end an attack. There is nothing that can be dropped in a game like WoW or in JevaEngine that wouldn’t have to be resent anyways.

To conclude, if you implement networking properly it won’t be difficult to go from one to the other, so I’d say start with TCP and move to UDP if you need it.

Don’t drop TCP just because it doesn’t work the first time, you can try manually disabling Nagle’s algorithm to prevent message queuing as well (which helps reduce packet overhead if you are sending small packets - but it may help optimize your game quite a bit if you need instant transmission of packets) Careful configuration of TCP sockets can go a long way.

http://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#setTcpNoDelay(boolean)

#11

Experienced friends don’t let rookie friends write a reliable layer on top of UDP.

TL;DR
go with TCP, make it work, ponder your options, stick with TCP.

#12

Well he says he’s done it before and doesn’t need help with the code :V

But you’re right. TCP is easier to use and it’s 99%* of the time just fine, perfect even, for our needs.

*This estimate is 96.33(3)% accurate.