Чем ловить UDP в современных плюсах?

Я лет пять назад тоже стоял перед таким выбором. Выбрал asio (отдельной либой, не boost), вроде бы всё получилось. Но логика работы с asio довольно непривычная после Qt. Всякие пулы, асинки и всё такое.

Если без GUI, то первый вариант, а если с GUI, то надо посмотреть. Я не сторонник Qt.

Если хочешь прямо стандартное, то в C++ уже почти завезли поддержку сети.

https://en.cppreference.com/cpp/experimental/networking

выбирая между Boost.Asio и QtNetwork - я за qt, т.к. их система сигнал/слот очень тут приятна - принял пакет и отдал его через сигнал

Я бы взял Standalone Asio. А в сторону Boost.Asio смотрел бы только в случае, если бы для проекта еще что-то из Boost-а потребовалось бы.

Сишные сокеты

в плюсовой программе…

Можно сделать обертку, если так уж хочется.

это мои личные тараканы.

Да!

Boost.Asio.

А какую проблемумс решаемс?

Сишные сокеты (<sys/socket.h> и всё такое). Гарантированно будет работать, но как-то в плюсовой программе… ну неопрятненько, что ли. Хотя возможно, это мои личные тараканы.

Никогда не понимал такого. Если нужна будет функциональность ffmpeg/sqlite/zstd/libjpeg/какой-нибудь криптографии, тоже какой-то комбайн нужно будет брать? А потом линкер сломается, потому что бинарник будет >=2 Gb.

https://github.com/fffaraz/awesome-cpp#networking, Ctrl-F, UDP.
https://github.com/chronoxor/CppServer выглядит годным:

Ultra fast and low latency asynchronous socket server & client C++ library with support TCP, SSL, UDP, HTTP, HTTPS, WebSocket protocols and 10K connections problem solution.

Has integration with high-level message protocol based on Fast Binary Encoding.

https://github.com/chronoxor/CppServer#features:

• Cross platform (Linux, MacOS, Windows)
• Asynchronous communication
• Supported CPU scalability designs: IO service per thread, thread pool
• Supported transport protocols: TCP (github.com), SSL (github.com), UDP (github.com), UDP multicast
• Supported Web protocols: HTTP, HTTPS, WebSocket, WebSocket secure
• Supported Swagger OpenAPI iterative documentation
• Supported message protocol based on Fast Binary Encoding

Если с нуля, то бери qt, там много всего вкусного, что можно притащить в приложение в едином стиле. Очень сильно сокращает время разработки. Имно шобы для спп не брать qt, нужно обоснование, а не наоборот.

Рекомендую Boost.Asio

Я использую свою либу. Я не уверен, что в ней есть udp, но если мне нужно будет, то появится :)

за протаскивания блоатваре в проекты полагается расстрел!

Я взял сначала boost:asio. Потом посмотрел на этого монстра и решил на чистой C-шечке написать работу с сокетами. https://github.com/skbuff-ru/muRPC/tree/master/src/cepoll

Для всего вышеперечисленного есть обвязки для более удобной работы в C++

1. А для позиксных сокетов — нет, получается? Нужно комбайны тащить?

2. Есть, но это же хелловорлды. Их авторы могут просто забить на них. Недостаточно быстро реагировать на изменения в C API. Ну или просто решат их снести или их зохавает вирус. И из-за очередной «обёртки над gethostname()» ваш проект перестанет собираться или сделает вам патч Бармина.

Вот я загуглил “ffmpeg c++”. Открыл первый результат: https://github.com/Raveler/ffmpeg-cpp : 8a6cec3 · 7 years ago.

ffmpeg постоянно ломает API, если что.

Boost и Qt есть в репозиториях дистрибутивах хотя бы.

---

Глупость какая-то, в общем. Может, и не весь C++. Но абстрагироваться от той части, которая Си, и тащить всякие leftpad-ы — точно глупость.

