Поиск сетевой библиотеки C / C ++ с мультиплексированием
Я пишу приложение, в котором несколько (сотни) параллельных сетевых операций выполняются параллельно между двумя экземплярами. Поскольку средний срок жизни соединения довольно короткий (не более секунды), я подумал, что издержки использования многих соединений TCP и выполнения рукопожатия каждый раз (особенно для рукопожатия TLS) будут слишком большими.
Я начал смотреть на пару протоколов и библиотек, реализующих мультиплексирование (в основном AMQP реализации, такие как Apache Qupid, RabbitMQ, как упоминалось в ответах на этот вопрос). Однако, похоже, что все они работают по протоколу TCP, что создает некоторые накладные расходы и не имеет большого смысла (эта почта объясняет проблему довольно хорошо и приходит к выводу, что мультиплексирование TCP глупо). Также все они чувствуют себя довольно толстыми, я бы предпочел что-то маленькое и легкое (ZeroMQ к сожалению, не реализует мультиплексирование афаик). Это заставило меня задуматься о том, можно ли использовать UDP. Конечно, нужно правильно реализовать такие вещи, как восстановление и ACK, но со знанием о множественных потоках по соединению, что должно быть гораздо более эффективным, чем простое использование TCP.
Вы думаете, что мои рассуждения выше верны, или я что-то упустил? Есть ли хорошие библиотеки C / C ++, которые реализуют мультиплексирование через UDP?
Решение
Сделайте самое простое, что может сработать, и сделайте его более сложным только по мере необходимости:
-
использовать одно соединение TCP и мультиплексировать логические сеансы через него
- например, если эти логические объекты являются просто асинхронными парами запрос / ответ, вы можете полностью отказаться от явных логических сессий
-
если у вас есть несколько одновременных компонентов в каждом экземпляре, который действительно нужны их собственные очереди с возвратом к дросселирующим чрезмерным отправителям:
- сначала рассмотрите возможность ограничить количество невыполненных запросов / активных сеансов на отправляющей стороне, вместо того, чтобы требовать определенного подтверждения
- только если вам нужно динамически изменять длину очереди (например, потому что вы действительно пытаетесь ограничить рабочую память, которая зависит от сеанса), используйте для этого явный логический подтверждение
-
только если вы столкнетесь с ситуацией, когда ваши логические сеансы действительно плохо взаимодействуют с TCP, подумайте о реализации собственного протокола надежных потоков-управляемых дейтаграмм
Другие решения
Других решений пока нет …