Hot answers tagged

125

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

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

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


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


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


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

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


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

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

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

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


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

You should be able to use java without any performance problems, the technology went way past that. Although services that work with massive number of clients still use c++. As for your choice of sockets, it's not a matter of performance, as people usually think, it's about what are you going to use them for. On game servers you don't care if messages are ...


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

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


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

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


3

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


3

When the user presses the button to enter panic mode, generate a sequential ID to tie to that event of wanting to enter panic mode. You then periodically send a message to the robot "Activate Panic Mode" with that sequence ID value you generated. Whenever the robot receives an "Activate Panic Mode" message, have it respond with "Panic Mode Activated" with ...


3

In an RTS you really cannot use a protocol like TCP, and you cannot make UDP reliable either. If you try to, the game will freeze whenever a there is a network hick-up. Instead, you design the protocol so that missed packets don't matter too much. The short version is that you don't care where the other players were last frame as long as you know where ...


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