Hot answers tagged

120

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. TCP creates an abstraction in which all network packets arrive, and they arrive in the exact order in which they were sent. To ...


32

This is a form of the Two Generals Problem, and you're right - no number of retries is enough to perfectly guarantee receipt. In practice in games, there's usually a time horizon beyond which the information doesn't really matter though even if it technically arrives reliably. Like finding out you had a perfect headshot lined up 2 seconds ago - it's too ...


19

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 ...


9

Not even home PC based action games or big MMOs run their packets at 60Hz. Plus having really small packet sizes is not necessarily a great thing, each one of those tiny packets has a big overhead in just sending it out. Try shooting for 10Hz updates with some client-side interpolation. I assume that you're already interpolating because there will always ...


9

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 ...


9

The approach TCP uses is that the sender will keep resending the packet until it receives an acknowledgement. The receiver will ignore duplicate packets, but still send acknowledgements for them. The sender will ignore duplicate acknowledgements. If a packet gets lost, the sender resends it, as you already know. If an acknowledgement gets lost, the sender ...


8

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 ...


7

Even though you are sending data using UDP, you will still need to add in your own form of reliability to handle situations like this. UDP just gives you the flexibility to do what you want, rather than deal with the reliable but less flexible format of TCP communication. Confirmation messages, or acknowledgement packets of a sort should be used when receipt ...


7

It turns out that this is due to how powersavings in mobile phones work. For my iPhone, sending a steady stream of UDP pings every 200 ms will keep the interface open, and give me a RTT of 80-100 ms. Reducing the ping frequency will drastically increase the RTT, to an average of about 400 ms. Further reducing frequency causes the RTT to occasionally go even ...


7

First, you have to make sure how big the entire data is. Your ISP will most likely care about actual bytes sent, not the amount or frequency of datagrams. If you're sending maximum (65507 payload octects) sized datagrams 60 times per second, you're sending around 30 Mb/s upstream. Not everybody has that kind of connection. Remember that the IP header is 20 ...


6

Okay, first of all, if you have something and it's working, it's usually a good idea to leave it like that. Why fix what's not broken? But if you're having trouble, and would really like to rewrite your networking code, I think you have four main choices: Multithreaded blocking code (what you're doing right now) Non-blocking sockets with level-triggered ...


6

If you want to reinvent TCP, it makes sense to look at TCP first, which deals with the exact problem you describe (part of the solution is to use user defined values for retry attempts and timeouts). Solutions that use 2 channels, a TCP channel (for reliable communication) as well as a UDP (for low latency communication) channel are not uncommon. Some ...


5

In a multiplayer game, every gameplay-relevant decision should be made by only one system. When multiple systems make a decision, like in your case the trajectory of the ball, and they disagree due to timing issues, the game gets out of sync. When each client calculates the angle only after its own collisions and sends the new trajectory of the ball to the ...


5

While the server has the final say on the position, it should do that by verifying and sanity-checking what the client sends over as the inputs and position. I say this because what you're doing is moving the player immediately and the expectation that creates in your code is that the client is the real position. You think it generally works well, but it's ...


5

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 ...


5

According to the answers on this page, about 512 is a safe amount for ipv4 because nearly all consumer's hardware will be able to support that size. For ipv6, 1500B is the maximum safe packet size. Subtract 40 + 8, the ipv6 and UDP header sizes, and you get 1454B maximum data inside that packet. If you send something over the limit, it's most likely going to ...


5

You should implement your UDP reliable as TCP. On http://gafferongames.com/ you can read about packing packets, resending them, correcting errors. There is some pseudo-code (or this is written in C, I don't remember now) - which explains everything well. Let's say that you have a struct (or a class) with currently pressed keys: class Input{ boolean ...


5

When it comes to chat systems, reliability is far more important than latency and bandwidth. That would usually make it a typical TCP/IP use-case. However, using both TCP and UDP in parallel through the same network can cause more UDP packet loss and adds additional complexity to your application. So it might be smarter to add some optional reliability ...


4

They can be as late as "never arriving at all." As far as what you can expect, the elapsed time drops off pretty sharply. You can assume that 99% of the time, you'll get your packet within some time x (if you're going to get it at all), but there will always be a possibility of some stragglers. Your actual value for x can be determined by experimentation, ...


4

3G is optimized for stuff like streaming video. It's terrible with regard to latency when talking about small bits of data. There's a reason multiplayer mobile games over 3G with split-second timing don't exist.


4

One reason you might prefer UDP over TCP is to save bandwidth. The drawbacks are obvious: if data gets lost on the way neither the sender nor the recipient will notice. In addition, the order of packages may change if they take different routes in the network, which would result in clients seeing wrong "combos" (e.g. Left-Down-Punch instead of Down-Left-...


4

Here's a quote by Sam Jansen from a comment on gafferongames.com: Speaking as a network researcher and not a game developer, the conclusion to never use TCP and UDP together seems a bit strong. TCP will only have packet loss if it is sending too much data; in some ways just like the UDP data you are sending. The difference is you have no direct control on ...


4

Update These are the lessons learned from fixing this problem: We found the following issues when reviewing the network code: [Client/Server] UdpClient.Receive alters the IPEndPoint you pass to it by reference. So, do not use the same endpoint you use for sending. [Server] We needed to use ReceiveAsync on the server to be able to interrupt it. Which we do ...


3

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 ...


3

The UDP port is only going to overflow if your program cannot handle the number of incoming packets at least as fast as they are being sent to your PC. While TCP will lead to your program itself needing to inspect less packets (since you only get reliably ordered packets and the rest are discarded by the networking level) I do not believe that I have ever ...


3

Many games use both UDP and TCP/IP for sending/receiving data and depending on how often the data is sent, different protocol is used. For example: UDP: positional updates, and anything else that could potentially be sent/received multiple times per second. TCP/IP: inventory actions, spell/ability actions, (most user performed actions) It really depends ...


3

You can also work around the problem by sending a full state update from the server to the clients, say every second. If a client did not receive a packet, it will behave incorrectly until it receives the full state update. Then it will be in sync again.


3

always double check on the server, don't allow teleportation through position but instead ensure the speed isn't too large you can ensure authenticity by having the client keep a counter and encrypt it together with UID with a prearranged client-specific secret (also send the unencrypted counter to account for lost packets)


3

First off, you misunderstand how UDP works: Lets say you send a 2500 byte packet. It will get fragmented into two separate packets and then reassembled transparently on the other end. UDP datagrams are atomic. An UDP datagram will not be split up into packets. I recommend sending the data in small atomic datagrams. The overhead is typically 28 bytes, ...


3

Those packets are still late. Even if you send 1M packets every second, there is still lag. Certain packet is packed at time t1 and it arrives at t1+ping/2. You send positions of other player to everyone. I assume you then do something like this: player[4].Position = new Vector2(readNextPlayerX(),ReadNextPlayerY()); You set that coordinate you sent, ...


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