4
\$\begingroup\$

I am currently implementing a real-time network protocol for a multiplayer game using UDP. I am not having any technical difficulties, but as I always have to care about late UDP packets I am wondering just how late they can arrive.

I have researched the topic and have not found any mention of it, so I assume there is no technical limitation, but I wonder if common network/internet architecture (or hardware) gives an effective limitation of how late a UDP packet can be delivered.

\$\endgroup\$
5
  • \$\begingroup\$ Since UDP is an unreliable protocol, this would be up to service that is sending out the packets. The effective limitation would likely depend on the system using your protocol. \$\endgroup\$
    – Evan
    Commented Jun 12, 2014 at 19:53
  • \$\begingroup\$ No, there is no technical limit. In fact, there is no requirement that UDP datagrams be delivered in finite time at all. In other words, it is perfectly acceptable never to deliver a UDP datagram. Dealing with packet loss (datagrams delivered at infinity) is up to you ;) \$\endgroup\$
    – Andon M. Coleman
    Commented Jun 13, 2014 at 7:05
  • \$\begingroup\$ @AndonM.Coleman I am already handling dropped and late packets. This question evolved out of curiosity about realistic delays in the internet. I should have stated that better. \$\endgroup\$
    – Jens Nolte
    Commented Jun 13, 2014 at 10:54
  • \$\begingroup\$ Oh, you want some sort of threshold as to when you can simply ignore a datagram that arrives ridiculously late? You could get all fancy and make it a multiple of the round-trip latency, but realistically since no attempt is ever made to re-transmit a datagram I think rather than considering some fundamental rule for delivery time, simply consider when the datagram stops being useful anymore at the application level (e.g. you probably cannot do much useful with a position update that arrives 5 seconds late). That number would be a heck of a lot easier to come up with. \$\endgroup\$
    – Andon M. Coleman
    Commented Jun 13, 2014 at 11:17
  • \$\begingroup\$ @AndonM.Coleman Yes, I have a lot of state which is still useful when it arrives late, but on the other hand the later a delayed packet can be handled the longer I have to cache some information (e.g., sequence channels for deleted items so they don't get recreated). If 95% of the packets arrive in 'ping + x' seconds anyway I would happily discard all packets arriving after 'ping + x' seconds. I don't have the opportunity to profile this on a lot of connections, so I wonder is there is some experience/research out there? \$\endgroup\$
    – Jens Nolte
    Commented Jun 13, 2014 at 17:32

2 Answers 2

Reset to default
4
\$\begingroup\$

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, but will vary according to a lot of factors outside of your control.

If you need 99.999% assurance, then increase x accordingly; if you only need 90% assurance, decrease it.

From a implementation perspective, if packets arrive after a certain elapsed time, they're probably worthless anyhow, so they can be discarded.

\$\endgroup\$
4
  • \$\begingroup\$ Do you have any experience on the actual value of "x"? As I said, this is pure curiosity, I already handle dropped packets and discard packets if they are over 60s late :) \$\endgroup\$
    – Jens Nolte
    Commented Jun 12, 2014 at 20:37
  • \$\begingroup\$ Not really, but it would also depend on the context. In a real-time environment (e.g., an FPS game), even getting a packet notifying you that someone pulled the trigger 5 seconds ago is worse than useless. \$\endgroup\$
    – Mike Harris
    Commented Jun 13, 2014 at 16:19
  • \$\begingroup\$ The last sentence pretty much sums it up. Discarding any packets arriving after a deadline means you no longer have to worry about late deliveries because you are turning them into lost packets, which you have to deal with anyway. \$\endgroup\$
    – kasperd
    Commented Apr 18, 2016 at 16:09
  • 2
    \$\begingroup\$ Obviously code has to deal with the possibility of a packet that never arrives, but an equally important question would be "If a packet arrives at time t, what can the recipient assume about when it was sent?" Can the recipient safely assume it wasn't sent more than five years ago? Five hours? Five minutes? The worst-case delay will affect the required length for things like sequence numbers. \$\endgroup\$
    – supercat
    Commented Apr 18, 2016 at 19:09
0
\$\begingroup\$

The default Time To Live for UDP packets sent over TCP/IP networks is 128 seconds (on Windows). One can reasonably assume that a router/network adapter will no longer forward the UDP packet after this. Of course this is a default value and can differ on different software/devices. I believe the maximum possible value for TTL is 255 seconds. Note that TTL is not an UDP feature but a feature of the protocol above it. So if you're using something else than TCP/IP (which I think is unlikely in your case) you'll have to find another source.

Source: http://www.binbert.com/blog/2009/12/default-time-to-live-ttl-values/

\$\endgroup\$
5
  • 2
    \$\begingroup\$ So I should have included my research about TTL into the question ^^ "In theory, under IPv4, time to live is measured in seconds, although every host that passes the datagram must reduce the TTL by at least one unit. In practice, the TTL field is reduced by one on every hop. To reflect this practice, the field is renamed hop limit in IPv6." \$\endgroup\$
    – Jens Nolte
    Commented Jun 12, 2014 at 20:12
  • \$\begingroup\$ I did not know that it was more of a hop limit. In that case it becomes less useful. :) \$\endgroup\$
    – Roy T.
    Commented Jun 12, 2014 at 21:40
  • \$\begingroup\$ To expand on what @JensNolte said, I think it is worth pointing out that very few devices would actually decrease the TTL by more than one even if they took multiple seconds to forward the packet. So in case of extreme bufferbloat, it is possible for a packet to be delivered more than 255 seconds later than it was send. This is true of both IPv4 and IPv6. \$\endgroup\$
    – kasperd
    Commented Apr 18, 2016 at 13:29
  • \$\begingroup\$ Note that TCP has nothing to do with this. You should say IP only. The IP protocol is where you have that "TTL" (hop) limit. \$\endgroup\$
    – Alexis Wilke
    Commented May 14, 2018 at 10:59
  • \$\begingroup\$ @AlexisWilke You're right. But I think the last sentences in this answer address this :). \$\endgroup\$
    – Roy T.
    Commented May 31, 2018 at 13:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .