Why do games use udp

Yes it actually does this. Fun times! The problem with using TCP for realtime games like FPS is that unlike web browsers, or email or most other applications, these multiplayer games have a real time requirement on packet delivery. Consider a very simple example of a multiplayer game, some sort of action game like a shooter. You want to network this in a very simple way. Every frame you send the input from the client to the server eg. So in our simple multiplayer game, whenever a packet is lost, everything has to stop and wait for that packet to be resent.

On the client game objects stop receiving updates so they appear to be standing still, and on the server input stops getting through from the client, so the players cannot move or shoot.

Plus, there are packets backed up in queue waiting for the resend which arrive at same time, so you have to process all of these packets in one frame. Everything is clumped up! This is just what it takes to make the unreliable, packet-based internet look like a reliable-ordered stream. We want our data to get as quickly as possible from client to server without having to wait for lost data to be resent.

For realtime game data like player input and state, only the most recent data is relevant, but for other types of data, say perhaps a sequence of commands sent from one machine to another, reliability and ordering can be very important. You are right, so you may be tempted to create one TCP socket for each stream of commands.

On the surface, this seems like a great idea. 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.

For more information, read this paper on the subject. Maybe you can implement reliability in a more efficient way that TCP does, better suited to your needs? Keep your game protocol running over UDP so you are fully in control of the data you send and receive and how reliability, ordering and congestion avoidance are implemented. The rest of this article series show you how to do this, from creating your own virtual connection on top of UDP, to creating your own reliability, flow control and congestion avoidance.

Network Next is fixing the internet for games by creating a marketplace for premium network transit. Gaffer On Games Articles. UDP vs. UDP Instead of treating communications between computers like writing to files, what if we want to send and receive packets directly? Then add in chat messages to the mix. The game server is already handling intensive gameplay experiences — physics, graphics, sound. To add in chat messages — one-to-one, group, team — parsing and routing the messages to the correct users — all these messages slowly build up for large-scale games, and hurt the overall performance of the game.

It is stealing important processing power that could be better suited for more complex problems than routing chat messages. Fast-paced multiplayer games first person shooters, arena games, etc , use the UDP protocol to sync player movement and update game state.

UDP is ideal for sending these game updates at a ridiculously fast speed, but messages are not guaranteed because the next message is coming so fast behind. TCP guarantees message delivery, which makes it a great option for chat. However, for less intense multiplayer games, like turn-based games, TCP is a suitable option for both gameplay and chat.

Latency is another thing to consider, as there are different standards of latency for multiplayer functionality vs. For a multiplayer game, ensuring game state and delivering player inputs, the industry-standard is no more than 20ms.

Whereas for a chat application, the maximum latency for delivery of a chat message is ms. Running chat as a standalone service, and picking an industry-standard protocol XMPP , WebSockets or a hosted-service PubNub opens up the opportunity to easily add new powerful social features.

Start with core chat, allowing users to individual and group chat. In minimal code, you can add table stake chat features like typing indicators, user presence to show what players are online and offline, and unread message counters — features that are expected by users.

Game studios big and small are moving towards this architectural design, including Pocket Gems , and more recently EVE Online. From better scalability and more efficient performance, to the freedom to innovate without being locked into a single stack, the benefits are clear — separating chat from your game servers is the way to go.

With PubNub Chat, you can easily implement in-game chat as the basis for robust social features, letting you focus more on your core game development and less on scaling and maintaining social infrastructure. You need to enable JavaScript to run this app. All we are asked is a port to use for the net socket, and the actual message we want to send. Also, it's reliable, meaning if some packets are lost along the network they are detected, then sent again taking care of sending them in the same order they were supposed to arrive.

On the other hand, UDP is a protocol oriented toward user control. Also, when a packet is lost it is neither going to be detected nor sent again. At this point, TCP would look like the ideal solution to all our problems. It's reliable, it's fast, it solves connection latency for us by keeping track of what packets arrived and what packets we still need to send. BUT , look beyond. The only advantage UDP gives us is its speed, and that's right the one thing we really want.

A UDP packet is just crafted, sumchecked and sent without any particular controls, because that's how UDP protocol works. A TCP packet must be crafted, labeled, sumchecked, and when it arrives an ACK is sent back to tell the sender "packet x is here, keep going" , and when this signal is not sent then that means such packet x must be sent again. Yes, but not only. UDP is largely preferred over TCP mainly because its high speed is idea to handle high data sending and management.

This happens when, assuming such videogame runs on deterministic lockstep what happens on the server is identically replicated on any client independently of network latency , an update packet is lost and never get to its destination. TCP would re-send such packet, and the following packets are dropped because arrive not in order, and are then re-sent after the lost one. UDP is much more tolerant in this scenario: it won't care about this packet, because newer updates are coming.

