Im making a game where real-time data is exchanged between server and clients, and I was using java UDP sockets straight up, but I reached a point where I actually need to know if a few specific packets do arrive or not, like RemoveObject, ChangeLevel etc. UDP alone isnt enough, I needed some reliability.

So i tried to implement a thin layer on top of UDP by following this great article: http://gafferongames.com/networking-for-game-programmers/

Still, although it's being great to learn low-level networking, its also very hard and I've grown tired, so i looked up for a good alternative and found Kryonet.

Kryonet is said to handle both UDP and TCP requests at the same time, by using two ports (although apparently a single port for both protocols can be used...).

My initial idea (which seems more logical for me) would be to send via UDP the packets with info about object state updates and other real-time dependent information, whilst using TCP for object creation, removal, state-changes or even eventually chat-messages.

Still, every example i saw until now only uses TCP even for real time games, which i find odd when every article i read about game networking strongly discourages such.

I also do not understand how UDP and TCP work at the same time since the article states:

The problem is that since TCP and UDP are both built on top of IP, the underlying packets sent by each protocol will affect each other. Exactly how they affect each other is quite complicated and relates to how TCP performs reliability and flow control, but fundamentally you should remember that TCP tends to induce packet loss in UDP packets.

Please explain how is Kryonet supposed to be used on game networking and why it should be used in such way regarding common knowledge about both protocols.

Summary of TCP and UDP

  • UDP: Sends packets as fast as it can and never checks whether or not the packet has been received. Order is not important either.
  • TCP: Packets will be verified and an acknowledge must be received by the endpoint. Packet order matters.

Answer

Yes, it was discouraged to use TCP in the past for real-time games. It still is, to a certain extend, but for many reasons, TCP is acceptable:

  • TCP guarantees the packets will be received by the endpoint. This will limit the bugs in the information transmitted.
  • TCP might be slower overall, but with the current speed of the Internet network, the difference is not significant for small games. The data should be transmitted and received almost at the same rate as UDP by now.

TCP still has some downsides:

  • TCP can be slow if the ping is high. TCP always waits for an answer to a packet and if the ping is high, the time between packets can become a problem.
  • Depending on the routers and the networking libraries, TCP can apply some optimization that can annoy the programmer, Ex: Packet grouping. Some routers and libraries wait for a certain amount of TCP packets and group them before sending them. This can become a real problem in real-time games as you want your packet to be sent as soon as it is ready.

Both TCP and UDP can run just fine together on a computer, as long as both run on different ports. If you try to send TCP and UDP packets on the same port, then you will have problems like the one you quoted.

Regarding how you should use them in a game, it is up to you in the end, but here are some guidelines:

  • TCP: Important packets than must be received by the server or client in the right order, like character creation, sending the map or the enemy data, etc.
  • UDP: Fast, real-time information that can be missed some frames without affecting the game too much, like player position, animations, score, etc.

Personnaly, I would tell you to start with TCP and if you have problems with it, you can implement UDP. But, as I said, with the current speed and reliability of the Internet network, you should have no problem at all with either.

EDIT: As far as I can see, Kryonet looks like a pretty standard networking library. You can check how it works in details on their main website here: http://www.kryonet.com/. You can also google "game networking tutorial" to get a more general idea.

  • Ye, the best of both worlds would be a TCP without the in-order feature, which in games screws everything by blocking most recent data to be processed if old data failed to arrive... It should be toggleable, like Nagle's algorithm and the keep-alive, but unfortunatly it is not and there's very few good libraries which implement such. I guess I'll try to use Kryonet with both protocols, as long as I dont spam TCP and UDP at the same time I guess there wont be much of a problem, but the best is to test i guess. Still you gave very few information about Kryonet itself :( – Xkynar Jul 10 '14 at 18:40
  • I have never used Kryonet, I have only read a bit of it on the website... I just know how Internet protocols work and what to use in a video game, that's all. Also, you said that Kryonet handles both protocol on different ports, so you can spam them as you wish, there shouldn't be any problems. – Alexandre Desbiens Jul 10 '14 at 22:13
  • Ye but id like to avoid using two ports for a single game, its already a bother to forward one port just to run the server – Xkynar Jul 10 '14 at 23:35
  • As for your edit, i already spent an entire day on google reading opinions, which is why i came to the conclusion there's not a sole answer on this subject and opinions are very different so ill just go for kryonet and see how it goes ^^ my doubt was about how to use it correctly but i guess ill just try it the way i believe it will do good, thanks – Xkynar Jul 11 '14 at 0:22
  • @Xkynar You can try Stream Control Transmission Protocol [SCTP]. It is essentially TCP with toggles and switches that you can flip to suit your needs. You can get a library that implements it over normal UDP. There is also en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol, but I'm not sure where it lies on the scale from experimental to widely-used. – user7610 Dec 24 '14 at 11:28

I am using KryoNet for a Java game i am making. I will sometimes have several hundrets of units at the same time. My approach has been to send frequent unit updates in small UDP packages and use interpolation on the client. I also rarely send larger unit update packes, also via UDP, with information that does not need to update as frequently as position and rotation. I then use TCP for important packages that i need to make sure get there.

If i try to send all my unit packages via TCP, the network can't handle it and i get an exception. So UDP is great for sending a lot of not-that-important packages.

  • That's most likely what Ill be trying to do soon. It seems the most reasonable solution. Ill tell about my results later. – Xkynar Jul 11 '14 at 14:45

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.