UDP is about as reliable as the underlying internet protocol. UDP doesn't really introduce any additional unreliability, ignoring factors such as the additional UDP header length causing trouble and a network route configured to punish UDP traffic.

The connection is the connection, that is fact. The point is how the protocol reacts to the connection reliability. TCP uses a suite of algorithms designed to take pressure off the network, while re-sending to ensure the data eventually gets through. UDP does not, it will happily shove packets onto the network at the rate you're sending, and doesn't do anything should those packets get lost, duplicated or re-ordered.

Packet loss is very relevant. As mentioned, you have no control over what circumstances can cause packet loss. You cannot ignore it as a factor. Sure, you could build a probability table of certain types of network behaviour, which might help you pick good defaults.

What is your *real* question? Presumably, if given the kind of figures you are looking for, you will use that to make some kind of decision. What kinds of decisions are you thinking about? TCP vs UDP? Reasonable packet sizes? Reasonable sending rates? Whether to bother implementing an adaptive mechanism that tries to react to packet loss? Something else?

I am not looking for any *real* answer, I was just curious after reading the article I posted. Additionally, it is good to know under how "bad" connection I should test multiplayer games.

I am very satisfied with answers by the way, thanks :)

Its really trivial to get an acceptable level of reliability by making your own "baby" protocol on top of UDP.

Lets just ignore fragmentation and assume everything you send is under the old 512 byte (or 3kb according to who you ask or where) limitation of IP/UDP.

Basically all you need to do is have a "packet id" at the front of every packet you send.

The receiver sends back an empty packet with this id to acknowledge.

Sender holds a list of packets waiting for ack, removes packet when receives ack...or

sender resends the packet after a waiting period.

Have packets that don't need reliability? Have a packet id of zero mean don't send ack and don't resend.

If your packet id's are sequential integers, you can even queue up packets until you have them all arrived and then pass them to your code in order.

Now you have reliability and in-order receipt taken care of with very little work.

Have you reinvented TCP? Not hardly. TCP does way more (like flow control, fragmentation, sessions, etc).

If your code only uses small packets then this will probably work. It is an extremely oversimplified version of what most UDP libraries do anyways.

Lets just ignore fragmentation and assume everything you send is under the old 512 byte (or 3kb according to who you ask or where) limitation of IP/UDP.

This depends on the protocol version, not so much whom you ask

IPv4 devices must be able to handle 576 byte datagrams whereas IPv6 devices must be able to handle a minimum of 1280 bytes.

