Использовали ли вы Boost для сетевого взаимодействия?
Что проверяют
Работали ли вы с асинхронной сетью в C++ руками или знаете Boost.Asio по примерам из документации. Следом спрашивают про модель: кто вызывает обработчики, как живут объекты сессии, как устроены потоки и что делать с таймаутами.
Как отвечать
Если опыт есть, начните с задачи: что за сервис, какой протокол, сколько соединений, почему Asio. Дальше покажите механику:
io_context: цикл событий. Операцииasync_read,async_write,async_acceptзапускаются сразу, а обработчики завершения вызываются в потоках, где крутитсяrun(). Старое имяio_serviceустарело ещё в Boost 1.66 и выдаёт знания из старых туториалов;- время жизни: сессия наследует
enable_shared_from_thisи отдаётshared_from_this()в обработчик, иначе объект и буфер умрут раньше, чем завершится операция; - потоки: несколько потоков вызывают
run()на одномio_context, а обработчики одной сессии сериализуются черезstrand, без мьютексов; - корутины C++20:
co_spawnиawaitableпревращают цепочку колбэков в линейный код, для нового проекта это обычный выбор; - таймауты: у сокетов Asio их нет, делают через
steady_timerили берутbeast::tcp_streamсexpires_after; - протоколы сверху: Boost.Beast для HTTP и WebSocket,
ssl::streamдля TLS.
Цифры называйте свои и с условиями: сколько соединений, какая латентность, на каком железе и как мерили.
Если с Boost не работали, скажите прямо и расскажите, что использовали: сокеты с epoll, libuv, Qt Network, gRPC. Затем покажите, что понимаете модель Asio. Сетевой библиотеки в стандарте C++ до сих пор нет, поэтому Asio остаётся стандартом де-факто.
Где спотыкаются
Вызывают async_write повторно, пока предыдущая запись не завершилась. Данные перемешиваются, нужна очередь исходящих сообщений.
Передают в асинхронную операцию буфер со стека. Функция возвращается сразу, а операция потом работает с уже освобождённой памятью.
Забывают, что run() возвращается, когда работы не осталось. Потоки пула, запущенные до первых операций, без executor_work_guard сразу выходят.