The update lost is not rendered, instead game physics is interpolated upon integration method used and latest update received. Well, yes, it is and it will for a long time. 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:. Just that it doesn't happen precisely when you want it to happen. UDP does none of these. It fires upon your will, just that one cannot expect it to hit each time - insead the target must announce that "you haven't shot in a long time, why?

One can still create own custom ACK packets, put multiple records in a single packet, etc. And also important, control NAT traversal. UDP is most certainly suitable for games with low latency demand. That's simply not likely to happen, for multiple reasons. One is that TCP simply has more bits. So if equipment can effectively process a certain number of bits per second, that will permit more UDP packets than TCP packets.

This requirement introduces additional overhead that UDP doesn't handle. There's a reason why most of your Internet communications start with some UDP communication. TCP's feature of keeping track of lost packets is rather unexciting, because a computer could simply make a new request rather than trying to let a remote system know that there is an unfulfilled prior request.

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 :. Assuming there wasn't an update needed right before it, the time when that singular update arrives in 1 vs 2 wont be very different.

It's one trip from the server to the client. But, say instead of just a bomb going off, you are trying to continuously relay the activity of someone running through a maze; weaving, ducking, shooting, etc. In the case of UDP, every action will be sent in a datagram, as soon as it happens. In the case of TCP every action will be sent in a packet only if the server is allowed to send. What says it's allowed to send? Having room in the TCP window assuming delayed ack is active so that the message can be put on the wire.

If not, it has to wait for an ack to arrive from the client before sending. How long is too long? When multiplayer first person shooter development hit it's stride back in the late 90's and early s low latency connections were not common.

A dialup modem would have a typical one-way latency of ms. Waiting around for an ack before sending another update, effectively doubling that time to ms, was painful; even novice users could definitely feel the difference.

When broadband connections caught on, they brought the latency down a lot but it still persisted when bandwidth was in short supply quite often in some areas. So the preference for lowest possible latency persisted. Modern home connections and interconnections have changed this, to the point where regional latency, even during congested times of day, are in the 15ms or below range.

So, for now and probably some time into the future UDP will be preferred for real-time communication. 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?

Your assumptions are wrong. TCP and UDP differ primarily in what model they represent unreliable datagrams versus in-order reliable virtual stream. They do not differ in respect of volume "high data usage" or throughput. In presence of packet loss, the two do differ in latency, but only in that condition. Otherwise, TCP has just as low latency as UDP give or take maybe a few dozen nanoseconds because the network stack has slightly more logic to do, but that's rather neglegible.

There is a slight difference in header size, so technically, more bytes must make it over the wire on serial lines, but that one is rather inconsequential, too. It only really matters for bulk transfers, and then it's about a 0. Some people build reliability on top of UDP. If some level of reliability is desired, but strict in-order deliverance is not needed, that may give a small advantage. However, it is still debatable whether the approach makes a lot of sense, and you pay a hefty price for that small advantage.

If you have clients connecting from hotel WiFis or other "weird" places, you will notice that often overall support for TCP is much, much better than for UDP. Games generally use UDP not because it is superior in one of the forementioned ways -- it isn't -- or because you can reduce jitter by half a millisecond by implementing reliability without in-order, but because games much like IP telephony often contain a lot of very volatile data, such as for example position updates.

This volatile data is regularly and quickly obsoleted both by time passing, and by the next datagram coming in. Assuming a network packet is dropped in a service which runs at a steady pace with frequent updates coming in shooter game, telephone, video chat it does not make a lot of sense to have the acknowledge time out and resend the packet, and meanwhile freeze everything on the other end while waiting for the resent packet to arrive.

That's way too disturbing, and no good. Instead, you just consider the packet lost and move on, taking the data from the next packet that makes it through and meanwhile, to the best of your ability, hide the fact that a packet was lost from the user.

Interpolation, dead reckoning, you name it. Note by the way that packet loss is a normal condition. While IP is generally "quite reliable", packets occasionally being dropped can happen, and will happen. It is perfectly normal. Every TCP bulk transfer will necessarily include lost packets, for example it's how the congestion control works. In a high bandwidth MPG, you don't care if you missed a packet giving you the location and health of monster , because you'll be getting another update in some fraction of a second.

In that same game, you want the patches to show up exactly as they were designed. TCP already has the "tell me if it fails" features built in, facilitating automatic retries and verified failures. You can do it in UDP, but why recreate the technology? Make a packet from the front of the stream. Encapsulate in IP. Wait for space in the TCP window. Ship it. Keep reshipping until a receipt is received or timeout.

Stay in the TCP window until a receipt is received or timeout.