Должен ли сокет-сервер и игровой сервер быть отдельными процессами?

Предположим, простая стандартная клиент / серверная игра. Для сервера стоит ли иметь отдельный процесс, который прослушивает соединения и сообщения от клиентов и отправляет данные через локальные сокеты или stdin другому процессу, который выполняет настоящий игровой сервер?

Другим вариантом было бы сделать обе вещи в одном процессе. В очереди входящих сообщений и их выполнении в правильном порядке не должно быть проблем с остановкой.

Мне интересно, стоят ли на самом деле дополнительные ресурсы для разделения этих двух «видов деятельности». Как мне решить? Я хотел бы услышать любые плюсы / минусы.

С точки зрения разработки API, при принятии решения о создании нескольких отдельных программ связи или только одной, возникает вопрос: может ли каждая программа функционировать осмысленно без других? Ответ будет варьироваться в зависимости от вашего проекта и предпочтений.

Если они не могут , об этом не стоит думать. Очевидно, что они настолько тесно связаны, что на самом деле они не являются отдельными процессами.

Если они могут , и вы можете увидеть, что в будущем захотите добавить другие компоненты, чтобы заменить их, то абстракция процесса, предоставляемая ОС, может помочь.

Как сильно это помогает зависит от остальной части вашего стека технологий , хотя. Например, Erlang уже внутренне моделирует вещи как процессы, поэтому вы не получите большую концептуальную выгоду, если разделите их также на процессы ОС. Если вы не думаете, возможно, переписать эти части сервера на другом языке. Внутренние компоненты программы на C ++ обычно связаны гораздо теснее, и поэтому их сложнее заменить, поэтому их разделение на различные процессы ОС может спасти вашу работу позже, если вы сможете предвидеть такие перестановки.

Стоит ли иметь отдельный процесс, который прослушивает соединения и сообщения от клиентов и отправляет данные через локальные сокеты или stdin другому процессу, который запускает реальный игровой сервер?

Чтобы ответить на вопрос, стоит ли это делать, вам нужно было сначала спросить себя, какую проблему вы пытаетесь решить, добавив выделенную службу очередей. Если это решает эту проблему, тогда это стоит; если это не решает проблему или если у вас нет проблемы, которую нужно решить, для начала, то, вероятно, это не так.

Давайте посмотрим, почему некоторые серверы используют многоуровневую архитектуру:

1. Балансировка нагрузки - балансировка нагрузки имеет смысл, если вы хотите распределить рабочую нагрузку на несколько рабочих компьютеров. Если в вашей программе есть узкие места, которые вы хотите устранить, просто имея несколько параллельных рабочих процессов на одной машине, то в долгосрочной перспективе лучше всего на самом деле устранить узкие места, но в качестве краткосрочного обходного пути могут быть полезны порождающие рабочие процессы.
2. Разделение привилегий - Возможно, вы не хотите, чтобы брешь в безопасности на вашем сервере чата автоматически получала доступ к вашему игровому серверу или наоборот. Если ваш игровой сервер отделен от игрового сервера чата, вы можете настроить свой игровой сервер и сервер чата для работы в отдельном домене безопасности (например, запускать от имени другого пользователя, с разными правами доступа, разными ограничениями процесса и т. Д.).
3. Обновление с нулевым временем простоя - если вы хотите обновить нулевое время простоя, вам нужно иметь несколько уровней и настроить систему таким образом, чтобы при отключении сервера для обслуживания его запросы были перенаправлены на другие серверы того же уровня, чтобы обеспечить непрерывную работу. служба.
4. Предел нарушения - если вы достигнете предела сокетов, предела дескриптора файла, глобальной блокировки интерпретатора и т. Д., Вы сможете обойти этот предел, запустив несколько процессов. Другой способ решить эту проблему - изменить ограничение, но это не всегда просто, поскольку вам может потребоваться перекомпилировать ядро, или это может повлиять на безопасность или производительность.
5. Ограничение утечки ресурсов - вы хотите написать программное обеспечение, которое не пропускает ресурсы, но даже на языках с полностью управляемым мусором это чрезвычайно сложно в долгоживущих процессах, и, что еще хуже, это трудно воспроизвести в среде разработки. Многоуровневая архитектура позволяет убивать и перезапускать игровые серверы через определенное количество времени или количество запросов, чтобы ограничить ущерб от утечек ресурсов, не прерывая работу службы.

Я согласен с трещоткой урод. Пока у вас есть один игровой сервер, это не стоит хлопот.

Тем не менее, эта архитектура может оказаться полезной, когда вам нужно масштабировать горизонтально. Когда одного игрового сервера уже недостаточно, и вам необходимо распределить свою игру по нескольким игровым серверам по соображениям производительности, архитектуру «сокет-сервера» можно очень легко адаптировать, чтобы превратить сокет-сервер в балансировщик нагрузки, который автоматически маршрутизирует соединения с одним из многих бэкэндов. сервер.

Но когда вы не уверены, что вам это когда-нибудь понадобится, вероятно, на данный момент слишком сложно разработать два отдельных серверных приложения.

Вероятно, это не так, большинство языков имеют асинхронные сокеты, которые позволяют вам использовать несколько соединений одновременно без блокировки, пока данные ожидают. Это смещает часть «сокет-сервер» в ОС / ядро.

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