CODEWITHSUNDEEP
network-programmingudpp2phole-punching
Vikram Ranabhatt
Vikram Ranabhatt

Reputation: 7620

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 the 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?

Upvotes: 1

Views: 6576

Answers (3)

Daniel Lubarov
Daniel Lubarov

Reputation: 7924

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.

Upvotes: -1

Len Holgate
Len Holgate

Reputation: 21616

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

Upvotes: 0

J&#233;r&#244;me Verstrynge
J&#233;r&#244;me Verstrynge

Reputation: 59586

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.

Upvotes: 5

Related Questions