[Sinned]

Hello everyone,

I was wondering why UDP is used so much.
I mean I understand UDP is faster - with its much smaller headers.
But I think the risks on UDP can't compare these benefits.
(Risks: packages could get lost, so server and client would run asynchronous)

http://en.wikipedia....tagram_Protocol:

Common network applications that use UDP include: the Domain Name System (DNS), streaming media applications such as IPTV, Voice over IP (VoIP), Trivial File Transfer Protocol (TFTP), IP tunneling protocols and many online games.

- When a DNS request/answer gets lost, and the client doesn't receive an response, the client could think the domain doesn't exist and goes on.
- Streaming media: when a identifying frame of a video gets lost, many frames - which gets well delivered after it - aren't shown properly.
- When on an online game a package will never be delivered, the client could run asynchronous on the server. Example: First person shooter - the server thinks the user has got the model for a specific gun, but the client hasn't got it. This will result in in-game glitches. (Many people hate glitches)

So this is my opinion about UDP connections.

I should like to hear from someone, who knows anything about it, why UDP is so much used, regardless its risks.
Or maybe someone else who really don't agree with me.

Thanks,

Sinned

[jimblumberg]

Not a C/C++ question, moved to Software Development.


Jim

[jimblumberg]

UDP is used as you said for speed where the dropping of packets can be tolerated. For example:

Quote

- When a DNS request/answer gets lost, and the client doesn't receive an response, the client could think the domain doesn't exist and goes on.

With DNS the loss of packet is not a serious issue, most applications that use DNS wait for a specific time for their requested packet if it doesn't appear in the allotted time the application retransmits the request, or takes appropriate action. This is really useful when dealing with a busy Name Server.

Quote

- Streaming media: when a identifying frame of a video gets lost, many frames - which gets well delivered after it - aren't shown properly.

Does it really matter if a few packets are not received? Unless the loss gets very severe you will probably not even see a difference.

Quote

- When on an online game a package will never be delivered, the client could run asynchronous on the server. Example: First person shooter - the server thinks the user has got the model for a specific gun, but the client hasn't got it. This will result in in-game glitches. (Many people hate glitches)

Many online gaming packages, that use UDP do their own error checking, and do not want to rely on a method that insures reception, but reduces the overall speed.

Quote

Trivial File Transfer Protocol (TFTP)

This protocol has it's own error checking and does not require the underling protocol to insure reception.

Jim

This post has been edited by jimblumberg: 18 February 2012 - 11:53 AM

[ccubed]

The potential loss of packets in a UDP connection for the services you listed, as jimblumberg mentioned, is acceptable and likely won't result in a large difference when using it. In fact, in the case of VOIP or Streaming Video, for instance, the loss of packets is expected and rather than stopping a video because of losing a couple of packets, they continue on with the call or video. This isn't going to affect your phone call or viewing, but stopping to take the time to 'reconcile' so to speak those packets will.

The reality is that packet loss, unless in a large amount, typically doesn't affect most applications that rely on information transmission and reception.

Edit: However, in some other cases, such as HTTP or P2P, the loss of packets, any at all, could result in a bad file or misaligned information. Especially in the case of downloading a large file over the internet through P2P, missing any information in that file could result in the file just not working. In these cases, the long delay that can typically occur with TCP is acceptable because it's necessary.

This post has been edited by ccubed: 18 February 2012 - 01:21 PM

[blackcompe]

Quote

I mean I understand UDP is faster - with its much smaller headers.

Don't forget about not having to handshake to establish/terminate a connection, not having to create more network congestion by sending acknowledgement packets, and not having to do error checking and maintain connection state in the OS's TCP layer (probably not that significant).

This post has been edited by blackcompe: 18 February 2012 - 01:38 PM

[Bench]

Delivery of UDP packets are "unreliable" because there is no built-in acknowledgement/re-send mechanism; however that's not the same thing as saying "the packets won't get there" - because they almost certainly will if you've got a good network connection (or at least so many of them will that any reduction in overall quality of audio/video/etc will not be noticable).

If, on the other hand, you have a network connection which is very jittery, prone to disconnects, or otherwise poor quality, then changing the type of data packet you choose to something with built-in reliability isn't going to help, because you're probably talking about the kind of packet loss or data corruption which would easily ruin the "streaming" audio/video/gaming/etc experience regardless.

