Skip to main content
Microsoft Game Development Kit (GDK)은 Windows Sockets 2 (Winsock) API의 사용을 지원합니다. Windows Sockets 2 (Winsock)을 사용하면 사용 중인 네트워크 프로토콜과 관계없이 애플리케이션 데이터를 유선으로 전송하는 고급 인터넷, 인트라넷 및 기타 네트워크 지원 애플리케이션을 만들 수 있습니다. Microsoft Game Development Kit (GDK) 타이틀이 Winsock과 상호 작용하는 방식은 일반적으로 Win32 프로그램이 Winsock과 상호 작용하는 방식과 동일합니다. 이 항목에서는 Microsoft Game Development Kit (GDK) 타이틀의 Winsock 사용에 특정한 사소한 차이점 및 모범 사례를 설명합니다.

설정

이 섹션에서는 Winsock API를 사용할 때 포함해야 하는 .h 및 .lib 파일을 설명합니다.
  • 소스 파일에 #include <winhttp.h>를 추가합니다.
  • PC 타이틀의 경우 계속해서 Winhttp.lib에 대해 링크합니다.
  • XBOX 콘솔 타이틀의 경우 Winhttp.lib에 직접 링크하는 대신 XGamePlatform.lib에 대해 링크해야 합니다.
Microsoft Game Development Kit (GDK) 타이틀에서는 WINAPI_PARTITION_GAMES API 계열 아래의 API만 작동합니다.

네트워크 초기화

WSAStartup에 대한 첫 번째 호출을 하기 전에 Microsoft Game Development Kit (GDK) 타이틀은 네트워킹 스택이 준비되었는지 확인해야 합니다. 타이틀의 시작 프로세스 중 너무 이른 시점에 WSAStartup이 호출되면 WSAStartup 또는 후속 Winsock 호출이 실패할 수 있습니다. 네트워킹 스택이 준비된 시점을 확인하는 방법에 대한 자세한 내용은 네트워크 초기화 및 연결을 참조하세요.

일시 중지 및 재개

RegisterAppStateChangeNotification을 통해 일시 중지 및 재개 이벤트에 등록해야 합니다. 일시 중지 시에는 모든 소켓 핸들을 닫고 WSACleanup을 호출해야 합니다. 재개 시에는 WSAStartup을 호출하고 새 소켓을 만들기 전에 네트워크 초기화를 다시 기다려야 합니다.

Microsoft Game Development Kit (GDK) 선호 로컬 UDP(User Datagram Protocol) 멀티플레이어 포트 API

Microsoft Game Development Kit (GDK) 선호 로컬 UDP 멀티플레이어 포트 API는 UDP를 통한 게임 내 통신을 촉진하기 위해 타이틀이 Winsock을 사용하여 바인딩해야 하는 최적의 동적으로 선택된 포트를 반환합니다. Microsoft Game Development Kit (GDK) 플랫폼은 이 특정 포트가 각 사용자의 특정 네트워킹 환경에서 작동할 가능성이 가장 높은 포트임을 보장합니다. 이 특정 포트를 사용하면 플랫폼의 고객 지원 및 진단 흐름의 사용을 극대화하고, 표준화된 NAT(network address translation) 호환성을 높이며, 표준화된 UPnP™ 인증 장치 기능을 제공하고, QoS(Quality of Service) 라우터 및 ISP 알고리즘에 대해 실시간 민감성 패킷으로 식별합니다. UDP 포트는 피어 투 피어 네트워크 토폴로지에 의존하는 타이틀에 특히 관련이 있습니다. 방화벽 뚫기를 수행하지 않고도 방화벽을 통해 인바운드 UDP 패킷을 허용하는 유일한 포트입니다. Microsoft Game Development Kit (GDK)에서 피어 투 피어 네트워크 토폴로지에 의존하는 타이틀은 여전히 자체 공개 IP 주소 및 포트 검색과 함께 보통 또는 엄격한 NAT 유형을 가진 클라이언트를 위한 NAT 뚫기 솔루션을 제공해야 합니다. 선호 포트 자체는 이러한 기술의 성공률을 개선하지만 이를 대체하지는 않습니다. 클라이언트/서버 네트워크 토폴로지를 사용하는 타이틀도 UDP 포트를 사용함으로써 이점을 얻습니다. 문제 해결, UPnP™ 및 패킷 식별은 병원, 호텔 및 대학 기숙사에서 흔한 캡티브 포털 및 기타 소스 기반 필터링 접근 방식에 여전히 관련이 있습니다. Microsoft Game Development Kit (GDK) 타이틀은 주요 멀티플레이어 및 채팅 네트워크 트래픽에 선호 로컬 UDP 멀티플레이어 포트를 사용하는 것이 강력히 권장됩니다.

