NanoMsg (NNG) & amp; FlatBuffers правильно подходит для этого проекта?
Кричите, если есть что-то лучшее, что мы должны рассмотреть:
Я ищу очень быстрый и простой способ получить несколько программ (например, 5) — каждая из которых работает на отдельных узлах в частном облаке OpenStack для общения друг с другом.
- Пакеты будут короткими структурами C ++ (менее 100 байт)
- Трафик будет легким (вероятно, менее 100 в секунду)
- Задержка действительно не проблема. (что такое несколько мс между друзьями?) — у нас много циклов и памяти
- Сообщения должны быть сделаны как парадигма pub / sub клиент / сервер
- Библиотека должна быть дружественной к C ++. Но работают как на Windows, так и на Linux
- Нам могут понадобиться дополнительные языковые привязки позже
- Мы бы предпочли не терять сообщения
Вот первая идея, которая у меня есть. Но если вам есть что предложить. Прокричать.
Friendly Wrapper для уровня сокетов UDP:
- NanoMSG (NNG, так как это активный проект nanoMsg) https://github.com/nanomsg/nng
Кодировщик / Декодер для структурных данных C ++:
- FlatBuffers https://google.github.io/flatbuffers/
Решение
Для сериализации подойдет практически все, что связано с правильными языковыми привязками. Буферы протокола Google не зависят от языка, доступно множество привязок. Единственное, чего следует избегать, так это сериализации, встроенной в ваш исходный код (например, сериализация Boost — это / was), потому что тогда вы не сможете легко перенести это на другой язык.
Для передачи сообщений ZeroMQ, NanoMsg являются хорошим выбором. Тем не менее, я думаю, что это действительно сводится к
- Как сильно вы не хотите терять сообщения,
- Именно то, что вы подразумеваете под «потерянным сообщением».
Что касается ZeroMQ (и NanoMsg), так это то, что (AFAIK) нет реального способа узнать судьбу сообщения при возникновении ошибки. Например, в ZeroMQ, если вы отправляете сообщение, а получатель просто работает и подключен, сообщение передается по соединению. Конец отправки теперь думает, что работа выполнена, сообщение доставлено. Однако, если и до тех пор, пока принимающая сторона на самом деле не вызывает zmq_recv() и полностью обрабатывает полученное сообщение, оно все равно может потеряться в случае сбоя процесса принимающей стороны, сбоя питания и т. д. Это происходит потому, что до тех пор, пока оно не будет использовано, сообщение сохраняется в ОЗУ в потоке выполнения ZeroMQ (внутри соответствующий Context()домен контроля экземпляра).
Вы можете объяснить это, имея какое-то подтверждающее сообщение, отправляющееся в обратном направлении, время ожидания и т. Д. Но это начинает нервничать, и вам будет лучше с чем-то вроде RabbitMQ.
Другие решения
С величайшим уважением к работе Маргарет Хэмилтон в программе «Аполлон».
Прокричать.
Уважаемый доктор.,
Есть много особенностей, которые станут важными для профессионального решения, которые не были упомянуты в списке покупок выше.
Если пример Apollo AGC может помочь здесь, тем лучше.
Пакет в поисках:
- должен держать ваш код под контролем относительных приоритетов обработки,
- должен позволять увеличивать / уменьшать / отображать использование пула ресурсов IO-потоков для каждого канала,
- следует разрешить установку тегирования приоритетов ToS для транспорта L3 +,
- должен позволить одному изменить ресурсы реализации стека L3 / L2, сконфигурированные O / S,
- должны разрешать неблокирующие элементы управления со стороны прикладной программы, без риска каких-либо блокировок,
- должен обеспечить широкий портфель транспортных классов, охватывающих {inproc: | IPC: | tipc: | tcp: | УДП: | VMCI: | пгм: | epgm:} по мере необходимости, чтобы работать в миксе
если все, что звучит важно для ваших дальнейших усилий в Draper Lab, ZeroMQ будет плавно вписываться (если некоторые показатели латентности / производительности, возможно, потребуется повысить на стероидах, поскольку они более важны, чем зрелая смесь, описанная выше, может также понравиться рассмотреть другого ребенка Мартина Сустрика) моложе его ZeroMQ — то nanomsg инструменты ).
Во всяком случае, если у вас действительно есть (Соч.) «… много циклов и памяти …«, просто впустите меня, у меня есть много TFLOP для обработки, если вы позволите, в свободное время :o)
Nota Bene:
Учитывая недавние комментарии, позвольте мне добавить замечание об использовании опубликованной NACK-ориентированной надежной многоадресной передачи (NORM). norm:// транспортный класс, который может помочь вашему чистому PUB/SUB— замыслы дизайна, для которых, кажется, это можно исправить желание «предпочитаю не терять сообщения«В противном случае это не обойдется стороной, согласно Zen-of-Zero, который оставляет все такие операции в коде приложения на стороне пользователя и распределенная система поведение.