Написание надежной, полностью упорядоченной системы многоадресной рассылки на Python
Мне нужно с нуля написать надежную, полностью упорядоченную систему многоадресной рассылки на Python. Я не могу использовать внешние библиотеки. Мне разрешено использовать центральный секвенсор.
Кажется, есть два непосредственных подхода:
- написать эффективную систему, прикрепив уникальный идентификатор к каждому многоадресному сообщению, имея порядковые номера многоадресной рассылки секвенсора для идентификатора сообщения, которое он получает, и отправка туда и обратно ACK и NACK.
- написать неэффективную систему лавинной рассылки, где каждый мультикастер просто повторно отправляет каждый сообщение, которое он получает один раз (если оно не было отправлено этим конкретным мультикастером).
Мне разрешено использовать второй вариант, и я склонен это делать.
В настоящее время я передаю многоадресные сообщения UDP (что, кажется, единственный вариант), но это означает, что некоторые сообщения могут быть потеряны. Это означает, что я должен иметь возможность однозначно идентифицировать каждое отправленное сообщение UDP, чтобы его можно было повторно отправить согласно пункту 2. Должен ли я действительно генерировать уникальные числа (например, используя адрес отправителя и счетчик) и упаковывать их в каждое отправленное сообщение UDP? Как бы я это сделал? И как мне получить одно сообщение UDP в Python, а не поток данных (например, socket.recv)?
Ответы 2
Подход с наводнением может ухудшить плохую ситуацию. Если сообщения отбрасываются из-за высокой нагрузки на сеть, повторная отправка каждого сообщения каждым узлом только ухудшит ситуацию.
Наилучший подход зависит от характера отправляемых вами данных. Например:
- Мультимедийные данные: повторных попыток нет, отброшенный пакет - это отброшенный кадр, что в любом случае не имеет значения, когда следующий кадр попадет туда.
- Данные с фиксированным периодом: узел-получатель хранит таймер, который сбрасывается каждый раз при получении обновления. Если время истекает, он запрашивает недостающее обновление у главного узла. Повторные попытки могут быть одноадресными для запрашивающего узла.
Если ни одна из этих ситуаций не применима (каждый пакет должен быть получен каждым узлом, а время пакета непредсказуемо, поэтому получатели не могут самостоятельно обнаружить пропущенные пакеты), тогда ваши варианты включают:
- Явный ACK от каждого узла для каждого пакета. Отправитель повторяет (одноадресно) любой пакет, который не был подтвержден.
- Сеточный подход на основе TCP, при котором каждый узел вручную повторяет полученные пакеты соседним узлам, полагаясь на механизмы TCP для обеспечения доставки.
Вы можете рассчитывать на то, что получатели заметят пропущенный пакет при получении пакета с более поздним порядковым номером, но для этого отправитель должен хранить пакет до тех пор, пока не будет отправлен хотя бы один дополнительный пакет. Требование положительных ACK более надежно (и доказуемо).
Выбранный вами подход будет во многом зависеть от характера данных, которые вы отправляете, масштаба вашей сети и количества данных, которые вы отправляете. В частности, это будет зависеть от количества целей, к которым подключен каждый из ваших узлов.
Если вы ожидаете, что это будет масштабироваться до большого количества целей для каждого узла и большого количества данных, то вы вполне можете обнаружить, что накладных расходов на добавление ACK / NAK к каждому пакету достаточно, чтобы отрицательно ограничить вашу пропускную способность, особенно когда вы добавляете в микс ретрансляции.
Как сказал Фрэнк Щерба, мультимедийные данные имеют то преимущество, что они могут восстанавливаться после утерянных пакетов. Если у вас есть какой-либо контроль над данными, которые вы отправляете, вы должны попытаться спроектировать полезные нагрузки так, чтобы минимизировать восприимчивость к отброшенным пакетам.
Если данные, которые вы отправляете, не могут переносить отброшенные пакеты и, которые вы пытаетесь масштабировать для высокого использования вашей сети, возможно, udp - не лучший протокол для использования. Реализация серии tcp-прокси (где каждый узел ретранслирует, одноадресно, на все другие подключенные узлы - аналогично вашей идее лавинной рассылки) будет более надежным механизмом.
С учетом всего вышесказанного, рассматривали ли вы возможность использования настоящей многоадресной рассылки для этого приложения?
Только что увидел тег "домашнее задание" ... эти предложения могут не подходить для домашнего задания.