3

How is it possible to guarantee delivery of messages using UDP on Node.js? For example, I could just resend the packet if it failed - but is there a way to identify when it failed? Also, how common is the loss of a packet?

MaiaVictor
  • 51,090
  • 44
  • 144
  • 286
  • @downvoter care to explain? – MaiaVictor Mar 26 '13 at 04:26
  • 1
    i see no reason to downvote..... but know that UDP has no gaurentee of delivery its part of the protocol a google search would have revealed this. I'd guess the downvote was a result of "What did you try." – j_mcnally Mar 26 '13 at 04:29
  • 1
    TCP is the way to go for error handling. – j_mcnally Mar 26 '13 at 04:30
  • 1
    @j_mcnally I know that UDP has no guarantee of delivery, what I was asking was how to guarantee the message delivery. I've edited to make it more clear. – MaiaVictor Mar 26 '13 at 04:39
  • No you don't know if it went or didn't thats the point. – j_mcnally Mar 26 '13 at 04:43
  • 1
    If it matters use TCP, thats what it is there for, this is like asking is there a way to know if people can travel through black holes. – j_mcnally Mar 26 '13 at 04:43
  • @j_mcnally lol, what? – MaiaVictor Mar 26 '13 at 04:51
  • we don't know if people can go through backholes because they distort space time at the event horizon. So to an observer an object appears to freeze at the event horizon and there is no way to tell if they made it or were torn apart, the same can be said of UDP packets. – j_mcnally Mar 26 '13 at 05:09

4 Answers4

12

If what you're really wondering is "how do I detect lost packets"? Then the general technique is to have the receiver send an acknowledgement for each packet sent. If the transmitter does not receive an acknowledgement then it must resend the packet. If the receiver gets duplicate packets then it should discard the duplicate.

The basic scheme is this:

TX                               RX
 ╷           data
 ╰──────────────────────────────▶

              ack               ╷
 ◄──────────────────────────────╯

 ╷           data
 ╰────────────────────── - - -         loss of data packet
               .
               .
               . timeout
               .
 ╷       data retransmit
 ╰──────────────────────────────▶

              ack               ╷
 ◄──────────────────────────────╯

 ╷           data
 ╰──────────────────────────────▶

              ack               ╷
      - - - ────────────────────╯      loss of ack packet
               .
               . timeout
               .

 ╷       data retransmit
 ╰──────────────────────────────▶

              ack               ╷
 ◄──────────────────────────────╯

This is essentially the basis of all forms of packet loss detection. There are several refinements that can be implemented to improve the technique but the basics is generally the same: if the receiver does not tell you that the packet has arrived then the packet is lost.

One of the first improvement generally done to the algorithm is to check that the ack is really the appropriate ack and not just some echo sent by the router or by signal cross inteference or by a software bug. The solution is to implement a toggle bit. The data packet is transmitted with the toggle bit set to a value and the ack packet needs to reply with the appropriate value (usually the same value). If the toggle bit is wrong then it means that the ack packet doesn't match the last data packet which implies that it matches the previous data packet. This implies that the last data packet hasn't been acknowledged which means that something has seriously gone wrong and the packet should be retransmitted until the correct ack is received.

TX                               RX
 ╷           data[0]
 ╰──────────────────────────────▶

              ack[0]            ╷
 ◄──────────────────────────────╯

 ╷           data[1]
 ╰──────────────────────────────▶

              ack[0]            ╷
 ◄──────────────────────────────╯     ack mismatch!

 ╷       data[1] retransmit
 ╰──────────────────────────────▶

Several real world protocols use this technique including most protocols used to control industrial equipment and robots.

The next step is actually an expansion of the above idea. Instead of sending just a bit why not send a number. That way you can more definitely match the ack to the data packet and so more accurately detect which packet was lost and needs retransmission. This technique is often referred to as the sliding window technique because at some point the number rolls over and slides back to zero. And so the maximum number of packets you can transmit before you're unable to detect packet loss is the sliding window size.

The big advantage of the sliding window technique is that you can send lots of data packets without waiting for the ack. This significantly improves throughput:

TX                             RX
 ╷           data[1]
 ╰──────────────────────────────▶
 ╷           data[2]
 ╰──────────────────────────────▶
 ╷           data[3]
 ╰──────────────────────────────▶


              ack[1]            ╷
 ◄──────────────────────────────╯
              ack[2]            ╷
 ◄──────────────────────────────╯

 ╷           data[4]
 ╰──────────────────────────────▶
 ╷           data[5]
 ╰──────────────────────────────▶

              ack[3]            ╷
 ◄──────────────────────────────╯
              ack[5]            ╷
 ◄──────────────────────────────╯     ack[4] missing!
               .
               . timeout
               .

 ╷       data[4] retransmit
 ╰──────────────────────────────▶

So the above is a short summary of the basic technique for detecting packet loss. That's what you need to implement if you want all your UDP packets to arrive at their destination.

You should know though that TCP already implements this so you should really use TCP if you don't want to reinvent the wheel. UDP was created because in some cases packet loss is OK (think audio/video streaming).

slebetman
  • 109,858
  • 19
  • 140
  • 171
2

From Wikipedia

UDP is suitable for purposes where error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level. Time-sensitive applications often use UDP because dropping packets is preferable to waiting for delayed packets, which may not be an option in a real-time system.[2] If error correction facilities are needed at the network interface level, an application may use the Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) which are designed for this purpose.

Basically use TCP if you care, if the packets/message gets there. Otherwise re-invent TCP using UDP at the application level.

3ventic
  • 1,023
  • 1
  • 20
  • 32
j_mcnally
  • 6,928
  • 2
  • 31
  • 46
0

It isn't possible to guarantee delivery of a specific UDP packet on ANY platform, not just node.js. If what you're looking for is a UDP-based reliable delivery mechanism, look for something like e-net or search for reliable UDP.

EDIT: or use TCP.

Femi
  • 64,273
  • 8
  • 118
  • 148
  • Not a specific UDP packet, but the message itself. I'm asking if it is possible to resend a lost packet until it arrives successfully? (EDIT: oh and I'll read about enet, thanks!) – MaiaVictor Mar 26 '13 at 04:23
0

UDP is a protocol with no guaranteed delivery. If you want to guarantee, you should implement some protocol on top of UDP.

Andrey Regentov
  • 3,687
  • 4
  • 34
  • 40