Синхронизация сообщений по сети - PullRequest
0 голосов
/ 18 января 2011

Использование широковещательной передачи и UDP с ack (мы должны использовать его, потому что он поддерживает существующую систему).

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

Как мы можем уменьшить опасность (я думаю, что решить невозможно) A повторно отправить B msg, прежде чем подтверждение B достигнет A, так что A может зарегистрировать сообщение как неудачное(после повторной отправки дважды), тогда B's Ack достигает A?

Ответы [ 2 ]

0 голосов
/ 15 февраля 2011

Приложение B должно быть записано таким образом, чтобы поток с высоким приоритетом, предпочтительно в реальном времени, планировал, ожидание пакетов от приложения A . Когда B получает пакет, скопируйте полезную нагрузку в кольцевой буфер с блокировкой памяти и немедленно вернитесь к опросу сокета. Затем используйте логику бизнес-уровня в приложении B , считанную из циклического буфера для фактической обработки.

0 голосов
/ 18 января 2011

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

Вы можете создать хороший механизм надежности, заимствуя понятия из TCP.TCP имеет наиболее общее и изношенное решение - он выполняет неправильную сборку и может масштабироваться до высокой пропускной способности с большой задержкой (с использованием окон ACK) и обладает некоторой адаптивностью к условиям канала.

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

В любом случае ваш общий тайм-аут (для оповещения о сбое доставки на прикладном уровне) должен быть длинным, чтобы вы никогда не ожидали его при нормальной работе.Например, реализации TCP будут ждать более 15 секунд, чтобы отказаться от доставки и сообщить о проблеме на прикладном уровне.

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

См. Также связанные обсуждения на Что вы используете, когдавам нужен надежный UDP? .

...