소켓 보안

Microsoft Game Development Kit (GDK) 타이틀은 Winsock API를 사용하여 네트워크를 통해 전송되는 모든 데이터에 대해 적절한 보안 및 암호화를 보장할 책임이 있습니다. BCrypt, WinCrypt, schannel 및 기타 표준 Windows API는 권장되는 암호화 기본 요소를 제공합니다. Microsoft Game Development Kit (GDK) 타이틀은 이러한 API를 사용하여 모든 소켓 흐름에 대해 DTLS(Datagram Transport Layer Security) 및 기타 표준화된 보안 프로토콜을 구현해야 합니다. 자체 보안 모델을 구현하고 싶지 않은 타이틀의 경우, Microsoft Game Development Kit (GDK) 라이브러리 PlayFab Party는 다른 기능과 함께 완전하고 통합된 소켓 보안 방안을 제공합니다.

소켓 메모리 고려 사항

Microsoft Game Development Kit (GDK) 타이틀은 현재 모든 WinSock 및 WinHTTP 사용에 대해 네트워크 스택에서 약 16MB만 사용 가능하며, 그 이후에는 시스템이 불안정해질 수 있습니다. 메모리 소비의 가장 큰 원인 중 하나는 WinSock 커널 모드 송수신 메모리 풀로, 여기서 들어오고 나가는 패킷은 유선으로 전송되거나 여러 recv 변형 중 하나를 통해 타이틀의 사용자 모드 메모리로 전송될 때까지 저장됩니다. 특히 높은 대역폭 상황에서는 원격 피어 또는 서버가 밀어넣는 속도와 최소한 같은 속도로 낮은 지연 시간으로 자체 사용자 모드 버퍼로 데이터를 전송하는 것이 타이틀의 책임입니다. 이를 수행하는 몇 가지 방법이 있으며 복잡성과 보장이 점점 증가하지만, 아래 제안 사항의 근본적인 목표는 커널이 점점 더 많은 메모리를 할당할 필요가 없도록 데이터가 도착하자마자 즉시 전송할 수 있는 사용자 모드 버퍼가 항상 대기 중이도록 하는 것입니다. 결과적으로 처리되지 않은 대기 중 데이터에 대한 메모리 사용을 극도로 제한된 커널 풀에서 훨씬 더 큰 타이틀 메모리 풀 내에서 직접 관리하는 메모리로 변경합니다. WinSock을 사용하는 상위 수준 API에는 일반적으로 소켓의 커널 메모리 사용을 제어하는 메커니즘이 있습니다. WinHTTPXCurl 모두 각각의 읽기 알림 메커니즘을 통해 커널 메모리 사용을 제어할 수 있으며, XSAPIPlayFab Party와 같은 다른 API는 아래 기술을 사용하여 커널 메모리 사용을 최소화합니다.

Berkley (BSD) 소켓

