UDP пакеты могут теряться, это нормально.

Для начала просто увеличь размер буфера сокета.



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

Асинхронно обрабатывать. Сделай структуру для хранения текущего состояния обмена в одним авторизующимся, там храни все что касается его, т.е. текущее состояние синхронизации. Назовем ее auth_t
У каждого спрашивающего есть какой-то свой уникальный IP:порт, используй его как идентификатор.

Все структуры собери в map


Чтобы компараторы не писать можешь "IP:порт" преобразовать в int64_t

Дальше алгоритм простой, в цикле:
ждешь UDP пакет, по приходу пакета получаешь указатель на структуру данного отправителя


по данным из пакета и структуры формируешь ответ, меняешь состояние авторизации в структуре и т.д. и т.п. Вобщем все что там у тебя по алгоритму обмена положено.
В начало цикла.

Так хоть 100500 параллельно обрабатывай.

Mari.PОсталось придумать как опрос разбить на шаги.
допустим опрашиваю в цикле часовые архивы. приходит ответ <IP:port:номер шага>
и получается, что надо нырнуть в середину цикла опроса часовых архивов, если перед этим занималась чем-то другим.
Запоминать состояние в структуре auth_t, т.е. при отправке запроса запоминаем там: отправлен запрос архива, а по приходу ответа смотрим там что запрашивали.

Mari.PА перед входом в цикл там куча значений вычисляется (маркер архива, общее число показаний и тп, индекс цикла)
Если это все поместить в структуру, описывающую узел периферии, то это монстр какой-то получится.

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

Можно по другому, оставить твой алгоритм как есть. Если одновременно обменов не много, то можно сделать через отдельные потоки и очереди. Вместо очереди можешь UDP порт на 127.0.0.1 использовать.
Делаешь хранилище очередей


При запуске потока обмена он открывает UDP сокет на 127.0.0.1:* и регистрирует его в queue

Поток приема UDP принимает пакет со внешнего порта, находит в queue локальный порт куда переслать и пересылает.

Поток обработки принимает с локального порта, а отправляет во внешний.

Mari.PDima T,

Как сказать немного, узлов 300, задачу авторизации каждый узел генерит 1 раз в 5 мин...
Не обязательно 300 потоков постоянно держать. Хотя можно и держать, комп выдержит, но некрасиво это.
Одновременно, как понял, максимум обмен с 2-3 узлами идет, поэтому лучше так: при необходимости обмена с конкретным узлом запускается отдельный поток, обменивается и завершается. Тогда лишних потоков висеть не будет.

Dima TПоток обработки принимает с локального порта, а отправляет во внешний.
Если так будешь делать, то отправку во внешний не забудь обернуть в блокировку мутексом, чтобы разные потоки одновременно не слали. Принимать одним потоком и слать другим можно, а вот слать несколькими - это под вопросом.

Шаблон проектирования Producer-Consumer .

ИМХО лишнее это, он для высоконагруженных систем, для 300 обменов раз в 5 минут одного потока хватит.

Dimitry SibiryakovРаз у аффтара теряются пакеты, значит не хватает.

Не теряются, она их сама не обрабатывает, т.к. алгоритм синхронный 20175832
Mari.Pпроблема в том, что один сеанс обмена с периферией, это примерно 30 запрос-ответов, и в это время приходит задача авторизации от другого узла периферии, которая сейчас просто игнорируется до окончания сеанса обмена с текущим узлом.

Mari.PУ меня один вопрос - допустим один поток ждет пакет UDP на порту 1234.



Другой поток может посылать пакеты по UDP в тот же порт 1234?
Это не приведет к тому, что первый поток ничего не дождется?
Что пришлют то и получит.
Слать можно откуда угодно, открывай в другом потоке новый сокет и шли с него на 127.0.0.1:1234.