ZeroMQ и TCP ретранслируют в Linux - PullRequest
Новая
       26

ZeroMQ и TCP ретранслируют в Linux

0 голосов
/ 08 сентября 2018

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

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

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

Может ли эта проблема возникнуть при использовании ZeroMQ?В настоящее время я использую PUSH / PULL в ОС Linux.

Или это не проблема, и если нет, то почему?

Крайне важно, чтобы сообщения от внешних устройств / приложений неустаревшие данные фида.

1 Ответ

0 голосов
/ 12 сентября 2018

Во-первых, единственный транспорт, где возможны повторные передачи, - это TCP через реальную физическую сеть. И тогда, вероятно, не в локальной сети, так как маловероятно, что пакеты Ethernet пропадут в локальной сети.

Внутренний TCP для компьютера, и особенно IPC, INPROC и т. Д., Каждый раз гарантированно обеспечивает доставку данных каждый раз. Механизм ретрансляции отсутствует.

Если один из транспортов, используемых сокетом, испытывает задержки из-за ошибок передачи, это замедлит работу. ZMQ не может считать сообщение «отправленным», пока оно не будет передано через все транспорты, используемые сокетом. Внешняя видимость «отправлено» такова, что очередь исходящих сообщений отошла от верхней отметки на 1.

Возможно, что любое одно сообщение будет доставлено через IPC раньше, чем TCP, и возможно, что сообщение 2 будет доставлено через IPC до того, как сообщение 1 будет получено через TCP. Но если вы полагаетесь на синхронизацию сообщений / относительный порядок, вам не следует использовать ZMQ в первую очередь; это актерская модель, а не CSP.

РЕДАКТИРОВАТЬ Для Фрэнка

Разница между Actor и CSP заключается в том, что первый асинхронный, второй синхронный. Таким образом, для модели Actor отправитель имеет нулевую информацию о том, когда получатель действительно получает сообщение. Для CSP отправка / получение - это рандеву исполнения - отправка завершается только после завершения приема.

Это может быть очень полезно. Если в вашей системе А не имеет смысла инструктировать С делать что-то до (во времени, а не только в потоке кода А) инструктажа В, то вы можете сделать это с помощью CSP (но не модели Actor). Это происходит потому, что когда A отправляет B, B получает сообщение до того, как завершается отправка A, освобождая A для последующей отправки в C.

Неудивительно, что системы реального времени выигрывают от CSP.

Итак, рассмотрим модель Actor в ZMQ со смесью транспортов TCP, IPC и INPROC в ZMQ. Существует большая вероятность того, что сообщения, отправленные через TCP, придут намного позже, чем сообщения, отправленные через INPROC, даже если они были отправлены первыми.

...