Often, real time applications send data in the form of self-contained "updates" (a bit like 'mini-snapshots') which do not make any assumptions about other packets which may or may not have been recieved at the client end.
Real time applications usually take a different philosophy on network traffic - If one update/snapshot gets lost, it's not a problem, because the data contained in that update will all be out-of-date by the time the next update is sent anyway (And as jimblumberg mentioned, if a datagram is that important, the application can still build in its own error checking). it only really becomes a problem when dozens of updates are being lost every second, at which point you may as well give up, because there's most likely a physical or network problem somewhere which needs to be fixed.

Reliable transport protocols are really for the kind of data where even a single missing or corrupt byte anywhere whatsoever would cause serious problems. e.g. downloading a compressed archive over FTP - a single byte missing somewhere in the middle could be the difference between the file being usable or complete garbage. People will happily take a slower download speed if the alternative is either being left with a corrupt file, or being unable to download at all because their network/provider is having a bad day. Things like files, webpages, etc can't be represented over the network using simple "updates", since they are complete static entities which aren't changing with time - therefore a reliable transport mechanism is the only reasonable option.

This post has been edited by Bench: 18 February 2012 - 01:52 PM

[Sinned]

Very nice explanations/theories all of you.

But to be honest: I'm not completely satisfied.

DNS:
Yeah, for things like DNS servers it could work, because the client sends 1 package and knows it has to receive 1 packet.

Video streaming:
But for video streaming the client doesn't know how much packets there are, and if one is missing. As you told: when only 1 frame should be missing this wouldn't be much trouble. But I was talking about an identifying frame. I'm not very familiar with video techniques, but I've heard once a video isn't build of millions of images. It's just an base images, and on every next frame are made changes to that base. (This gives less data consumption) And after a while there is a new base image. But so if there is missing a base image, there could be many incorrectly implemented frames after it. (Which are well sent over)

So sometimes there are very important packages missing. Even if there is only a loss of 0.1%, the risk is present there are many packages after it are useless.

Online games:
And to get back to the games: Of course the risk is so tiny the loss almost wouldn't offset against the overall speed. But as in my example a client could miss the "specific gun", so one client could see an enemy running like wielding a gun, but he hasn't got one. And then he gets shot by a bullet from an unseen gun. (This is just a small example, but there could appear bigger glitches, like you are running like you're on some hills, but you see like you are in a battlefield. Just because you didn't receive the new map, and the server handles you for the new map.)

Own error checking:
I don't understand how error checking on UDP is possible. By TCP when a between lying hub couldn't bring the package any further it sends back an error message. But with UDP when a between lying hub couldn't bring it further it drops the package. So the error checking is with TCP intergrated in the "between-lying-hubs", this part you can't do yourself. The only error checking you could do on UDP is checking if you get the package - which you can only know if you know there has to come a package. This is what I think about it.

Accountability:
To be clear: I'm not an enemy of UDP, I'm just interested in those protocols, so I maybe could use it myself. But before I gonna use it I have to be certain it could work well.

[Bench]

Sinned, on 18 February 2012 - 10:28 PM, said:

Video streaming:
But for video streaming the client doesn't know how much packets there are, and if one is missing. As you told: when only 1 frame should be missing this wouldn't be much trouble. But I was talking about an identifying frame. I'm not very familiar with video techniques, but I've heard once a video isn't build of millions of images. It's just an base images, and on every next frame are made changes to that base. (This gives less data consumption) And after a while there is a new base image. But so if there is missing a base image, there could be many incorrectly implemented frames after it. (Which are well sent over)

So sometimes there are very important packages missing. Even if there is only a loss of 0.1%, the risk is present there are many packages after it are useless.

Streaming audio and video technologies are generally designed to cope smoothly with around 1% data loss/corruption without any significant loss of quality. There are different streaming technologies around, and they each build different mechanisms to handle these errors; sometimes the error handling means that the software itself re-requests the data if it notices a lengthy interruption; but for individual dropped packets it will almost always have enough information to fill in the gaps with some kind of a "smoothing" algorithm (or perhaps a way to approximately rebuild the missing packets).

Audio and Video also has the added bonus that it can afford a small amount of caching time which allows a small window for data to be re-requested when there are longer interruptions. e.g. sites like youtube have a buffer for the streaming videos - if your network feed happens to dry up for a couple of seconds, you won't notice. For live broadcasts this buffer is obviously going to be smaller but there'll probably still be one.

Sinned, on 18 February 2012 - 10:28 PM, said:

Online games:
And to get back to the games: Of course the risk is so tiny the loss almost wouldn't offset against the overall speed. But as in my example a client could miss the "specific gun", so one client could see an enemy running like wielding a gun, but he hasn't got one. And then he gets shot by a bullet from an unseen gun. (This is just a small example, but there could appear bigger glitches, like you are running like you're on some hills, but you see like you are in a battlefield. Just because you didn't receive the new map, and the server handles you for the new map.)

