Configuração
Esta seção descreve quais arquivos .h e .lib você precisa incluir ao usar as APIs do Winsock.- Adicione
#include <winhttp.h>aos seus arquivos de origem. - Para títulos de PC, continue vinculando a
Winhttp.lib. - Para títulos de console XBOX, você deve vincular a
XGamePlatform.lib, em vez de vincular diretamente aWinhttp.lib.
WINAPI_PARTITION_GAMES funcionam em títulos do Microsoft Game Development Kit (GDK).
Inicialização da rede
Antes de fazer a primeira chamada para WSAStartup, os títulos do Microsoft Game Development Kit (GDK) devem garantir que a pilha de rede esteja pronta. SeWSAStartup for chamada muito cedo durante o processo de inicialização do título, WSAStartup ou as chamadas subsequentes do Winsock poderão falhar. Para obter detalhes sobre como determinar quando a pilha de rede está pronta, confira Inicialização e conectividade da rede.
Suspensão e retomada
Você deve se registrar para os eventos de suspensão e retomada por meio deRegisterAppStateChangeNotification. Na suspensão, você deve fechar todos os identificadores de soquete e chamar WSACleanup. Na retomada, você deve novamente aguardar a inicialização da rede antes de chamar WSAStartup e criar novos soquetes.
API de porta multijogador UDP (User Datagram Protocol) local preferencial do Microsoft Game Development Kit (GDK)
A API de porta multijogador UDP local preferencial do Microsoft Game Development Kit (GDK) retorna uma porta ideal, selecionada dinamicamente, à qual os títulos devem se associar usando o Winsock para facilitar a comunicação no jogo via UDP. A plataforma do Microsoft Game Development Kit (GDK) garante que essa porta específica seja a que tem maior probabilidade de funcionar no ambiente de rede específico de cada usuário. Usar essa porta específica maximiza o uso dos fluxos de suporte ao cliente e de diagnóstico da plataforma, aumenta a compatibilidade padronizada com a NAT (conversão de endereços de rede), fornece funcionalidade padronizada de dispositivos certificados por UPnP™ e identifica os pacotes como sensíveis a tempo real para algoritmos de QoS (qualidade de serviço) de roteadores e ISPs. A porta UDP é particularmente relevante para títulos que dependem de topologias de rede ponto a ponto. É a única porta que permite pacotes UDP de entrada pelo firewall sem realizar a perfuração do firewall. Os títulos que dependem de topologias de rede ponto a ponto no Microsoft Game Development Kit (GDK) ainda devem fornecer sua própria descoberta de endereço IP público e porta, juntamente com uma solução de perfuração de NAT para clientes com tipos de NAT moderados ou estritos. A porta preferencial por si só melhora a taxa de sucesso dessas tecnologias, mas não as substitui. Os títulos que usam topologias de rede cliente/servidor também se beneficiam do uso da porta UDP. A solução de problemas, o UPnP™ e a identificação de pacotes ainda são relevantes para portais cativos e outras abordagens de filtragem baseadas na origem, comuns em hospitais, hotéis e alojamentos universitários. É altamente recomendável que os títulos do Microsoft Game Development Kit (GDK) usem a porta multijogador UDP local preferencial para seu principal tráfego de rede de multijogador e chat.Segurança dos soquetes
Os títulos do Microsoft Game Development Kit (GDK) são responsáveis por garantir que haja segurança e criptografia adequadas para todos os dados transferidos pela rede com a API do Winsock. BCrypt, WinCrypt, schannel e outras APIs padrão do Windows fornecem as primitivas criptográficas recomendadas. Os títulos do Microsoft Game Development Kit (GDK) devem usar essas APIs para implementar o DTLS (Datagram Transport Layer Security) e outros protocolos de segurança padronizados para todos os fluxos de soquete. Para títulos que não desejam implementar seu próprio modelo de segurança, a biblioteca do Microsoft Game Development Kit (GDK) PlayFab Party fornece uma solução completa e integrada de segurança de soquetes, entre outros recursos.Considerações sobre memória de soquetes
Os títulos do Microsoft Game Development Kit (GDK) têm atualmente apenas cerca de 16 MB disponíveis para a pilha de rede para todo o uso de WinSock e WinHTTP; a partir desse ponto, o sistema pode se tornar instável. Uma das maiores fontes de consumo de memória está nos pools de memória de envio e recebimento do modo kernel do WinSock, onde os pacotes de entrada e saída são armazenados até que possam ser enviados pela conexão ou transferidos para a memória de modo de usuário do seu título por meio de uma das muitas variantes derecv.
Particularmente em situações de alta largura de banda, cabe ao seu título transferir os dados para seus próprios buffers de modo de usuário com baixa latência, a uma taxa pelo menos igual à que o par remoto ou servidor está enviando. Há algumas maneiras de fazer isso, com complexidade e garantias crescentes, mas o objetivo subjacente de todas as sugestões abaixo é sempre ter um buffer de modo de usuário pendente para transferência imediata assim que os dados chegarem, para que o kernel não precise alocar uma quantidade crescente de memória. O efeito líquido é transferir o uso de memória para dados pendentes não processados do pool extremamente limitado do kernel para a memória gerenciada diretamente por você, dentro do pool de memória muito maior do seu título.
APIs de nível mais alto que consomem o WinSock geralmente têm mecanismos para controlar o uso de memória do kernel de seus soquetes. O WinHTTP e o XCurl permitem controlar o uso de memória do kernel por meio de seus respectivos mecanismos de notificação de leitura, enquanto outras APIs, como XSAPI e PlayFab Party, minimizam o uso de memória do kernel com as técnicas abaixo.
Soquetes Berkley (BSD)
Se você quiser continuar usando as APIs de soquete Berkley bloqueantes, precisará aumentar a frequência das chamadas recv. Recomendamos usar um thread dedicado com um loop apertado que enfileire os dados recebidos para processamento em outro lugar. Idealmente, o thread estaria sempre bloqueado dentro de uma chamada recv; qualquer tempo gasto fora da chamada recv será potencialmente um tempo em que o uso de memória do kernel crescerá enquanto ele aguarda que você chame recv novamente. Muitas vezes, se você tentar processar os dados antes de chamar recv novamente, seu título poderá ficar para trás e o uso de memória do kernel crescerá enquanto os dados continuarem sendo recebidos a taxas altas. Também recomendamos especificar tamanhos de buffer de pelo menos 8k para se alinhar aos limites de tamanho de buffer do kernel e ajudar com jitter e padrões de envio em rajadas.E/S sobreposta do WinSock
A E/S sobreposta do WinSock permite que você mantenha de forma assíncrona um buffer de recebimento de modo de usuário pendente. Ela também permite que o kernel use diretamente seu buffer de memória e evite uma cópia de memória extra (ao contrário do paradigma de soquetes Berkley) e, supondo que haja sempre um buffer pendente, o kernel não fará nenhuma alocação para os dados recebidos. Além disso, com a E/S sobreposta, você pode definir SO_RCVBUF e SO_SNDBUF com o valor especial 0, o que evitará quase totalmente a alocação de memória de kernel para envio/recebimento. Essa abordagem é a melhor maneira de gerenciar a memória usada pelos seus soquetes em quase todos os cenários.E/S registrada
A E/S registrada é uma API de rede complexa que oferece a menor latência e garante que nenhuma memória de kernel seja usada para operações de envio e recebimento. Ela permite configurar vários buffers de recebimento/envio usados diretamente pelo kernel para garantir que você sempre tenha buffers prontos para os dados de entrada.Tamanho máximo da unidade de transmissão UDP
Embora exista um tamanho máximo teórico de payload no Microsoft Game Development Kit (GDK), na prática, o máximo para uma determinada conexão depende do tipo de conexão de rede. Ele pode variar enquanto um título está em execução. Em vez de tentar determinar a MTU (unidade máxima de transmissão) real e reagir a alterações na MTU enquanto o título está em execução, você deve projetar seu código de rede para assumir um payload UDP máximo por pacote de 1.384 bytes. Esse valor é seguro para uso em todas as configurações de rede para evitar a fragmentação durante a transmissão. Recomendamos isso independentemente de o tipo de soquete ser IPv4 ou IPv6. A transmissão de payloads maiores que 1.384 bytes geralmente requer a fragmentação de pacotes no nível de IP. A fragmentação de pacotes IP não é bem suportada por ISPs e por roteadores e dispositivos domésticos dos usuários. Nessas configurações de rede, a fragmentação de pacotes IP não causa falhas na API do Winsock. Em vez disso, a fragmentação aparece como perda de pacotes para o seu título. Para evitar a fragmentação de pacotes no nível de IP, use 1.384 bytes como máximo seguro para o payload dos seus pacotes. Para garantir que seu título evite a fragmentação e ajudar seu título a atender aos Requisitos do XBOX associados aos requisitos mínimos de rede multijogador, você deve aplicar as opções de soqueteIP_DONTFRAGMENT e IP_USER_MTU a todos os soquetes que seu título abrir. Esses sinalizadores só estão disponíveis para títulos do Microsoft Game Development Kit (GDK) quando a API XGameRuntimeIsFeatureAvailable(XGameRuntimeFeature::XNetworking) retorna true. Se o recurso XNetworking não estiver disponível, a chamada setsockopt falhará. Veja a seguir um exemplo de como definir essas duas opções de soquete.