Есть ли руководство по переходу с простых сокетов udp (linux, C99 / C ++, recv syscall) на необработанные сокеты?
Согласно http://aschauf.landshut.org/fh/linux/udp_vs_raw/ch03s04.html raw socket намного быстрее, чем udp.
Приложение клиент-серверное. клиент является проприетарным и должен использовать точно такой же протокол, как и с udp-сервером. Но сервер может быть немного быстрее с сырыми сокетами. Какие части udp я должен реализовать на сервере? Есть ли библиотеки "быстрой миграции"?
Необработанный сокет позволяет вам взаимодействовать с протоколами более низкого уровня, такими как Ethernet, IP и т. Д. Да, переход на более низкий уровень может дать вам некоторые преимущества, однако вы должны уравновесить это с тем, что вы теряете.
В этом случае вы упоминаете, что сервер написан для использования протокола Udp, поэтому на проводе связь должна быть Udp. Теперь, если вы собираетесь использовать необработанный сокет, вам нужно будет убедиться, что данные вашего приложения инкапсулированы в пакет Udp. Вам также нужно будет написать код, чтобы убедиться, что вы подчиняетесь протоколу Udp и конечному автомату, чтобы для сервера ваш клиент выглядел просто как еще один клиент Udp. Все это требует написания большого количества кода и имеет некоторые недостатки в виде повышенного обслуживания, увеличения затрат на правильную работу и т. Д.
Я не полностью прочитал статью, на которую вы ссылались выше, но вопрос, который следует задать себе, заключается в том, можете ли вы получить результаты, указанные в этой исследовательской статье, и воспроизвести их для своего сценария?
На мой взгляд, вы должны сначала попытаться выяснить, почему ваш клиент такой медленный. Каковы ваши требования? Есть ли у вас какие-либо показатели того, что можно считать хорошим и быстрым клиентом? На вашем месте я бы сначала измерил текущую реализацию, имея в виду некоторые показатели, которые полезны для сценария, например, количество переданных байтов / сек и т. Д. Затем я бы профилировал клиента, чтобы увидеть, где он тратит слишком много времени, и попытаюсь понять, смогу ли я уменьшить накладные расходы и сделать это намного быстрее.
Подводя итог, ищите экономию в верхней части стека (то есть в своем приложении), прежде чем спускаться вниз по стеку. Если ваше приложение написано некорректно, то, как бы низко вы ни опустились, вы не увидите ожидаемого прироста производительности.
