Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 10
Судя по описанию, очень классная штука! Спасибо!
Какими каналами можно соединять клиент и сервер? Как насчет UDP и применения для игр типа Quake?
Какими каналами можно соединять клиент и сервер? Как насчет UDP и применения для игр типа Quake?
Yas require C++11 support.Получается, без C++11 не работает?
Какими каналами можно соединять клиент и сервер?
поясните вопрос.
Как насчет UDP
будет, однозначно. так же будет UDT.
и применения для игр типа Quake?
собственно говоря, я не вижу препятствий…
Получается, без C++11 не работает?
да, наша небольшая конторка преимущественно использует С++11.
от С++11 зависимости можно избавиться, но в таком случае придется выбирать и другую сериализацию/десериализацию, ибо YAS так же требует С++11.
поясните вопросЧерез что можно соединить клиент и сервер? C TCP и UDP разобрались. А можно ли их соединить через unix pipe или Unix domain socket? Можно ли разместить клиент и сервер в одном процессе (и одном потоке исполнения) без создания сокетов ради ускорения и экономии ресурсов?
Сколько клиентов можно присоединить к одному серверу?
> А можно ли их соединить через unix pipe или Unix domain socket?
пока нет, но записал в TODO, ибо идея здравая.
> Можно ли разместить клиент и сервер в одном процессе (и одном потоке исполнения)
> без создания сокетов ради ускорения и экономии ресурсов?
оно-то можно, но как же им тогда общаться, без создания сокетов? или, вы подразумеваете Unix domain socket?
> Сколько клиентов можно присоединить к одному серверу?
сервер, входящий в состав этого проекта, в общем-то типовой для наших гейм-продуктов.(из него, по правде сказать, было вырезано Custom Memory Allocation, пул буферов и жендлеров, и еще некоторые части кода, специфичного для наших продуктов.)
у нас он показывает предел на одном ядре, в 50к клиентов. это, приблизительно 300к запросов-ответов в секунду. это я говорю только об IO, ибо логика у нас отделена от IO, и выполняется в отдельном пуле потоков.
пока нет, но записал в TODO, ибо идея здравая.
> Можно ли разместить клиент и сервер в одном процессе (и одном потоке исполнения)
> без создания сокетов ради ускорения и экономии ресурсов?
оно-то можно, но как же им тогда общаться, без создания сокетов? или, вы подразумеваете Unix domain socket?
> Сколько клиентов можно присоединить к одному серверу?
сервер, входящий в состав этого проекта, в общем-то типовой для наших гейм-продуктов.(из него, по правде сказать, было вырезано Custom Memory Allocation, пул буферов и жендлеров, и еще некоторые части кода, специфичного для наших продуктов.)
у нас он показывает предел на одном ядре, в 50к клиентов. это, приблизительно 300к запросов-ответов в секунду. это я говорю только об IO, ибо логика у нас отделена от IO, и выполняется в отдельном пуле потоков.
оно-то можно, но как же им тогда общаться, без создания сокетов?Закидывать задачу в свою же asio::io_service, единственную в процессе и вообще в программе при таком запуске. Вроде бы, для этого много изменений кода не потребуется. Путь информации: клиент — сериализация — io_service — десериализация — сервер.
А можно маршрут ещё сократить: клиент — сервер. То есть, чтобы клиент прямо вызывал методы сервера (они же в одном потоке, сам Бог велел так делать). Для такого придётся внести какие-то изменения в код библиотеки. При этом убивается асинхронность. Зато экономия на сериализации. Если клиент и сервер действительно расположены на одной машине, то это должно приводить к уменьшению времени пинга. Пример: сервер quake и бот на этом же сервере. Кажется, в quake боты действительно «срослись» с сервером гораздо сильнее, чем удаленные игроки. Возможно, поэтому quake быстро бегает с ботами даже на VPS.
Хочется, чтобы эта оптимизация была реализована «прозрачно», а не захардкожена в игровой движок как в quake. Чтобы можно было 1 раз написать код бота, которого можно было бы и запускать удаленно, и «сращивать» с сервером.
Посмотрите лучше на m4.
Был опыт написания подобной штуковины и тоже первая версия была на boost.preprocessor, в итоге через некоторое время я сам перестал понимать что там происходит, не говоря о других.
— Добавлять новые фичи во «фреймворк» стало просто пыткой, т.к. отлаживать макросы то еще удовольствие, а бустовые — удовольствие вдвойне.
— Если при декларации RMI функции допускаешь синтаксическую ошибку — компилятор выдает портянки текста с чем угодно но не с местом, где я ошибся.
— Ошибка в рантайме, где-то в середине RMI вылезло непонятное исключение — можно стреляться, отладить это будет очень сложно. Любые ошибки в RMI у коллег — 100% летят к вам.
— Когда синтаксис описания функций расшириться (ну захотите сделать in\out параметры, именованные параметры и т.п.) кода в макросах станет на порядок больше и начнутся глюки с компилятором, например VS 2012 периодически падал или выдавал ошибки на валидные конструкции.
Продолжать можно бесконечно, но у истории happy-end — я перешел на кодогенерацию через m4, которая выполнятся до компиляции и сохраняет получившийся cpp файл. Теперь проблем почти не возникает, очень советую.
Был опыт написания подобной штуковины и тоже первая версия была на boost.preprocessor, в итоге через некоторое время я сам перестал понимать что там происходит, не говоря о других.
— Добавлять новые фичи во «фреймворк» стало просто пыткой, т.к. отлаживать макросы то еще удовольствие, а бустовые — удовольствие вдвойне.
— Если при декларации RMI функции допускаешь синтаксическую ошибку — компилятор выдает портянки текста с чем угодно но не с местом, где я ошибся.
— Ошибка в рантайме, где-то в середине RMI вылезло непонятное исключение — можно стреляться, отладить это будет очень сложно. Любые ошибки в RMI у коллег — 100% летят к вам.
— Когда синтаксис описания функций расшириться (ну захотите сделать in\out параметры, именованные параметры и т.п.) кода в макросах станет на порядок больше и начнутся глюки с компилятором, например VS 2012 периодически падал или выдавал ошибки на валидные конструкции.
Продолжать можно бесконечно, но у истории happy-end — я перешел на кодогенерацию через m4, которая выполнятся до компиляции и сохраняет получившийся cpp файл. Теперь проблем почти не возникает, очень советую.
А с какой целью был еще один велосипед запилен, ну, за исключением любви к искусству?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
RMI средствами С++ и boost.preprocessor