Основная концепция заключается в отправке данных нескольким заинтересованным сторонам. Текущий метод используется для того, чтобы издатель отправлял данные промежуточной части программного обеспечения по TCP, которая затем разглашает их всем заинтересованным слушателям по TCP.
Я изучаю возможность перехода на многоадресную рассылку, чтобы исключить эту среднюю часть программного обеспечения.
Использование многоадресного метода распределения данных должно устранить 4 задержки сериализации в сети с 1 Гбит / с и одно время обработки коммутатора, а также все накладные расходы с этим средним компонентом распространения программного обеспечения. Таким образом, экономия времени составляет 10-60 микросекунд в зависимости от размера пакета, даже не считая среднего программного обеспечения.
В моих тестах отправитель сначала отправляет данные через многоадресную рассылку, а затем отправляет их по TCP в программное обеспечение для распространения.
Слушатель будет прослушивать как многоадресную рассылку, так и TCP, и заметит разницу во времени прибытия пакета.
Проблема - TCP-трафик приходит быстрее, чем многоадресный трафик! Это регистрируется моей программой прослушивания и подтверждается захватом проволочной акулы на прослушивающей машине.
Есть ли у вас какие-либо мысли о том, как ОС, сетевой адаптер или коммутатор могут это делать, и возможных настройках для проверки?
[править]
Только что произвел синхронизированный захват пакетов на отправляющей / прослушивающей машине, обнаружил экземпляр, в котором слушатель увидел, что TCP входил до MCAST, но при отправке захвата трафик TCP вышел через 15 микросекунд после
[/ править]