Для всего вышеперечисленного есть обвязки

В теории - да, но на практике - нет. Помимо описанной выше проблемы

1. Автор(ы) обвязки часто покрывают только свой сценарий использования, и не весь API представлен.
2. Обработка ошибок либо отсутствует, либо захардкожена внутри обвязки.

По факту почти всегда проще иметь дело с сишной либой напрямую.

, надо принимать и обрабатывать UDP-пакеты.

Ну так принимай и обрабатывай. Тут же нет 100500 соединений. Тут один порт и всё валится на него. Всё что можно сделать: это быть готовым принимать пачками и с доп информацией. Но это не про С++, а про системный вызовы, которым к чёрту не сдались какие-то там плюсовые обёртки. Да же больше, проще написать короткий файлик с парой функций на голом Си, чем городить нечто СиПлюсПлюсЭдаКое из-за разности требований к инициализации структур.

Хочешь что-то этакое на плюсах: возьми модель акторов или что душе угодно. И перерабатывай эти пакеты там.

Если нужна будет функциональность ffmpeg/sqlite/zstd/libjpeg/какой-нибудь криптографии, тоже какой-то комбайн нужно будет брать?

какой-нибудь криптографии

Конечно. Самостоятельно криптографию реализовывать нельзя.

Постарайтесь, пожалуйста, вникнуть в контекст того, что я писал. И предлагал ли реализовывать что-либо с нуля.

И ответить на вопрос: почему криптографию нельзя, а ffmpeg, zstd или libjpeg «самостоятельно реализовывать» можно, хотя ошибка там тоже с большой вероятнстью приведёт к уязвимости?

И что вы понимаете под «криптографией»? А то мне, может быть, деньги платили за это, а посоны-то и не знали, что нельзя.

Не так часто приходится начинать проекты с нуля, поэтому хочется сделать красиво.

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

А что обрабатывать то? Я бы написал класс - обёртку над обычными юдп сокетами и им же ловил пакеты. Это вариант если не лень, но дел максимум минут на 30

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

Ну и как третий вариант на гошечку перейти, там такого нет) (шутка)

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

Да, с ffmpeg я работал напрямую, без комбайнов. Но он сам по себе мегакомбайн, хоть и сишный.

А вот когда понадобился JPEG, пришлось взять маленькую библиотеку стороннего автора и долго её патчить, потому, что оригинал не был рассчитан на работу с битыми изображениями и в случае битых смещений в таблицах Хаффмана ронял всю программу.

бери qt, там много всего вкусного

Ты знаешь, меня за Qt агитировать не надо, я ей пользуюсь около 20 лет.

Сигналы-слоты дело хорошее. Но в этом случае такое дело, что чем меньше будет всяких памперсов, тем лучше. Тут обрезанный процесс с чёткой функцией: получать информацию (не только по сети), писать её на диск в согласованном виде, эпизодически обмениваться статистикой с другими программами (в том числе той, которая занимается GUI, вот там будет Qt, да). Всё. И даже кутешная очередь сообщений, которую я не контролирую, может оказаться лишней.

Причём поток информации будет весьма плотный, падать программа не должна, терять информацию тоже не очень желательно (по вине программы, естественно, про то, что UDP доставку не гарантирует, я знаю). Поэтому программы я порезал так, чтобы каждая занималась сугубо своим делом, разделением полномочий пусть ОС занимается, у неё это по-любому получится лучше, чем у меня.

Я даже думал про ОС РВ, но мало того, что там вообще всё сложнее – её тут надо очень серьёзно обосновывать, явных требований к времени отклика в проекте нет. А к линуксу заказчик готов.

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

Вот именно поэтому сппшники никому нах и не нужны и вымирают, шо могут накатать телегу, почему в 26 году надо изобретать очередной 7 колёсный велосипед и в 100500 раз ходить по граблям по которым уже прошли 100500 других людей. Ну шош таков путь мамонтов и динозавров.

