А корень зла был в самом бенчмарке. Дело в том, что помимо смены транспорта планировалась переделка протокола. Не вдаваясь в подробности, скажу, что сообщений должно было стать меньше, они должны были быть больше, но не превышать MTU. Конечно, согласно методологии, переход на новый протокол должен был состояться в следующей итерации, но бенчмарк проектировался с учетом нового протокола, а не текущего. В текущем же было много мелких сообщений, а выбранная библиотека не поддерживала их склейку в один UDP-пакет, преследуя цель как можно быстрее отправить данные. Слишком частые вызовы отправки влияли на пропускную способность, что и приводило к проблемам.
прекрастный пост! прям не дтф, а как минимум хабр 😎
Скорее всего там статья тоже присутствует
написали бенчмарк для сравнения двух библиотек, реализующих RUDP,А какие использовали, в бенчмарках, результаты и какую выбрали, интересно)
Сравнивали собственную разработку Pixockets, на которой работает второй выпущенный проект Dino Squad https://github.com/pixonic/pixockets и LiteNetLib https://github.com/RevenantX/LiteNetLib. Вот тут есть сравнение, которое делалось перед запуском Dino Squad https://habr.com/ru/company/pixonic/blog/499642/
Первый бенчмарк был похожий. Клиенты объединены в комнаты по 12. Отправляют стейт ~1kb раз в 100мс, сервер принимает стейт от клиента и бродкастит другим клиентам в комнате. Результаты были схожими с теми, что в статье. Вкратце: Pixockets > LiteNetLib
Второй бенчмарк отправлял 1 стейт + 10 мелких пакетов. И вот в таком случае всё шло по бороде, задержки росли как снежный ком. При этом на LiteNetLib проблемы не было. Но если в ней убрать склейку мелких пакетов - симптомы те же.
В итоге сейчас используем LiteNetLib.
В закладки, перед сном почитаю
Комментарий недоступен
Комментарий недоступен