소켓 서버와 게임 서버는 별도의 프로세스 여야합니까?

간단한 표준 클라이언트 / 서버 게임을 가정하십시오. 서버의 경우 클라이언트로부터의 연결과 메시지를 수신하고 로컬 소켓 또는 stdin을 통해 실제 게임 서버를 실행하는 다른 프로세스로 데이터를 보내는 별도의 프로세스를 보유하는 것이 가치가 있습니까?

다른 옵션은 단일 프로세스에서 두 가지 작업을 모두 수행하는 것입니다. 들어오는 메시지를 큐에 넣고 올바른 순서로 실행하면 중단 문제가 없어야합니다.

두 "활동"을 분리하기위한 추가 자원이 실제로 가치가 있는지 궁금합니다. 어떻게 결정해야합니까? 찬반 양론을 듣고 싶습니다.

API 설계 관점에서 여러 개의 개별 통신 프로그램을 만들 것인지 아니면 하나만 만들 것인지를 결정할 때 문제는 다음과 같습니다. 각 프로그램이 다른 프로그램없이 의미있게 작동 할 수 있습니까? 답변은 프로젝트 및 환경 설정에 따라 다릅니다.

그들이 할 수 없다면 , 생각할 가치가 없습니다. 분명히 그들은 너무 분리되어있어 실제로 별도의 프로세스가 아닙니다.

그들이 할 수 있고 앞으로 다른 구성 요소를 교체하기 위해 다른 구성 요소를 떨어 뜨리기를 원한다면 OS 제공 프로세스 추상화가 도움이 될 수 있습니다.

얼마나 많은 이 도움이 것은 비록 당신의 기술 스택의 나머지에 따라 달라집니다. 예를 들어 Erlang은 내부적으로 프로세스를 이미 프로세스로 모델링하므로 OS 프로세스로 분할해도 개념적 이점을 얻지 못합니다. 서버의 해당 부분을 다른 언어로 다시 작성하려고 생각하지 않는 한. C ++ 프로그램의 내부 구성 요소는 일반적으로 훨씬 더 밀접하게 결합되어 스왑 아웃하기가 더 어려워 다른 OS 프로세스로 분할하면 나중에 재배치를 예측할 수 있다면 나중에 작업을 절약 할 수 있습니다.

클라이언트로부터의 연결 및 메시지를 수신하고 로컬 소켓 또는 stdin을 통해 실제 게임 서버를 실행하는 다른 프로세스로 데이터를 보내는 별도의 프로세스를 갖는 것이 가치가 있습니까?

가치가 있는지 여부를 확인하려면 먼저 전용 큐 서비스를 추가하여 해결하려는 문제가 무엇인지 스스로에게 물어야합니다. 그것이 그 문제를 해결한다면 그만한 가치가 있습니다. 문제가 해결되지 않거나 처음부터 해결해야 할 문제가 없다면 아마도 아닐 것입니다.

일부 서버가 다중 계층 아키텍처를 사용하는 몇 가지 이유를 살펴 보겠습니다.

1. 로드 밸런싱-워크로드를 여러 작업자 시스템으로 분산하려는 경우로드 밸런싱이 적합합니다. 프로그램에 동일한 머신에서 여러 동시 작업자 프로세스를 사용하여 간단히 해결하려는 병목 현상이있는 경우 실제로 병목 현상을 해결하는 것이 가장 좋지만 단기적인 해결 방법으로 작업자 프로세스를 생성하는 것이 실용적 일 수 있습니다.
2. 권한 분리-채팅 서버에 대한 보안 침해가 자동으로 게임 서버에 액세스하거나 그 반대로 액세스하는 것을 원하지 않을 수 있습니다. 게임 서버가 게임 내 채팅 서버와 분리 된 경우 게임 서버와 채팅 서버를 별도의 보안 도메인에 살도록 구성 할 수 있습니다 (예 : 액세스 권한, 프로세스 제한 등이 다른 다른 사용자로 실행).
3. 다운 타임 제로 업그레이드-다운 타임 제로 업그레이드를 달성하려면 서비스를 위해 서버를 중단 할 때 요청이 동일한 계층의 다른 서버로 리디렉션되어 연속성을 유지하도록 시스템을 여러 계층으로 구성하고 시스템을 구성해야합니다. 서비스.
4. 제한 한계-소켓 한계, 파일 디스크립터 한계, 글로벌 인터프리터 잠금 등에 도달하면 여러 프로세스를 실행하여 해당 한계를 해결할 수 있습니다. 이 문제를 해결하는 또 다른 방법은 한계를 변경하는 것이지만 커널을 다시 컴파일해야하거나 보안 또는 성능에 영향을 줄 수 있으므로 항상 쉬운 것은 아닙니다.
5. 리소스 누수 제한-리소스를 누수하지 않는 소프트웨어를 작성하려고하지만 완전히 가비지 관리되는 언어에서도 장기적인 프로세스에서는 매우 어렵고 개발 환경에서는 복제하기가 어렵습니다. 멀티 티어 아키텍처를 사용하면 서비스 중단없이 리소스 유출로 인한 피해를 제한하기 위해 일정 시간 또는 횟수의 요청 후에 게임 서버를 종료하고 다시 생성 할 수 있습니다.

나는 래칫 괴물에 동의합니다. 게임 서버가 하나만 있으면 문제가되지 않습니다.

그러나이 아키텍처는 수평으로 확장해야 할 때 유용 할 수 있습니다. 하나의 게임 서버가 더 이상 충분하지 않고 성능상의 이유로 여러 게임 서버에 게임을 배포해야하는 경우, "소켓 서버"아키텍처는 소켓 서버를로드 밸런서로 전환하여 연결을 여러 백엔드 중 하나로 자동 라우팅하도록 매우 쉽게 조정할 수 있습니다. 섬기는 사람.

그러나 이것이 꼭 필요할지 확신 할 수 없을 때는이 시점에서 두 개의 개별 서버 응용 프로그램을 개발하는 것이 너무 많은 엔지니어링 일 것입니다.

아마도 대부분의 언어에는 비동기 소켓이있어 데이터가 기다리는 동안 차단하지 않고 한 번에 여러 연결을 사용할 수 있습니다. "소켓 서버"부분을 OS / 커널로 이동합니다.

명시 적 소켓 서버를 사용하면 로컬 소켓을 통해 데이터를 전달할 때 약간의 추가 사본 비용이 발생합니다. 확장 성을 없애는 한 가지 방법은 필요하지 않은 추가 복사본입니다.