Причём поток информации будет весьма плотный, падать программа не должна, терять информацию тоже не очень желательно

Что бы выбрали вы в 2026 году?

уже что-то более стандартное и надёжное появилось?

начинать проекты с нуля, поэтому хочется сделать красиво.

Не утерплю. Ты, похоже, хочешь раст(на худой случай go), но ещё не осознал этого. За пределами Qt в плюсах жизни реально нет, всё сделано через такую уродливую бажную жопу что практического смысла это не имеет, только если себе и пользователям на зло. Многопоточка, асинк, плотный поток информации, сложный алгоритм, надёжность/технологичность - однозначно раст. Это я по опыту если чё, как бывший(надеюсь) плюсовик/сишник

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

Ох ты ж… макаронная громоздкость сишки это наименьшая из её бед.

почему в 26 году надо изобретать очередной 7 колёсный велосипед

У меня тут под боком второй день контора разгребает завалы C#/Java/JS версий библиотек с уязвимостями, перетряхивая все свои проекты.

Как по мне - свои грабли лбу приятнее должны быть.

Пардон за оффтоп.

Многопоточка, асинк, плотный поток информации, сложный алгоритм, надёжность/технологичность - однозначно раст.

Это уже совсем офтопик, но раз ты так категорично настроен… Есть какая-то вменяемая хаутушка, как создать вменяемую среду разработки на расте локально без интернета? Чтобы предварительно всё потенциально нужное скачать и пользоваться этим в локальной сети, а то и на отдельной машине?

я бы не стал ставить вопрос про UDP сокеты, а ставил бы вопрос про протокол высшего уровня

то есть если он уже есть то брать его реализации

если его нет - подумать еще раз, потом еще раз пять, и на крайний случай взять какой-нибудь QUIC или вариации на тему RUDP и подобного

Да просто https://doc.rust-lang.org/cargo/commands/cargo-vendor.html - и всё, редакторы( которыми я пользуюсь) vscode/zed разницы не должны видеть. Обычно, достаточно отдельный крейт скачать и локальный путь в cargo.toml к исходникам прописать, и понадобилось подобное только чтобы исходники поправить под себя.

1. Сишные сокеты (<sys/socket.h> и всё такое).

я за это, с учетом того что udp просто как 2 копейки, читаешь буфер и все..

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

Вот именно поэтому сппшники никому нах и не нужны и вымирают,

«Не нужность» и «Вымирание» это статус, которым обладают абсолютно все, в том числе и ты. Так что не зазнавайся. Использовать готовые сторонние библиотеки или самому работать с сокетами, у каждого из этих подходов есть свои плюсы и минусы. Принимать что-то по UDP не такая уж великая задача, чтобы сильно париться.

За пределами Qt в плюсах жизни реально нет, всё сделано через такую уродливую бажную жопу что практического смысла это не имеет,

Вот за это не люблю растаманов. Rust - прикольный язык, с интересными решениями и технологиями. Портит его только упоротость сообщества, сформировавшегося вокруг этого языка.

В моей либе кстати udp есть, оно используется для реализации асинхронного резолвера: https://github.com/resetius/coroio/blob/7b0213976114ece81c6c1698d848607157e05893/coroio/dns/resolver.hpp#L237

Ставьте звезды кстати. Мне 5 штук не хватает на ачивку :)

Ставьте звезды кстати.

Хотел, но уже поставил раньше, оказывается. :)

THostPort(const std::string& host, int port);
...
int Port;

Семён Семёныч!…

Там разные первые буквы.

Попробуй ещё раз.

вопрос не однозначный

если бы вы разбирались то наверное бы не спрашивали, по этому для новичков

если нужна работа на уровне сокетов то буст или любая другая библиотека на гитхабе

если нужна работа на более прикладном уровне, где есть возможность кастомизировать и где транспорт нужен UDP

то можно поиграться с librats или взять попроще, старый добрый enet