블로킹 Berkley 소켓 API를 계속 사용하려면 recv 호출 빈도를 늘려야 합니다. 다른 곳에서 처리하기 위해 수신된 데이터를 큐잉하는 타이트 루프가 있는 전용 스레드를 사용하는 것이 좋습니다. 이상적으로는 스레드가 항상 recv 호출 내부에서 블로킹되어야 합니다. recv 호출 외부에서 보내는 모든 시간은 잠재적으로 커널 메모리 사용이 증가하는 시간이 될 것입니다. recv를 다시 호출하기 전에 데이터를 처리하려고 하면 타이틀이 뒤처지고 데이터가 계속 높은 속도로 수신되는 한 커널 메모리 사용이 증가하는 경우가 많습니다. 또한 커널 버퍼 크기 경계에 맞추고 지터 및 버스트성 송신 패턴을 처리하는 데 도움이 되도록 최소 8k 이상의 버퍼 크기를 지정하는 것이 좋습니다.

WinSock Overlapped I/O

WinSock의 overlapped I/O를 사용하면 사용자 모드 수신 버퍼를 비동기적으로 대기 상태로 유지할 수 있습니다. 또한 커널이 메모리 버퍼를 직접 사용하고 추가 메모리 복사를 피할 수 있게 해주며(Berkley 소켓 패러다임과 달리), 버퍼가 항상 대기 중이라고 가정할 때 수신된 데이터에 대해 커널이 전혀 할당하지 않습니다. 또한 overlapped I/O를 사용하면 SO_RCVBUF 및 SO_SNDBUF를 특별한 값 0으로 설정할 수 있으며, 이는 대부분 송수신 커널 메모리가 전혀 할당되지 않도록 합니다. 이 접근 방식은 거의 모든 시나리오에서 소켓이 사용하는 메모리를 관리하는 가장 좋은 방법입니다.

Registered I/O

Registered I/O는 최저 지연 시간을 제공하고 송수신 작업에 사용되는 커널 메모리가 없음을 보장하는 복잡한 네트워킹 API입니다. 커널이 직접 사용하는 여러 개의 수신/송신 버퍼를 설정하여 들어오는 데이터를 위한 버퍼가 항상 준비되어 있도록 할 수 있습니다.

최대 UDP 전송 단위 크기

Microsoft Game Development Kit (GDK)에는 이론적인 최대 페이로드 크기가 존재하지만, 실제로는 특정 연결에 대한 최대값은 네트워크 연결 유형에 따라 달라집니다. 타이틀이 실행되는 동안 달라질 수 있습니다. 실제 MTU(Maximum Transmission Unit)를 결정하고 타이틀이 실행되는 동안 MTU의 변경에 대응하려고 시도하는 대신, 패킷당 최대 UDP 페이로드가 1,384바이트라고 가정하도록 네트워킹 코드를 설계해야 합니다. 이 값은 전송 중 조각화를 피하기 위해 모든 네트워킹 구성에서 안전하게 사용할 수 있습니다. 소켓 유형이 IPv4이든 IPv6이든 이를 권장합니다. 1,384바이트보다 큰 페이로드를 전송하려면 종종 IP 수준 패킷 조각화가 필요합니다. IP 패킷 조각화는 ISP와 사용자의 홈 라우터 및 디바이스에서 잘 지원되지 않습니다. 이러한 네트워크 구성에서는 IP 패킷 조각화가 Winsock API에서 실패를 일으키지 않습니다. 대신 조각화는 타이틀에서 패킷 손실로 나타납니다. IP 수준 패킷 조각화를 피하기 위해 패킷 페이로드의 안전한 최대값으로 1,384바이트를 사용하세요. 타이틀이 조각화를 피하고 최소 멀티플레이어 네트워크 요구 사항에 대한 관련 XBOX 요구 사항을 충족하는 것을 지원하려면, 타이틀에서 여는 모든 소켓에 소켓 옵션 IP_DONTFRAGMENTIP_USER_MTU를 적용해야 합니다. 이러한 플래그는 XGameRuntimeIsFeatureAvailable(XGameRuntimeFeature::XNetworking) API가 true를 반환할 때만 Microsoft Game Development Kit (GDK) 타이틀에서 사용할 수 있습니다. XNetworking 기능을 사용할 수 없는 경우 setsockopt 호출이 실패합니다. 다음은 이 두 소켓 옵션을 설정하는 방법의 예제입니다.

참고 항목

마지막 수정일 2026년 8월 24일