0
\$\begingroup\$

This is a Java related question.

I've got this question and I searched on the internet but didn't really get any clear answer.

I want to develop a little multyplayer game which needs real time synchronization for a few clients. I don't really want to have a lot of clients, but I want to have the chance to create it for a greater scale later.

Seeing through some Links (also given here from stackexchange) I got the answer that UDP would be better, then others say TCP. I know it's sometimes more an opinion thing what you prefer most for yourself.

But I've developed some network games in the past (not proffessional ;) ) and used TCP. And I didn't really get a lagfree game, even for three clients (players)

I then used the new nio (asynch) network framework of java, but the lag just reduced a little bit.

So how can I develop a reliable Server-Client model? Using TCP or UDP? Or did I just end up developing a bad example and thats why my server-client communication lagged?

If someone has a good tutorial for developing a reliable java game server that would be nice.

Thank you

\$\endgroup\$

closed as off-topic by bummzack, MrCranky, Trevor Powell, MichaelHouse Jan 21 '14 at 14:41

This question appears to be off-topic. The users who voted to close gave these specific reasons:

  • "Questions about "how to get started" or "what should I learn next" cannot reasonably be answered with anything other than opinion polling and therefore are off topic for the site. For more information on how to ask a better question, see the help center" – MichaelHouse
  • "Questions that are about "which tech to use" are outside the scope of the site. For more information, see this meta post" – bummzack, MrCranky
If this question can be reworded to fit the rules in the help center, please edit the question.

3
\$\begingroup\$

When I started looking at Network programming, I found the blog of Glenn Fiedler an excellent source of knowledge about real time network programming. He's starting with a broad discussion of whether to choose TCP or UDP for your game and covers details in later posts.

This would give you a starting point in the UDP vs TCP topic from a professional game developer (used to work for Sony, now working for respawn entertainment) but he is focussing on C++. So this is just for the abstract part of the question, not really helping with the Java part.

\$\endgroup\$
  • \$\begingroup\$ Well the Java part is not that much of a problem because I already know how to use the different protocols with their given classes. But my problem, and with this article its the same, is that this article and a lot of other questions about tcp vs udp started a huge discussion about tcp evangelists vs udp evangelists :D. And concerning my older work which lagged really fast using TCP I'm just not sure if I just developed bad or used the wrong protocol \$\endgroup\$ – Loki Jan 21 '14 at 8:09
  • \$\begingroup\$ I think the basic idea that Glenn wants to bring across is that if you want to have the latest information available, then reliability of messages like TCP does is in your way. Resending messages without your notice that are not of importance anymore is likely to slow your game down. That's why he wants to implement a protocol where he gets to decide which information is requested again and which is dropped. And only UDP can do that. That's the short version of his blog book ;) \$\endgroup\$ – HaMster Jan 21 '14 at 8:19
  • \$\begingroup\$ aka TCP assumes you need all data on the other end and sacrifices some speed and bandwidth for it, while with UDP you can decide \$\endgroup\$ – ratchet freak Jan 21 '14 at 8:50
  • \$\begingroup\$ @Loki You should evaluate pros and cons of both for your case and then decide; you should not just try and say "good" because you may (will) have surprises in future. Regarding "evangelist", TCP and UDP are both tools not deity, again you can use a flathead screwdriver for a cross head screw if you have to but you sould not say that flathead will rule all screwdrivers :) \$\endgroup\$ – FxIII Jan 21 '14 at 8:51
  • \$\begingroup\$ I did a lot of research on this. Open a TCP port and use it as a fallback in case UDP problems crop up. Send throwaway data over UDP and reliable data on TCP, but don't use both at the same time as TCP will eat all bandwidth of UDP. Adds a ton of complexity for a ~30% increase in ideal scenarios, assuming you're doing everything right. It's not very straightforward. \$\endgroup\$ – person27 Sep 9 at 0:18
3
\$\begingroup\$

Some of the multiplayer games I have worked on used both. That is, TCP for messages that must be delivered, and UDP for information such as position updates where if one is missed the next one will be coming automatically. My own personal rule of thumb is if the information is something that I would ask to be resent if it were missed, to just use TCP.

One sneaky thing to check for lag with TCP is whether you have Nagling disabled. When Nagling is enabled and the client is sending TCP messages to the server frequently, with the server sending messages to the client less frequently, you probably won't notice much lag. If you have a situation where the server is sending more messages than the client is it can be a noticeable 200ms lag when Nagling is turned on. That is, the server will wait 200ms to send messages to the client unless the client sends a message. Check your client code as well to make sure it isn't Nagling the outgoing messages.

\$\endgroup\$
  • \$\begingroup\$ +1 for the pragmatic approach, I used this way in my projects \$\endgroup\$ – HaMster Jan 21 '14 at 15:44

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