Написание надежной, полностью упорядоченной многоадресной системы на Python

Question

Мне нужно написать надежную, полностью упорядоченную многоадресную систему с нуля на Python. Я не могу использовать какие-либо внешние библиотеки. Мне разрешено использовать центральный секвенсор.

Кажется, есть два непосредственных подхода:

1. написать эффективную систему, прикрепив уникальный идентификатор к каждому многоадресному сообщению, наличие порядковых номеров многоадресной рассылки для идентификаторов сообщений, которые оно получает, и отправлять туда и обратно ACK и NACK.
2. написать неэффективную систему затопления, где каждый мультикастер просто пересылает каждый сообщение, которое он получает один раз (если оно не было отправлено этим конкретным мультикастером).

Мне разрешено использовать второй вариант, и я склонен сделать это.

В настоящее время я отправляю многоадресные UDP-сообщения (что кажется единственным вариантом), но это означает, что некоторые сообщения могут быть потеряны. Это означает, что я должен иметь возможность однозначно идентифицировать каждое отправленное UDP-сообщение, чтобы его можно было повторно отправить согласно # 2. Должен ли я действительно генерировать уникальные номера (например, используя адрес отправителя и счетчик) и упаковывать их в каждое отправленное UDP-сообщение? Как бы я поступил так? И как мне получить одно сообщение UDP в Python, а не поток данных (т.е. socket.recv)?

Answer 1

Подход наводнения может привести к ухудшению плохой ситуации. Если сообщения отбрасываются из-за высокой загрузки сети, повторная отправка каждого сообщения каждым узлом только ухудшит ситуацию.

Лучший подход зависит от характера данных, которые вы отправляете. Например:

1. Мультимедийные данные: без повторных попыток, отброшенный пакет - это пропущенный кадр, который в любом случае не будет иметь значения, когда следующий кадр попадет туда.
2. Данные с фиксированным периодом: узел получателя сохраняет таймер, который сбрасывается при каждом получении обновления. Если время истекает, он запрашивает отсутствующее обновление от главного узла. Повторные попытки могут быть одноадресными для запрашивающего узла.

Если ни одна из этих ситуаций не применима (каждый пакет должен быть получен каждым узлом, и время пакета непредсказуемо, поэтому получатели не могут самостоятельно обнаружить пропущенные пакеты), тогда ваши параметры включают:

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

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

Answer 2

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

Если вы ожидаете, что это масштабируется до большого количества целей для каждого узла и большого количества данных, то вы вполне можете обнаружить, что накладные расходы на добавление ACK / NAK к каждому пакету достаточны для неблагоприятного ограничения вашей пропускной способности. особенно когда вы добавляете ретрансляции в микс.

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

Если данные, которые вы отправляете, не могут переносить отброшенные пакеты и , которые вы пытаетесь масштабировать до высокого уровня загрузки вашей сети, тогда, возможно, протокол udp не лучший протокол для использования. Реализация серии прокси tcp (где каждый узел ретранслирует одноадресную передачу всем остальным подключенным узлам - аналогично вашей идее затопления) будет более надежным механизмом.

Учитывая все вышесказанное, рассматривали ли вы возможность использования настоящей многоадресной рассылки для этого приложения?

---

Только что увидел тег "домашнее задание" ... эти предложения могут не подходить для решения домашнего задания.