| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| en:network_terms:udp [2022-04-01-23-39] – ↷ Page moved from en:games:network_terms:udp to en:network_terms:udp 7saturn | en:network_terms:udp [2022-04-02-13-10] (current) – 7saturn |
|---|
| ====== User Datagram Protocol ====== | ====== User Datagram Protocol ====== |
| The user datagram protocol, or short UDP, is a network [[..:protocol]], that is widely used for computer games. The communication does use a [[network address]] and a [[port]], but in contrast to [[TCP]], the communication is connection less, meaning, it does not have any state, that defines whether the communication is "connected" or the connection being "established" or data being received or correct. | The user datagram protocol, or short UDP, is a network [[..:network terms:protocol]], that is widely used for computer games. The communication does use a [[network address]] and a [[port]], but in contrast to [[TCP]], the communication is connection less, meaning, it does not have any state, that defines whether the communication is "connected" or the connection being "established" or data being received or correct. |
| |
| UDP's disadvantages are, that it is not really reliable. A package may arrive its destination or not. No one will ever know for sure, neither the sender nor the recipient. Also the data might get corrupted on the way. There are no check sums to find out. So in essence, when there is no reply from the other side, you do not know, whether the recipient is not even there, your packages are just not reaching the destination, are received as unreadable, or the other way around, the answers are not reaching you properly. It's like throwing a message in a bottle into the river, hoping it will get to the desired person, which can read it and will be there to receive the message. That makes UDP difficult to diagnose, when something goes wrong. | UDP's disadvantages are, that it is not really reliable. A package may arrive its destination or not. No one will ever know for sure, neither the sender nor the recipient. Also the data might get corrupted on the way. There are no check sums to find out. So in essence, when there is no reply from the other side, you do not know, whether the recipient is not even there, your packages are just not reaching the destination, are received as unreadable, or the other way around, the answers are not reaching you properly. It's like throwing a message in a bottle into the river, hoping it will get to the desired person, which can read it and will be there to receive the message. That makes UDP difficult to diagnose, when something goes wrong. |
| |
| On the other hand it has the advantage of being very fast. No handshakes being done to establish a state "connected". No reply that a package has arrived and no waiting for data from the sender. No check-overhead for garbled data, no re-send data if not received. (See also [[TCP]] on the matter.) This is precisely why UDP is used in fast paced communication, as computer games require them. There is little point for a [[..:gaming_theory:shooter]] [[server]] to wait for the [[client|client's]] packages while the game simply continues. It would take too long. Also latencies are important. The faster the better. This cannot be done via [[TCP]] in a fast fashion. As modern connections are mostly reliable, speed for possible information loss is an acceptable compromise. This is also, why cable connections, which are known to be more reliable than wireless connections, give a better performance when it comes to [[loss]] and [[..:lagg]]. | On the other hand it has the advantage of being very fast. No handshakes being done to establish a state "connected". No reply that a package has arrived and no waiting for data from the sender. No check-overhead for garbled data, no re-send data if not received. (See also [[TCP]] on the matter.) This is precisely why UDP is used in fast paced communication, as computer games require them. There is little point for a [[..:gaming_theory:shooter]] [[server]] to wait for the [[client|client's]] packages while the game simply continues. It would take too long. Also latencies are important. The faster the better. This cannot be done via [[TCP]] in a fast fashion. As modern connections are mostly reliable, speed for possible information loss is an acceptable compromise. This is also, why cable connections, which are known to be more reliable than wireless connections, give a better performance when it comes to [[loss]] and [[..:network terms:lag]]. |
| ===== See Also ===== | ===== See Also ===== |
| * [[..:protocol]] | * [[..:network terms:protocol]] |
| * [[TCP]] | * [[TCP]] |
| * [[IPX]] | * [[IPX]] |
| |
| [ [[..:games_database]] ] [ [[..:game_related_terms]] ] [ [[..:network_terms]] ] | [ [[..:Games Database]] ] [ [[..:Game Related Terms]] ] [ [[..:Network Terms]] ] |