Though even if you use IPv4, your devices and all intermediate routers are almost certainly IPv6-capable devices anyway (unless you're in a third or fourth world country and using a 15 year old router). Virtually the entire internet backbone has been IPv6 for years, so 1280 byte datagrams are a pretty safe bet.

Have you reinvented TCP? Not hardly. TCP does way more (like flow control, fragmentation, sessions, etc).

Flow control is something that you most likely have to implement as well, since flow control is the one thing that prevents packet loss.

This experiment shows the very problem:

When sending small packets with at least one ms sleep in between, 100% of all packets were received and in order. As soon as I dropped that sleep, however, I saw something like 15-20% packet losses

Here, the sleep was a very basic "congestion control". You can in theory push 8Gbit/s to your network card over PCIe, but the cable will only take 1Gbit. What is the network card supposed to do? It can buffer a few datagrams, and then it will have to drop the rest until the buffered ones are sent. This is why congestion control is needed.

It is very similar when there are half a dozen routers in between, only then you're not the only one sending datagrams.

Quote
Have you reinvented TCP? Not hardly. TCP does way more (like flow control, fragmentation, sessions, etc).
Flow control is something that you most likely have to implement as well, since flow control is the one thing that prevents packet loss.

Packet loss is for any reason is taken care of by retransmission.

The receiver sends back an empty packet with this id to acknowledge.
Sender holds a list of packets waiting for ack, removes packet when receives ack...or
sender resends the packet after a waiting period.

If you want flow control, retransmission, and in order receipt use TCP instead of UDP.

Although, for a game its unlikely you will need flow control since your game world updates should be very small in throughput.

Though even if you use IPv4, your devices and all intermediate routers are almost certainly IPv6-capable devices anyway (unless you're in a third or fourth world country and using a 15 year old router). Virtually the entire internet backbone has been IPv6 for years, so 1280 byte datagrams are a pretty safe bet.

Most residential ISP's here in america are still IPv4 only. My mobile connection has IPv6, but my cable ISP and competing DSL ISP do not have IPv6 working on residential connections.

Flow control is something that you most likely have to implement as well, since flow control is the one thing that prevents packet loss.

Packet loss is for any reason is taken care of by retransmission.

That is true, but it has nothing to do with flow control (or congestion control). Indeed, retransmission without congestion control may quite possibly further increase packet loss.

If you want flow control, retransmission, and in order receipt use TCP instead of UDP. Although, for a game its unlikely you will need flow control since your game world updates should be very small in throughput.

You use TCP if you want guaranteed in-order delivery and cannot afford to discard and move on quickly. Or, if you want your networking simple and reliable and don't care about a possible delay now and then. You will however in most cases still need flow control if you use UDP.

In addition to bandwidth not being infinite (not only at the client's end, but also on your end.. consider having to send out updates to a hundred clients, and receiving input from these as well), TCP will induce packet loss on UDP, which is a normal thing to happen. You will usually have TCP connections in addition to your UDP traffics, either because you use TCP to download assets, or because you need a TCP connection to another service (say, database server), or because the user makes TCP connections completely unrelated to your game (say, a webbrowser). That means that the available bandwidth at either end can, and will, change dynamically. You must detect this and react appropriately, or you will lose packets in large numbers (especially if you retransmit).

Most residential ISP's here in america are still IPv4 only. My mobile connection has IPv6, but my cable ISP and competing DSL ISP do not have IPv6 working on residential connections.

Neither do they in my place, but that is irrelevant since they use ATM everywhere from my modem throughout the DSLAM and BRAS and up to the internet router anyway. The Internet router on the other hand certainly supports IPv6 as they'd have trouble meeting the IX's requirements otherwise (plus, it demonstrably supports IPv6 as it's made available to clients who pay for it since late 2011).

They just don't give me (and thousands of others) who doesn't want to pay extra an IPv6 address, that's all. Don't ask me why, it would certainly be much easier to just hand everybody an IPv6 address anyway (plus, IPv6 means more traffic, so more €€€), but they just don't do it unless you pay extra.

Maybe the reason is that without the restricted address space of IPv4, there is no credible excuse for handing out dynamic addresses which change every few days (which is of course done on purpose so it's much harder for you to run a public server "for free" from home).

Maybe the reason is that without the restricted address space of IPv4, there is no credible excuse for handing out dynamic addresses which change every few days (which is of course done on purpose so it's much harder for you to run a public server "for free" from home).

Over here almost all consumers have dynamic IPv4 addresses, but they almost never change, at least not as long as you keep renewing it and/or use your connection. I think it's partially for tracking reasons. Then again, our ISPs openly allow private servers and some of them even give out free dynamically updated domain names to their customers..

Maybe the reason is that without the restricted address space of IPv4, there is no credible excuse for handing out dynamic addresses which change every few days (which is of course done on purpose so it's much harder for you to run a public server "for free" from home).

Over here almost all consumers have dynamic IPv4 addresses, but they almost never change, at least not as long as you keep renewing it and/or use your connection. I think it's partially for tracking reasons. Then again, our ISPs openly allow private servers and some of them even give out free dynamically updated domain names to their customers..

I only get a new IPv4 address in the event that i reboot my router and leave it off for more than a few hours, or if the cable company decide to force me to have a new IP (which happens maybe once a year?). I very rarely do this. This means that generally i just have a bunch of A records pointed at my home server and don't even bother with dynamic DNS.

I also have a free IPv6 tunnel with a few billion static addresses which is always up and running, gotta love IPv6...