потеря и восстановление пакетов udp

Question

Я работаю как с P2P на основе udp / tcp для файлов, так и с приложением потокового видео в реальном времени. Приложение будет разрабатываться как для Linux, так и для платформы Windows с использованием C ++.

Мы используем ICE (дырокол TCP / UDP) для реализации P2P. в то время как TCP гарантирует потерю пакетов, но для UDP мне нужен достойный подход, чтобы убедиться, что пакет должен быть доставлен другому узлу.

1. Я хотел знать алгоритм или технику, чтобы сделать это.
2. Есть ли какой-нибудь бесплатный инструмент / библиотеки для вечеринки?

Любая ссылка и предложение будет оценено?

Answer 1

Вам необходимо покрыть 4 основных вопроса:

1. Разделение данных - дейтаграммы UDP не могут содержать бесконечное количество информации. Поэтому вам (часто) нужно будет разделить вашу информацию на несколько дейтаграмм и повторно соединить кусочки головоломки на другом конце. Для данной «нарезки» вам нужен уникальный идентификатор и номер кусочка головоломки.
2. Никогда не достигнуто - дейтаграммы UDP иногда могут потеряться в сети. Если целевой узел не получает ожидаемую дейтаграмму, должен быть механизм, позволяющий ему запросить его снова. Другой способ - отправить подтверждение при получении.
3. Воспроизведение - Иногда вы можете получить одну и ту же дейтаграмму UDP дважды (по сложным причинам). Целевой узел должен обнаружить это.
4. Не в порядке - Порядок отправки не всегда является порядком получения. Целевой узел должен справиться с этой ситуацией.

Существует протокол, называемый Slicing Window , который вы можете реализовать. Я не думаю, что вы найдете стороннюю библиотеку для этого (хотя кто-то может доказать, что я здесь не прав), потому что все вышеперечисленное обычно реализуется самим TCP.

Answer 2

Вам могут пригодиться ответы на этот вопрос: Что вы используете, когда вам нужен надежный UDP?

Answer 3

Простой подход заключается в том, чтобы иметь поток мониторинга для каждого пакета -

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

Если важна производительность, для контроля очереди сообщений можно использовать один поток.