С++ библиотека для обмена сообщениями поверх tcp/udp

В TCP нет приоритетов. В остальном - посмотри на zeromq.

В TCP нет приоритетов. В остальном - посмотри на zeromq.

Мало ли чего там нет. В худшем случае приоритеты наворачиваются в очереди до сокета, в лучшем - заводится несколько TCP соединений кроме приоритетов в очереди. Что касается темы, то скорее всего придётся писать самому. ZMQ тот ещё кусок помоев.

заводится несколько TCP соединений кроме приоритетов в очереди

Прекрасное нерешение.

В TCP/UP нет сообщений, в ZeroMQ нет гарантированной доставки сообщений.

ответ ни о чём

Сервер/клиент должны иметь возможность отвечать на сообщения - сообщениями, в соотсветствии с приоритетами сообщения «запроса».

Есть же IRC! Подними свой IRC-сервер на 6667 порту и юзай паралельно с TCP/UDP.

Попробуйте посмотреть на https://github.com/real-logic/Aeron

Сам не пробовал, но мне ее когда-то приводили в пример системы для обмена сообщениями с поддержкой приоритетов.

сообщения должны уметь в приоритеты(нужно 2 приоритета как минимум: высокий и низкий), сообщения с высоким приоритетом должны стараться прохиваться первыми

Это QoS. Проставляется в IP-header.

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

Ээээ. Это TCP делает просто по умолчанию. Для негарантированной доставки есть UDP.

Заведи 2 очереди и пихай свои пакеты в них, и отправляй сначала из приоритетной очереди потом из второй. Делов на пару часов на голых сокетах

Ещё гугловский protobuf можешь ковырнуть

поверх tcp/udp обмениваться некими сообщениями(бинарными), сообщения должны уметь в приоритеты(нужно 2 приоритета как минимум: высокий и низкий)

Если считать что (потоковые) данные передаются по TCP с нормальным приоритетом, то некоторые данные можно посылать out-of-band, т.е. «срочно». Если нужны преимущества TCP, но без потоковости, а сообщениями как в UDP, то смотреть на SCTP.

Если между хостами нет NAT, то QUIC. Другие варианты, судя по постановке вопроса, ты не осилишь или сделаешь криво.

Наоборот, советовать QUIC страшновато, лучше что-то попроще

Тогда пусть нормально распишет требования к «высокоприоритеным» сообщениям и «гарантированной» доставке:

• После обрыва связи на час - всё равно доставлять или выдать ошибку? (читай - сбрасывать ли на диск)
  
• Жирные сообщения утилизируют всю небольшую ширину канала последней мили?
  
• Выскокоприоритетные сообщения короткие?
  
• Сообщения идемпотентны? Если два раза доставить всё развалится?
  
• Нужна «портабельность» (запускает юзер) или нет (деплоим сами)?
  
• Важен ли порядок между потоками высокоприоритетных/низкоприоритетных сообщений? А внутри потока?
  
• Нужно ли шифрование?

Как простой вариант - взять gRPC, самостоятельно нарезать большие сообщения на куски и отправлять по одному. Плюсы - не нужно парсить протоколы, несколько стримов внутри одного tcp (http2), прозрачный реконнект, можно отменить запрос. Минусы - усложнение сборки (protobuf), для C++ там достаточно запутанный и неудобный API, много магии под капотом.

Кстати, странно, что никто еще не посоветовал HTTP/2.

1. Сообщения пакуются таймаутами, если таймаут указан в неделю - значит доставка должна быть совершена на протяжении этой недели если клиент появляется на связи. 2. Канал бывает 3Г с очень плохой связью, читай - по ссш сложно зайти. 3. Высокоприоритетные сообщения по большей части короткие, до 4х килобайт где-то 4. Дедубликация посылки важна на уровне транспорта 5. Не важна, ПО работающее на стороне клиента свои кишки никак не показывает и работает в связке с сервером(в данном конкретном случае на своём протоколе, который, как я вижу, проще написать. Ибо более-менее готовых решений подходящих я так и не нарыл пока) 6. Скажем так, порядок в рамках одного приоритета важен. 7. Не всегда, пока этот вопрос в приоритете не стоит, ибо зачастую оборачивается в впн

Всем спасибо, думал имеются какие то инструменты дабы не городить велосипеды, но ничего подходящего не нашёл. Можно со спокойной душой городить велосипеды )

Значит доставка должна быть совершена на протяжении этой недели

Тогда тебе не библиотека нужна, а системный сервис-брокер доставляющий низкоприоритетные сообщения с диска. Обычно там можно ограничивать скорость аплоада и поставить QoS на его трафик. Тебе нужна семантика «exactly once», а значит приёмник данных на той стороне тоже должен хранить число прочитанных сообщений на диске. Готовые решения есть, гугли.

Тогда твое приложение должно просто писать в очередь брокера на диске. Высокоприоритетные - zmq, grpc. Голые tcp сокеты опасны тем, что логикой переподключения в случае разрыва легко можно доставить одно сообщение дважды (в новом и старом сокете).

Apache Kafka. Может есть что попроще, без «distributed», но модель нужна такая.

Брокеры не подходят, так как гарантированная доставка через неделю вероятна, но это не основная цель. Основные цели я написал в первом посте. Доставка высокоприоритетных сообщений на протяжении N времени, обычно оно не очень велико, до 5 мин. Сюда входят частые обрывы связи, и перепосылка сообщений с разруливанием дубликатов. Вторая важная задача - это низкоприоритетных сообщения, с таким же отслеживанием дубликатов. Обычно там ходит информация, которая не способна повлиять на важные процессы(грубо говоря, в качестве примера, можно привести мониторинг железа, пример с потолка), но эти пакеты по разным причинам могут содержать, например, мегабайт информации, которая будет очень долго препятствовать высокоприоритетным сообщениям покинуть очередь отправки на плохом соединении.

Соответственно, я вижу разбивку на чанки низкоприоритетных сообщений, например по 4кб, между отправками чанка должны летать ацки, которые сигнализируют о том, что пакет дошёл, если в очереди приоритетных задач есть что-либо, помещать это на отпрвку. На другом конце линии диспетчер который разделяет котлеты и мухи, собирает фрагментированные пакеты и отдаёт дальше на обработку дедубликатору. Онный хранит какое-то кол-во респонсов, если видит дубликат и уже был отправлен пакет, то переотправляется уже сформированный. Я уже разрабатывал пилотную версию протокола, и когда стало всё более-менее понятно, во второй итерации стало интересно, не пилил ли кто уже такое. В первой итерации я не задействовал фрагментатор и дальше понял, что это может испортить немного картину.

не пилил ли кто уже такое

Ты изобрёл малую часть 0mq (nanomsg), там у мультипарт и «дедубликтор» есть.

srt enet