udp packet loss and recovery

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 th开发者_Go百科e other peer.

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

Any link and suggestion will be appreciated?

---

You need to cover for 4 main issues:

1. 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.
2. 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.
3. Replay - Sometimes, you may receive the same UDP datagram twice (for complex reasons). The target peer should detect this.
4. 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.

---

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

---

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.