질문
방금 Lidgren 및 네트워킹 작업을 시작했으며 동일한 프로세스 내에서 서버와 클라이언트를 모두 실행할 수 있다는 것을 깨달았습니다 .
어떤 이유로 든이 관행을 권장하지 않습니까?
문맥
내가 묻는 이유는이 개념으로 싱글 플레이어와 멀티 플레이어 모드를 모두 동일하게 취급 할 수 있다고 이론화했기 때문에 매우 도움이 될 것입니다.
내 생각에 따라, 이것은 내가 생각한 분포입니다.
내가 그림으로 보여주는 실행 흐름은 클라이언트가 사용자 입력을 받고 서버에 알림을 보내는 것입니다. 그런 다음 서버는이를 검증하고 모든 클라이언트가 실행할 조치를 브로드 캐스트합니다. 하나의 클라이언트 (예 : 싱글 플레이어) 또는 여러 클라이언트 (예 : 멀티 플레이어) 만 있는지는 중요하지 않습니다.
답변:
이것은 기본적으로 프로세스 대 스레드 질문이며 둘 다 다르지 않으며 때로는 스레드를 경량 프로세스라고합니다. 가장 큰 차이점은 별도의 프로세스에 자체 주소 공간이 있지만 다른 차이점이 있다는 것입니다 (1).
프로세스 당
스레드 당
이러한 차이점에 따라 파일 핸들과 전역 변수를 공유 할 수 있도록 서버와 클라이언트 스레드를 동일한 프로세스에 두는 것이 편리 할 수 있습니다. 이것은 '동일한 프로세스에서'접근 방식에 대한 논쟁이 될 것이며, 또 다른 (작은) 논쟁은 프로세스 당 하나의 'Windows 방화벽'팝업 만 얻는다는 것입니다. '다른 프로세스'접근 방식에 대한 논쟁은 개인이 여러 클라이언트를 실행할 필요없이 여러 서버를 실행할 수 있다는 것입니다. 이는 셋업과 같은 전용 호스트에 이상적이며 1 인칭 슈팅 게임에서 흔히 볼 수있는 접근 방식입니다.
이제 오프라인 플레이 (또는 싱글 플레이어의 경우에도)를 위해 서버 프로세스 또는 스레드를 갖는 아이디어는 실제로 많이 사용되는 좋은 아이디어입니다. 로딩 화면을 보면 많은 게임에이를 알 수 있습니다. '수신'과 같은 작은 힌트가 그것을 줄 것입니다. 멀티 플레이어를 만들려는 경우 대부분의 게임 규칙이 서버에 의해 관리되므로 싱글 플레이어에 대해 규칙을 적용하지 않는 이유는 무엇입니까? 이렇게하면 작성해야하는 코드가 줄어들고 클라이언트와 '게임'이 명확하게 분리되어 코드 품질이 향상됩니다.
이제 프로세스와 스레드 간 통신은 어떻습니까? 프로세스 간 통신은 파이프, 공유 메모리, COM 등 다양한 방법으로 수행 할 수 있으며 실제로 사용중인 기술에 따라 다릅니다. 그러나 서버를 만드는 경우 소켓과 TCP와 같은 것을 사용하는 네트워킹 변형을 사용하고 싶을 것입니다 .LIDGREN이 유용 할 것입니다.
이러한 많은 기술은 스레드 간 통신에도 유효합니다. 그러나 이것은 사용중인 기술에 훨씬 달려 있습니다. TCP로 다시 갈 수는 있지만 더 간단한 시스템은 이벤트와 마샬링 일 수 있지만 게임 루프를 결정적이지 않게 만들 수 있습니다 (2).
출처