Чи повинні сервер сокет і сервер ігор бути окремими процесами?

Припустимо просту стандартну гру клієнт / сервер. Чи варто для сервера мати окремий процес, який прослуховує з'єднання та повідомлення клієнтів і передає дані через локальні сокети або stdin до іншого процесу, який запускає власне ігровий сервер?

Іншим варіантом було б, щоб обидві речі були виконані в один процес. Чергування вхідних повідомлень та виконання їх у правильному порядку не повинно виникати.

Мені цікаво, чи варто зайвих ресурсів для розділення двох «видів діяльності». Як я повинен прийняти рішення? Я хотів би почути будь-які плюси / мінуси.

З точки зору дизайну API, коли вирішувати, чи робити кілька окремих комунікаційних програм або лише одну, виникає питання: чи може кожна програма функціонувати доречно без інших? Відповідь буде залежати від вашого проекту та вподобань.

Якщо вони не можуть , думати про це не варто. Очевидно, вони настільки сильно пов'язані між собою, що насправді вони не є окремими процесами.

Якщо вони можуть , і ви бачите, що хочете в майбутньому використати різні компоненти, щоб замінити їх, тоді допомога, надана ОС, може допомогти.

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

чи варто мати окремий процес, який прослуховує з'єднання та повідомлення клієнтів і передає дані через локальні сокети або stdin в інший процес, який запускає власне ігровий сервер?

Щоб відповісти, чи варто це, вам потрібно було спершу запитати себе, яку проблему ви намагаєтеся вирішити, додавши спеціальну службу черги. Якщо вона вирішує цю проблему, тоді це варто; якщо це не вирішує проблему або якщо у вас немає проблеми, яку слід вирішити для початку, то, мабуть, це не так.

Розглянемо деякі причини, чому деякі сервери використовують багаторівневу архітектуру:

1. Балансування навантаження - балансування навантаження має сенс, якщо ви хочете поширити навантаження на декілька робочих машин. Якщо у вашій програмі є вузькі місця, які ви хочете вирішити просто шляхом декількох одночасних робочих процесів на одній машині, то найкраще в перспективі реально вирішити вузьке місце, але, як короткочасне вирішення, нерестові робочі процеси можуть бути практичними.
2. Розмежування привілеїв - можливо, ви не хочете, щоб порушення безпеки вашого сервера чату автоматично отримувало доступ до вашого ігрового сервера або навпаки. Якщо ваш ігровий сервер відокремлений від вашого ігрового сервера чату, ви можете налаштувати ваш ігровий сервер та сервер чату так, щоб він жив в окремому домені безпеки (наприклад, запускатись як інший користувач, з різними правами доступу, різними обмеженнями процесу тощо).
3. Оновлення нульового простою - якщо ви хочете домогтися нульового простою, вам потрібно мати кілька рівнів і налаштувати систему таким чином, що коли ви знімаєте сервер для обслуговування, його запити будуть перенаправлені на інші сервери в тому ж рівні, щоб забезпечити постійне сервіс.
4. Ліміт порушення - якщо ви досягнете ліміту сокета, обмеження дескриптора файлів, глобального блокування інтерпретатора тощо, можливо, ви зможете обійти цю межу, виконавши кілька процесів. Ще один спосіб вирішити це - змінити ліміт, але це не завжди просто, тому що вам може знадобитися перекомпілювати ядро, або можуть бути наслідки для безпеки або продуктивності.
5. Обмеження витоку ресурсів - ви хочете написати програмне забезпечення, яке не просочує ресурси, але навіть у повністю керованих сміттям мовах це надзвичайно важко в довготривалих процесах, і ще гірше, що це важко повторити в середовищі розробки. Багатоярусна архітектура дозволяє вбивати та відновлювати ігрові сервери через певний час або кількість запитів, щоб обмежити збитки від витоків ресурсів, не порушуючи послуги.

Я погоджуюся з храповиком виродком. Поки у вас є єдиний ігровий сервер, клопоту не варто.

Однак ця архітектура може виявитися корисною, коли потрібно масштабувати горизонтально. Коли одного ігрового сервера вже не вистачає, і вам потрібно з міркувань продуктивності розповсюджувати свою гру на декількох ігрових серверах, архітектуру "socket server" можна легко адаптувати, щоб перетворити сервер сокетів в балансир завантаження, який автоматично спрямовує з'єднання до одного з безлічі резервних служб сервер.

Але коли ви не впевнені, що вам це коли-небудь знадобиться, швидше за все, надмірна інженерія може розробити два окремі серверні програми в цей момент.

Мабуть, це не так, у більшості мов є асинхронні сокети, які дозволяють використовувати декілька з'єднань одночасно, не блокуючи, поки дані очікують. Це переміщує частину "сервера сокетів" на ОС / ядро.

З явним сервером сокет ви несете вартість декількох додаткових копій, передаваючи дані через локальний сокет; одне, що знищить масштабованість - це додаткові копії там, де вони вам не потрібні.