Запуск сервера и клиента в одном процессе

Вопрос

Я только начал работать с Лидгреном и впервые начал работать в сети, и я осознал, что и сервер, и клиент могут работать в одном и том же процессе.

Не рекомендуется ли эта практика по какой-либо причине?

контекст

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

Следуя моим соображениям, это распределение, которое я имел в виду:

• Одиночная игра - 1 сервер + 1 клиент в одном процессе. Как быстро связь?
• Многопользовательский режим - такой же, как для одного игрока для хоста + 1 дополнительный клиент для каждого другого игрока.

Порядок выполнения, который я представляю, предназначен для клиентов, чтобы получить пользовательский ввод и отправить уведомление на сервер. Затем сервер проверяет его и передает действие, которое должно быть выполнено всеми клиентами. Не должно иметь значения, если есть только один клиент (например, одиночная игра) или несколько клиентов (например, многопользовательская игра).

Это в основном вопрос процесса против потока, оба они не слишком различны, иногда потоки называют легкими процессами. Самое большое отличие состоит в том, что отдельный процесс имеет свое собственное адресное пространство, но есть и другие различия (1):

За процесс

• адресное пространство
• Глобальные переменные
• Открытые файлы
• Дочерние процессы
• Ожидающие тревоги, прерывания и обработчики сигналов

На поток

• Счетчик команд
• Регистры
• стек
• государственный

Исходя из этих различий, может быть удобно иметь серверный и клиентский поток в одном процессе, чтобы вы могли совместно использовать файловые дескрипторы и глобальные переменные. Это будет аргументом для подхода «в том же процессе», другой (маленький) аргумент будет то, что вы получаете только одно всплывающее окно «Брандмауэр Windows» на процесс. Аргументом в пользу подхода «другой процесс» может быть то, что человек может запускать несколько серверов без необходимости запуска нескольких клиентов. Это было бы идеально для выделенного хоста, такого как установка, и это подход, который мы обычно видим в шутерах от первого лица.

Теперь что касается идеи иметь серверный процесс или поток даже для автономной игры (и, возможно, даже для одиночной игры), это отличная идея, которая часто используется на практике. Вы можете сказать, что многие игры делают это, посмотрев на экран загрузки, небольшие подсказки, такие как «получение», откажутся. Это логично, поскольку, если вы собираетесь создать многопользовательский режим, большинство правил игры будут регулироваться сервером, так почему бы не настроить его для однопользовательского режима? Это сокращает код, который вы должны написать, и обеспечивает более четкое разделение между клиентом и «игрой», что улучшит качество вашего кода.

А как насчет связи между процессами и потоками? Межпроцессное взаимодействие может осуществляться разными способами (именованные каналы), общая память, COM, это действительно зависит от технологии, которую вы используете. Однако, если вы создаете сервер, вы, вероятно, захотите использовать сетевой вариант с использованием сокетов и чего-то вроде TCP, и это, конечно, пригодится LIDGREN.

Многие из этих методов также действительны для связи между потоками. Но это зависит еще больше от методов, которые вы используете. Вы можете снова использовать TCP, но, возможно, еще более простой системой будут события и некоторая сортировка, хотя это может сделать ваш игровой цикл недетерминированным (2).

источники

1. Разработка и внедрение операционных систем (книга MINIX), 3-е издание Эндрю С. Таненбаума
2. Исправьте свой временной шаг Гленн Фидлер: http://gafferongames.com/game-physics/fix-your-timestep/