This comes down to the design of the game; One of the things about packets is that they can be easily hijacked using something like WinPCap (Wireshark is a good example of a very useful packet sniffer for Windows).

If packets travelling from the client to the server contained critical information (or if the client were trusted to do the calculations for important events), then the game would be extremely vulnerable to anyone who fancied hijacking packets and inserting their own data. e.g. I decided I want a million health points and the SuperBigGun with 20000 ammo - if the server puts its trust into the data it recieves over the network, then all I have to do is spend a little time figuring out what the game's internal events look like with Wireshark, and I can create my own super cheat!
But networkable games and simulations usually don't work that way - the data contained in the packets is fairly mundane stuff of relatively low significance. Typically, updates from the client might contain user input events (e.g. "The client has the 'go forward' input pressed down" or "The client has the 'attack' input pressed down" - any calculations which actually affect the state of the game will probably be calculated on the server based on those recieved events.

Sinned, on 18 February 2012 - 10:28 PM, said:

Own error checking:
I don't understand how error checking on UDP is possible.

Error checking can be handled however you like, although it is done at the application layer. Typically packets may have a sequence number attached, or the client is designed to accept particular "reliable" messages at certain intervals. E.g. the client may be told that that there is an important message every 100ms, therefore if it doesn't recieve that message for 200ms then it needs to send an alert to the server re-requesting the important message. Alternatively, the client could count sequence numbers on packets - if it recieves 49,50,..... nothing... 72,73, and it was expecting some important data at packet 60, then it could send a re-request there too (or if it has been caching, it could send a re-request for every packet from 51 to 71)

