Допустим, у меня есть 2 машины в одном центре обработки данных, но не обязательно в одной стойке.
Насколько часто будут отброшены пакеты при отправке с использованием UDP между этими двумя машинами?
Я спрашиваю, исходя из предположения, что, поскольку между машинами всего несколько коммутаторов, пакеты не будут отброшены вообще.
Насколько распространено прибытие неупорядоченных пакетов в одном центре обработки данных? Я предполагаю, что в 99,9% случаев существует только один маршрут, поэтому этого не может произойти.
Тем не менее, каждый раз, когда я ловлю себя на мысли об абсолютных терминах, я знаю, что, должно быть, что-то упускаю!
Какая справочная информация мне нужна, чтобы лучше понять, когда ожидать отброшенных пакетов и как часто они могут сбрасываться и приходить из строя для машин в одном центре обработки данных?
В конечном итоге я пытаюсь решить, использовать ли многоадресную рассылку UDP или PGM при взаимодействии между разными экземплярами Linode VPS, расположенными в одном центре обработки данных. Информация должна поступать и в порядке. Конечно, тогда UDP звучит не так хорошо!
Но если можно ожидать почти идеальной или идеальной доставки в одном и том же центре обработки данных, то это нормально. Но я проверяю это предположение.
Спасибо.
Вы не можете полагаться на UDP для доставки пакетов по порядку, потому что спецификация не предоставляет таких гарантий. Даже в самой идеальной ситуации, когда между двумя хостами используется один кусок Ethernet-кабеля, все равно остается вопрос об ОС, сетевом стеке, драйвере сетевой карты и реализации libc, против которых вы пишете.
На каждом этапе этой цепочки авторы этого кода будут выбирать НЕ отдавать приоритет упорядочиванию пакетов UDP, даже если они поступают, по той простой причине, что они не должны этого делать.
Одним из надуманных примеров может быть структура данных, в которую считываются входящие пакеты, которая может быть кольцевым буфером. Пакеты, поступающие по порядку, будут помещены в кольцевой буфер по порядку, но для разработчика драйвера может быть проще выгружать их на верхние уровни сетевого кода. в порядке памяти, следовательно, их порядок рандомизируется.
Если взять вашу ситуацию, виртуальная машина работает в общей инфраструктуре, которая будет работать для объема, а не для производительности, тогда вероятность прогнозирования порядка получения пакетов UDP будет низкой.
Короче говоря, если в спецификации сказано, что вы не можете полагаться на упорядочение пакетов UDP. Вы не можете полагаться на это, и вы не можете пытаться настроить среду, чтобы дать более надежную гарантию, чем когда-либо обещала спецификация.
Практически любой переключатель вызовет переупорядочение двух пакетов в любое время и учитывается многими сетевыми протоколами, такими как PGM.
Следует учитывать, что большинство центров обработки данных блокируют дейтаграммы и блокируют многоадресную рассылку, чтобы упростить и сократить накладные расходы на свою сетевую инфраструктуру.
Сам протокол IP / PGM необходимо использовать только в том случае, если у вас включен PGM Router Assist и осведомлены о сетевых элементах между сервером и клиентами, в противном случае придерживайтесь PGM, инкапсулированного в UDP, и избавьтесь от бремени управления разрешениями приложений.
Если вы используете уровень обмена сообщениями, такой как ØMQ, вы можете отложить выбор сети IP / PGM, UDP / PGM или TCP до развертывания и интеграции.
Если кому интересно экспериментировать, просто используйте Wireshark. Если кто-то действительно задумывается о медленном подключении или сброшенных пакетах, мы просто зеркалируем порт на коммутаторе, подключаем ноутбук с помощью Wireshark и проверяем.
Я написал простое приложение для многоадресной рассылки .net, которое может измерять количество отброшенных пакетов при заданном давлении.
Вы можете скачать это здесь: SimpleMulticastAnalyzer.
Наслаждаться.