udp packet loss and recovery

Question

I am working on both udp/tcp based P2P for file and real time video streaming application.the application will be developed for both Linux and windows platform using c++.

We are using ICE(TCP/UDP hole punching) to implement the P2P. while TCP ensure the packet loss but for UDP I need a decent approach to make sure packet must be delivered to the other peer.

I wanted to know the algorithm or technique to do this.
Is there any free thord party tool/libraries to do.

Any link and suggestion will be appreciated?

score 5 · Answer 1 · answered Apr 19 '11 at 11:03

You need to cover for 4 main issues:

Data slicing - UDP datagrams cannot contain an infinite amount of information. Therefore, you will (often) need to slice your information into multiple datagrams and reconnect the puzzle pieces at the other end. For a given 'slicing', you need unique identifier and puzzle piece number.
Never Reached - UDP datagrams can sometime get lost on the net. If a target peer does not receive an expected datagram, there should be a mechanism letting him request it again. Another method is to send a confirmation upon reception.
Replay - Sometimes, you may receive the same UDP datagram twice (for complex reasons). The target peer should detect this.
Out-of-order - The order of sending is not always the order of receiving. A target peer needs to handle this situation.

There is a protocol called slicing window which you could implement. I don't think you'll find a 3rd party library for this (though someone may prove me wrong here), because all the above is typically implemented by TCP itself.

score 0 · Accepted Answer · edited May 23 '17 at 12:18

0

You might find the answers to this question helpful: What do you use when you need reliable UDP?

edited May 23 '17 at 12:18

Community

1
1

answered Apr 19 '11 at 12:27

Len Holgate

21,282
4
45
92

Daniel Lubarov · Answer 3 · 2017-05-31T16:49:44.920

-1

A simple approach would be to have a monitoring thread for each packet --

public void run() {
    int transmissions = 0;
    do {
        sendPacket();
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {}
    } while (!acknowledged() && ++transmissions < MAX_TRANSMISSIONS);
}

If performance is important, a single thread could be used to monitor a queue of messages.

edited May 31 '17 at 16:49

answered Apr 19 '11 at 08:50

Daniel Lubarov

7,796
1
37
56

This just seems a VERY unlikely method of ensuring UDP data delivery, that's all... – Len Holgate Apr 19 '11 at 15:24
Why do you say it's unlikely? – Daniel Lubarov Apr 19 '11 at 21:24
This trivial solution wastes threads. One thread doing this is still waste. A reactive system would be better. For instance, if the receiver detects packet loss, it can request that the lost packet be resent. In which case, the send would receive said request, notice its a retransmit request for a specific packet, and queue it up to be resent over UDP. No threads would be just looping waiting for something to happen. – czifro May 30 '17 at 23:46
@czifro requesting retransmits can sometimes be better, but it depends on the packet loss rate and the message frequency (which affects how soon the receiver can detect a lost packet). Having the sender timeout and retransmit is more efficient in general, hence TCP's design. – Daniel Lubarov May 31 '17 at 17:02
@DanielLubarov , if you look at fasp, rbudp, and QUIC protocols, they perform very similar steps to what I have outlined and a extremely reliable and very fast (they greatly out perform TCP). Dedicating a thread per packet as described in your solution is a huge waste of resources. In worst case scenario where no packets are making it, the sender would be bogged down by hundreds of threads looping until `transmissions < MAX_TRANSMISSIONS == false`. – czifro Jun 03 '17 at 21:25
@czifro the OP wanted reliable UDP just for hole punching, so the thread overhead would probably be trivial. But as I said, if the packet rate is substantial then you can have a single thread monitor a packet queue. None of the protocols you mention eliminate the need for a packet queue (or send buffer, in TCP terminology) or a thread to monitor it. RBUDP batches acks which is good for transmitting large static files, but doesn't help with hole punching. – Daniel Lubarov Jun 04 '17 at 21:04

udp packet loss and recovery

3 Answers3

Linked