If you really wanted to, you can build in TCP-style error checking into UDP - the difference between that and TCP is that the error checking is handled at the Transport layer (so typically it's done for you already!). Any error checking done at the application layer obviously needs to be written by the application developer, and the application developer needs to come up with ways of checking and handling the various error conditions

This post has been edited by Bench: 18 February 2012 - 04:31 PM

[blackcompe]

Quote

But I was talking about an identifying frame. I'm not very familiar with video techniques, but I've heard once a video isn't build of millions of images. It's just an base images, and on every next frame are made changes to that base.

I'm sure the application took into account that possibility. There's a solution for just about everything. How do you know all media formats use 'base images'? How you know the format your talking about didn't implement some kind of reliable UDP transport, that's still significantly faster, since there's no congestion or flow control?

Quote

Error checking can be handled however you like, although it is done at the application layer. Typically packets may have a sequence number attached, or the client is designed to accept particular "reliable" messages at certain intervals. E.g. the client may be told that that there is an important message every 100ms, therefore if it doesn't recieve that message for 200ms then it needs to send an alert to the server re-requesting the important message. Alternatively, the client could count sequence numbers on packets - if it recieves 49,50,..... nothing... 72,73, and it was expecting some important data at packet 60, then it could send a re-request there too (or if it has been caching, it could send a re-request for every packet from 51 to 71)

Exactly what I was going to say. You just send an initial UDP packet that requires acknowledgement. That packet could specify a number of packets to come. There could be a field with the packet numbers ORed together, so that the receiver knows of packets he didn't get.

There's no limit on what you can do atop UDP. You can essentially pick and choose what TCP-like services you want and them create yourself.

Quote

If you really wanted to, you can build in TCP-style error checking into UDP - the difference between that and TCP is that the error checking is handled at the Transport layer (so typically it's done for you already!)

Exactly, the big is deal is that it's all taken care of for you. It's always a priority to abstract systems programming from application developers. But sometimes you need performance, which is why UDP exists.

This post has been edited by blackcompe: 18 February 2012 - 04:25 PM

[jimblumberg]

Sinned, on 18 February 2012 - 03:28 PM, said:

Very nice explanations/theories all of you.

But to be honest: I'm not completely satisfied.

Nothing new here, are you ever completely satisfied?

Sinned, on 18 February 2012 - 03:28 PM, said:

Video streaming:
But for video streaming the client doesn't know how much packets there are, and if one is missing. As you told: when only 1 frame should be missing this wouldn't be much trouble. But I was talking about an identifying frame. I'm not very familiar with video techniques, but I've heard once a video isn't build of millions of images. It's just an base images, and on every next frame are made changes to that base. (This gives less data consumption) And after a while there is a new base image. But so if there is missing a base image, there could be many incorrectly implemented frames after it. (Which are well sent over)

So sometimes there are very important packages missing. Even if there is only a loss of 0.1%, the risk is present there are many packages after it are useless.

Most of the time these video streaming applications are buffering the stream and putting the pieces together in the proper order on the receiving machine, this buffering while not eliminating data loss minimizes the number of lost or late packets.

Sinned, on 18 February 2012 - 03:28 PM, said:

Online games:
And to get back to the games: Of course the risk is so tiny the loss almost wouldn't offset against the overall speed. But as in my example a client could miss the "specific gun", so one client could see an enemy running like wielding a gun, but he hasn't got one. And then he gets shot by a bullet from an unseen gun. (This is just a small example, but there could appear bigger glitches, like you are running like you're on some hills, but you see like you are in a battlefield. Just because you didn't receive the new map, and the server handles you for the new map.)

Here to, there is usually some buffering done on the player's machine. Plus if you have ever played an online game you have heard the term "lag", especially on a heavily loaded server or with a slow internet connection. To help with the server load, the server will usually send and forget the packets, and if receiving a packet will probably just discard incomplete or damaged packets. If packets are missed by the player, then they will resend the request for the information after the appropriate waiting period.

Sinned, on 18 February 2012 - 03:28 PM, said:

Own error checking:
I don't understand how error checking on UDP is possible. By TCP when a between lying hub couldn't bring the package any further it sends back an error message. But with UDP when a between lying hub couldn't bring it further it drops the package. So the error checking is with TCP intergrated in the "between-lying-hubs", this part you can't do yourself. The only error checking you could do on UDP is checking if you get the package - which you can only know if you know there has to come a package. This is what I think about it.

See this link for information on the TFTP protocol. This link explains one very simple method of error detection, and correction.

[Sinned]

Thank you all for your explanations.

I think I'm (partly) satisfied.

UDP could be a nice protocol for my purpose. (With good error checking, and maybe in combination with TCP)

This post has been edited by Sinned: 19 February 2012 - 04:39 AM

[no2pencil]

Sinned, on 18 February 2012 - 01:09 PM, said:

- Streaming media: when a identifying frame of a video gets lost, many frames - which gets well delivered after it - aren't shown properly.

Imagine if you are playing a game & old data packets are updated. What about streaming audio/video. You'd have a bunch of garbage packets being played out of order as error correction displays old data. It would be hell.

[ccubed]

Sinned, on 18 February 2012 - 02:28 PM, said:

Video streaming:
But for video streaming the client doesn't know how much packets there are, and if one is missing. As you told: when only 1 frame should be missing this wouldn't be much trouble. But I was talking about an identifying frame. I'm not very familiar with video techniques, but I've heard once a video isn't build of millions of images. It's just an base images, and on every next frame are made changes to that base. (This gives less data consumption) And after a while there is a new base image. But so if there is missing a base image, there could be many incorrectly implemented frames after it. (Which are well sent over)

So sometimes there are very important packages missing. Even if there is only a loss of 0.1%, the risk is present there are many packages after it are useless.

Identifying Frames, AKA Key Frames, have nothing to do with playing video after it has been rendered. Depending on your FPS, we'll say 30, then there exists at any one time 30 copies of the same frame. That frame is shown 30 times per second. So, will losing one copy of that frame matter? Not likely. Will losing 10? Maybe the quality degrades, but the movie can continue. Will losing all 30? Yes, you've lost an entire frame. Will losing 1 frame of out of the potentially thousands really matter? Yes and no. Fact is most people will notice the sudden jump, or at least our minds do, but depending on what type of movie it is you may not. For example, eagle eye is quite possibly the most hyped up never-stop movie i've ever seen. One frame missing from that? hell, you couldn't even follow half the car chases, you're not going to see one frame missing from that.

So in that light, .01% loss? It's not even worth talking about. 1%? Okay, maybe we have a problem.

Sinned, on 18 February 2012 - 02:28 PM, said:

Online games:
And to get back to the games: Of course the risk is so tiny the loss almost wouldn't offset against the overall speed. But as in my example a client could miss the "specific gun", so one client could see an enemy running like wielding a gun, but he hasn't got one. And then he gets shot by a bullet from an unseen gun. (This is just a small example, but there could appear bigger glitches, like you are running like you're on some hills, but you see like you are in a battlefield. Just because you didn't receive the new map, and the server handles you for the new map.)

It follows the same kind of logic from before, but if you miss 1 packet of hundreds of thousands, you're fine. Most online games don't actually have lag or 'jump in' of objects because of packet loss either, since most packet loss can be fixed. Most online games have these problems because of 'jitter.' Which is an entirely different thing.

In other words, you're looking at a problem but talking about the wrong cause.