реализация ack по UDP?

Технически Resharper корректен в этом, "еще" является ненужным, я предпочитаю бывшую версию, хотя, поскольку намерение более очевидно.

Однако я пошел бы с:

return attr != null ? attr.Value : string.Empty;
8
задан 3 October 2009 в 20:59
поделиться

4 ответа

Взгляните на главы 8 и 20 книги Стивена Сетевое программирование UNIX, том 1 . Он охватывает несколько различных подходов. Раздел 20.5 «Повышение надежности UDP-приложения», вероятно, наиболее интересен для вас.

5
ответ дан 5 December 2019 в 09:26
поделиться

TCP объединяет 3 службы, которые могут иметь значение (хорошо, TCP делает гораздо больше, но я расскажу только о 3).

  1. Доставка по заказу
  2. Надежная доставка
  3. Управление потоком

Вы только что сказали, что вам не нужно управление потоком, поэтому я даже не буду касаться этого (как вы бы объявляли размер окна и т. Д., За исключением того, что вам, вероятно, понадобится окно Я доберусь до этого.)

Вы действительно сказали, что вам нужна надежная доставка. Это не так уж сложно - вы используете ACK, чтобы показать, что отправитель получил пакет. Базовая надежная доставка выглядит так:

  1. Отправитель отправляет пакет
  2. Получатель получает пакет, а затем отправляет подтверждение.
  3. Если отправитель не получает подтверждения (посредством таймера), он повторно отправляет пакет.

Эти три шага не решают следующие проблемы:

  1. Что делать, если ACK теряется?
  2. Что делать, если пакеты приходят не по порядку?

Итак, для вашего приложения вы сказали, что вам нужна только надежная доставка, но ничего не сказали о необходимости их порядка. Это повлияет на способ реализации вашего протокола.

(пример, где порядок не имеет значения: вы копируете записи сотрудников с одного компьютера на другой. Не имеет значения, получена ли запись Алисы раньше, чем запись Боба, если когда оба доберутся до места.)

Итак, исходя из предположения, что вам нужна только надежность (поскольку это то, что вы сказали в своем сообщении), вы можете добиться этого несколькими способами.

Ваш отправитель может отслеживать неподтвержденные пакеты. Таким образом, если он отправляет # 3, 4, 5 и 6 и не получает ACK для 3 и 4, то отправитель знает, что ему нужно повторно передать. (Хотя отправитель не Не знаю, были ли пакеты 3 и 4 партиями или их ACK были потеряны. В любом случае, мы должны передать повторно.)

Но тогда ваш отправитель мог бы делать кумулятивные ACK - поэтому в приведенном выше примере он подтвердил бы только # 6, если бы получил 3, 4 и 5. Это означает, что получатель будет отбросить пакет 6, если он не получил их ранее. Если ваша сеть очень надежна, тогда это может быть неплохим вариантом.

Однако у описанных выше протоколов есть окно, то есть сколько пакетов отправляет одновременно отправитель? Это означает, что вам действительно нужно какое-то оконное управление, но не для управления потоком. Как вы будете передавать размеры окон?

Вы могли бы сделать это без окна, установив постоянный размер окна или выполнив что-то вроде остановки и ожидания. Первое могло бы быть лучшим вариантом.

В любом случае, я не знаю ' t прямо ответил на ваш вопрос, но я надеюсь, что указал на некоторые вещи, которые стоит учесть при проектировании этого. Задача иметь "надежную передачу" без частей управления потоком (например, оконного управления) и без какого-либо отношения к порядку является сложной! (Дайте мне знать, если я должен рассказать о некоторых из этих вещей подробнее!)

Удачи!

9
ответ дан 5 December 2019 в 09:26
поделиться

У меня есть вопрос здесь , который собирает ответы на вопрос «Что использовать, когда вам нужен надежный UDP». Возможно, ответов гораздо больше, чем вы хотите или вам нужно, но вы можете взглянуть на некоторые протоколы, созданные на UDP, и получить только ту часть ACK, которая вам нужна.

Из моей работы с ENet протокол (надежный протокол UDP), я ожидаю, что вам понадобится порядковый номер в каждой дейтаграмме UDP, способ отправки ACK для датаграмм, которые вы получили, способ удержания датаграмм, которые вы отправили, пока вы не получите ACK для них, или время ожидания истекает, и способ синхронизации повторной отправки датаграмм, для которых вы еще не получили ACK ... Я бы также добавил общий тайм-аут, когда вы решите, что никогда не собираетесь доставлять конкретную датаграмму , а также,

4
ответ дан 5 December 2019 в 09:26
поделиться

Сложная проблема. Я бы сказал, что вы не сможете добиться надежности TCP. Однако я понимаю, что иногда вам нужен надежный UDP.

Форум Gamedev

RUDP (немного больше хардкор)

Старая тема о надежном UDP

0
ответ дан 5 December 2019 в 09:26
поделиться
Другие вопросы по тегам:

Похожие вопросы: