대기 시간을 최소화하기 위해 IIS를 사용하여 HTTP를 통해 멀티 플레이어 게임 데이터를 터널링하는 방법은 무엇입니까?

Question

브라우저 기반 네트워크 게임을 만들고 싶습니다. 최대한 많은 사람들이 사용할 수 있도록 표준 HTTP 패키지에 모든 트래픽을 포함시키고 싶습니다.

백 엔드로 IIS를 사용한다고 가정 할 때 대기 시간을 최소화하려면 어떻게 코딩해야합니까?

메모리의 공유 상태를 사용하여 일종의 ASP 응용 프로그램 (ASP.NET MVC)을 시작하는 것이 합리적입니까? 아니면 내 자신의 IIS 플러그인의 일종을 쓰기 시작부터 계획해야합니까? 아니면 IIS를 포기하고 대신 사용자 지정 서버를 작성해야합니까?

각 클라이언트가 반복적으로 쿼리하는 것으로 시작하는 것이 합리적입니까, 예를 들어 초당 10 회라고 말합니까? 아니면 어떻게 든 데이터를 더 많은 스트림과 같이 만들어야합니까?

Answer 1

정상적으로 작동 할 수 있지만 "기존의"것보다 적은 것을해야합니다.

이 작업을 수행하려면 개별 요청을 수행하지 말고 요청을 열린 상태로 유지 한 다음 열린 연결로 데이터를 전송하십시오.

Bayeux과 같은 프로토콜을 사용해 볼 수도 있지만 여기에는 규칙이 없습니다.

Here's an example with ASP.NET using COMET.

Answer 2

초당 웹 서버를 10 번 누르는 앱을 디자인하는 것은 좋은 생각이 아닙니다. 웹 서버는 클라이언트 요청 빈도가 적기 때문에 처리 시간과 응답 크기가 커질 수 있습니다. 그렇다고해서 웹 서버가 효율적인 클라이언트 - 서버 매치가 아닐 수도 있다는 것을 의미하지는 않습니다.

초당 여러 패킷을 필요로하는 모든 유형의 앱의 경우 HTTP보다 훨씬 가벼운 프로토콜을 생각해 봐야합니다. 이는 매우 장황합니다. 예를 들어 게임이 사용자 전함 좌표를 등록하기 위해 4 바이트를 전송해야하는 경우 추가로 수백 바이트의 HTTP 헤더를 전송하고 싶지는 않습니다.

플래시의 Siverlight와 같은 브라우저 플러그인 기술을 권하고 싶습니다. 둘 다 TCP 소켓 연결을 지원합니다. TCP 소켓의 다른 끝에 앉아서 자신의 서버를 작성해야합니다. 이 방법을 사용하면 HTTP와 같이 필요한 클라이언트 폴링 메커니즘에 의존하지 않고도 클라이언트에 데이터를 전달할 수 있다는 장점이 있습니다. AJAX.

Answer 3

표준 HTTP 메시지에서 직면하게 될 문제 중 하나는 헤더 데이터에 대한 크기 (제어력 부족)입니다.

저는 수백만 명이 플레이하는 플래시 게임의 디자인에 관여했습니다. 우리는 몇 초마다 서버와 통신 할 필요가 있었고 초경량 JSON 메시지를 사용하여 대역폭을 절약하고 계속 원활하게 유지했습니다. JSON 메시지의

크기 : 16 바이트 HTTP 헤더의

크기 :

HTTP 정말 높은 트래픽, 낮은 지연 시간 요구 사항에 대한 좋은 프로토콜 아닌 200 바이트. 이 요청은 크기가 크고 빈도가 적은 요청/응답 모델 용으로 설계되었으며 상태 코드는 304 Not Modified입니다.

사용자 지정 TCP/IP 구현으로 드롭 다운 할 수 있습니다.