Hot answers tagged

105

No, UDP is still superior in terms of performance latency, and will always be faster, because of the philosophy of the 2 protocols - assuming your communication data was designed with UDP or any other lossy communication in mind. If you send 2 updates on TCP, and a packet of the first update gets lost, you will not see the second update until: The loss of ...


17

We agree upon both TCP and UDP being protocols built on top of IP, don't we? IP specifies how messages are delivered across the internet, but nothing is about the messages structure, format. Here come TCP and UDP protocols. They use IP properties, but let the programmer focus on the message exchange without worrying about the lower layers of net ...


7

TCP <- Transmission Control Protocol. It's made to control transmission. TCP was created to be a good and diplomatic network citizen. It focuses on making the networking a good experience for everyone, and willingly decreases it's throughput to achieve that. It adjusts to the environment by adding latency. Reasons are for example: Receiver detects a ...


4

It results in packet loss for UDP due to contention between the two protocols - remember that UDP is not guaranteed delivery, while TCP is. More TCP packets will get through while UDP suffers - TCP induces UDP packet loss. There has also been the (historical) idea that router infrastructure favours TCP over UDP, though I doubt that is still true by this late ...


3

I would use UDP since it has lower latency. When a packet is lost, UDP carries on with the next packet instead of waiting for the previous packet to be sent. UDP will also reorder packets, since it is just sending blocks of data, not a stream like TCP. You would need to track the packets as you will have to manually sort the order of the incoming data. ...


2

Is this a reasonable idea? Yes What are the possible drawbacks? Packet Loss, more code complexity, another connection to manage == more chance for disconnects, time outs, exceptions, whatever ... Are there better ways to handle this? Use an existing Reliable UDP Library. Two of the most popular are: Lidgren Network (C#), RakNet (C++). From ...


1

In a high bandwidth MPG, you don't care if you missed a packet giving you the location and health of monster #425, because you'll be getting another update in some fraction of a second. This is and example where UDP makes TCP look stupid for making you wait for instantly obsolete data. In that same game, you want the patches to show up exactly as they ...


1

Consider what's happening for a moment. To simplify the scenarios, you have two choices when trying to send a state change (like your player just changed direction, or shot a gun, or some other player just set off a bomb): Keep a TCP session open, and when the bomb is to go off send a TCP message to all players (if possible, see below) Keep a UDP port ...


1

You may compare the first diagram of RFC 768 (UDP) to the first diagram of RFCP 793 (TCP) page 15. Both show 16 bits for a “source port” followed by 16 bits for a “destination port”. Both show 16 bits for a “checksum”. According to RFC 768, UDP's “checksum procedure is the same as is used in TCP.” Whereas ...


1

I know that UDP is usually recommended for real-time multiplayer games with high data usage Is UDP still superior in terms of speed and latency? Could recent TCP optimizations have made TCP perform better than UDP? Your assumptions are wrong. TCP and UDP differ primarily in what model they represent (unreliable datagrams versus in-order reliable ...


1

I can't speak for Google play services, but between the embedded LibGDX networking and Kryonet, I would suggest Kryonet. After all, it was written partially by the authors of Libgdx :) . It's also a big plus that you can integrate kryonet using gradle. By "Libgdx's embedded networking" I assume you mean the sockets that Libgdx provides. Kryonet handles all ...



Only top voted, non community-wiki answers of a minimum length are eligible