> ## Documentation Index > Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt > Use this file to discover all available pages before exploring further. # Introducción a Windows Sockets en el GDK > Introducción a los sockets de Windows en el Microsoft Game Development Kit El Microsoft Game Development Kit (GDK) admite el uso de la API [Windows Sockets 2 (Winsock)](https://learn.microsoft.com/windows/desktop/WinSock/windows-sockets-start-page-2). Windows Sockets 2 (Winsock) te permite crear aplicaciones avanzadas de Internet, intranet y otras aplicaciones con capacidades de red para transmitir datos de aplicación a través de la red, independientemente del protocolo de red que se use. La forma en que los títulos de Microsoft Game Development Kit (GDK) interactúan con Winsock es, en general, la misma que la forma en que los programas Win32 interactúan con Winsock. Este tema describe las pequeñas diferencias y los procedimientos recomendados específicos del uso de Winsock en los títulos de Microsoft Game Development Kit (GDK). ## Configuración Esta sección describe qué archivos .h y .lib debes incluir al usar las API de Winsock. * Agrega `#include ` en tus archivos de código fuente. * Para los títulos de PC, continúa vinculando con `Winhttp.lib`. * Para los títulos de consola XBOX, debes vincular con `XGamePlatform.lib`, en lugar de hacerlo directamente con `Winhttp.lib`. Solo las API de la familia de API `WINAPI_PARTITION_GAMES` funcionan en los títulos de Microsoft Game Development Kit (GDK). ## Inicialización de la red Antes de realizar la primera llamada a [WSAStartup](https://learn.microsoft.com/windows/desktop/api/winsock/nf-winsock-wsastartup), los títulos de Microsoft Game Development Kit (GDK) deben asegurarse de que la pila de red está lista. Si se llama a `WSAStartup` demasiado pronto durante el proceso de inicio del título, `WSAStartup` o las llamadas posteriores de Winsock podrían producir errores. Para obtener más información sobre cómo determinar cuándo está lista la pila de red, consulta [Inicialización y conectividad de la red](/build/console-features/networking/initialization-connectivity-networking). ## Suspensión y reanudación Debes registrarte para los eventos de suspensión y reanudación mediante `RegisterAppStateChangeNotification`. En la suspensión, debes cerrar todos los identificadores de socket y llamar a [WSACleanup](https://learn.microsoft.com/windows/desktop/api/winsock/nf-winsock-wsacleanup). En la reanudación, debes esperar de nuevo a la [inicialización de la red](/build/console-features/networking/initialization-connectivity-networking) antes de llamar a [WSAStartup](https://learn.microsoft.com/windows/desktop/api/winsock/nf-winsock-wsastartup) y crear nuevos sockets. ## API del puerto multijugador local preferido de User Datagram Protocol (UDP) del Microsoft Game Development Kit (GDK) La API del [puerto multijugador UDP local preferido](/build/console-features/networking/game-mesh/preferred-local-udp-multiplayer-port-networking) del Microsoft Game Development Kit (GDK) devuelve un puerto óptimo, seleccionado dinámicamente, al que los títulos deben [enlazarse](https://learn.microsoft.com/windows/desktop/api/winsock/nf-winsock-bind) mediante Winsock para facilitar la comunicación dentro del juego mediante UDP. La plataforma de Microsoft Game Development Kit (GDK) garantiza que este puerto específico sea el que tenga más probabilidades de funcionar en el entorno de red particular de cada usuario. El uso de este puerto específico maximiza el uso de los flujos de soporte técnico al cliente y de diagnóstico de la plataforma, aumenta la compatibilidad estandarizada con la traducción de direcciones de red (NAT), proporciona una funcionalidad estandarizada de dispositivos con certificación UPnP™ e identifica los paquetes como sensibles al tiempo real para los algoritmos de calidad de servicio (QoS) de enrutadores e ISP. El puerto UDP es especialmente relevante para los títulos que dependen de topologías de red de punto a punto. Es el único puerto que permite paquetes UDP entrantes a través del firewall sin realizar perforación de firewall. Aun así, se espera que los títulos que dependen de topologías de red de punto a punto en el Microsoft Game Development Kit (GDK) proporcionen su propio mecanismo de detección de dirección IP pública y puerto, junto con una solución de perforación de NAT para los clientes que tengan tipos de NAT moderados o estrictos. El puerto preferido por sí solo mejora la tasa de éxito de estas tecnologías, pero no las sustituye. Los títulos que usan topologías de red cliente/servidor también se benefician del uso del puerto UDP. La solución de problemas, UPnP™ y la identificación de paquetes siguen siendo relevantes para portales cautivos y otros enfoques de filtrado basados en el origen habituales en hospitales, hoteles y residencias universitarias. Recomendamos encarecidamente que los títulos de Microsoft Game Development Kit (GDK) usen el puerto multijugador UDP local preferido para su tráfico de red principal de multijugador y chat. ## Seguridad de los sockets Los títulos de Microsoft Game Development Kit (GDK) son responsables de garantizar que exista la seguridad y el cifrado adecuados para todos los datos que se transfieren a través de la red con la API de Winsock. [BCrypt](https://learn.microsoft.com/windows/desktop/api/bcrypt/index), [WinCrypt](https://learn.microsoft.com/windows/desktop/api/wincrypt/index), [schannel](https://learn.microsoft.com/windows/desktop/api/schannel/index) y otras API estándar de Windows proporcionan las primitivas criptográficas recomendadas. Los títulos de Microsoft Game Development Kit (GDK) deben usar estas API para implementar Datagram Transport Layer Security (DTLS) y otros protocolos de seguridad estandarizados para todos los flujos de socket. Para los títulos que no quieran implementar su propio modelo de seguridad, la biblioteca [PlayFab Party](/build/console-features/networking/game-mesh/playfab-party-intro-networking) del Microsoft Game Development Kit (GDK) proporciona una solución de seguridad de sockets completa e integrada, entre otras características. ## Consideraciones sobre la memoria de los sockets Los títulos de Microsoft Game Development Kit (GDK) solo tienen actualmente unos 16 MB disponibles para la pila de red para todo el uso de WinSock y WinHTTP, punto a partir del cual el sistema puede volverse inestable. Una de las mayores fuentes de consumo de memoria son los grupos de memoria de envío y recepción en modo kernel de WinSock, donde los paquetes entrantes y salientes se almacenan hasta que pueden enviarse por la red o transferirse a la memoria en modo usuario de tu título mediante una de las muchas variantes de `recv`. En particular, en situaciones de gran ancho de banda, es responsabilidad de tu título transferir los datos a sus propios búferes en modo usuario con baja latencia, a una tasa al menos igual a la que el par o servidor remoto está enviando. Hay un par de maneras de hacerlo, con complejidad y garantías crecientes, pero el objetivo subyacente de todas las sugerencias siguientes es tener siempre un búfer en modo usuario pendiente para la transferencia inmediata en cuanto lleguen los datos, de modo que el kernel no necesite asignar una cantidad creciente de memoria. El efecto neto es cambiar el uso de memoria para los datos pendientes sin procesar del grupo del kernel, extremadamente limitado, a memoria administrada directamente por ti dentro del grupo de memoria mucho mayor de tu título. Las API de nivel superior que consumen WinSock generalmente disponen de mecanismos para controlar el uso de memoria del kernel de sus sockets. Tanto [WinHTTP](/build/console-features/networking/web-requests/intro-winhttp) como [XCurl](/build/console-features/networking/web-requests/intro-xcurl) permiten controlar su uso de memoria del kernel mediante sus respectivos mecanismos de notificación de lectura, mientras que otras API como [XSAPI](https://learn.microsoft.com/windows/uwp/xbox-live/xsapi-flat-c) y [PlayFab Party](/build/console-features/networking/game-mesh/playfab-party-intro-networking) minimizan su uso de memoria del kernel con las técnicas siguientes. ### Sockets Berkeley (BSD) Si quieres seguir usando las API de sockets Berkeley con bloqueo, debes aumentar la frecuencia de las llamadas a recv. Recomendamos usar un subproceso dedicado con un bucle estrecho que ponga en cola los datos recibidos para procesarlos en otro lugar. Idealmente, el subproceso siempre estaría bloqueado dentro de una llamada a recv; cualquier tiempo que se pase fuera de la llamada a recv será potencialmente tiempo en el que el uso de memoria del kernel crecerá mientras espera a que vuelvas a llamar a recv. A menudo, si intentas procesar los datos antes de volver a llamar a recv, tu título puede quedarse atrás y el uso de memoria del kernel crecerá mientras se sigan recibiendo datos a tasas elevadas. También recomendamos especificar tamaños de búfer de al menos 8 k para alinearse con los límites del tamaño de búfer del kernel y para ayudar con la fluctuación y los patrones de envío en ráfagas. ### E/S superpuesta de WinSock La [E/S superpuesta de WinSock](https://learn.microsoft.com/windows/win32/winsock/overlapped-i-o-and-event-objects-2) te permite mantener pendiente de forma asincrónica un búfer de recepción en modo usuario. También permitirá que el kernel use directamente tu búfer de memoria y evite una copia de memoria adicional (a diferencia del paradigma de sockets Berkeley) y, suponiendo que siempre haya un búfer pendiente, el kernel no realizará ninguna asignación para los datos recibidos. Además, con la E/S superpuesta puedes establecer SO\_RCVBUF y SO\_SNDBUF en el valor especial 0, lo que evitará en su mayor parte que se asigne memoria de kernel de envío/recepción. Este enfoque es la mejor manera de administrar la memoria usada por tus sockets en casi todos los escenarios. ### E/S registrada La [E/S registrada](https://learn.microsoft.com/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh997032\(v=ws.11\)) es una API de red compleja que te ofrece la latencia más baja y garantiza que no se use memoria del kernel para las operaciones de envío y recepción. Te permite configurar varios búferes de recepción/envío usados directamente por el kernel para asegurarte de que siempre tengas búferes listos para los datos entrantes. ## Tamaño máximo de la unidad de transmisión UDP Aunque existe un tamaño máximo teórico de carga útil en el Microsoft Game Development Kit (GDK), en la práctica, el máximo para una conexión concreta depende del tipo de conexión de red. Puede variar mientras un título se está ejecutando. En lugar de intentar determinar la unidad de transmisión máxima (MTU) real y reaccionar a los cambios en la MTU mientras tu título se está ejecutando, debes diseñar tu código de red asumiendo una carga útil UDP máxima por paquete de 1384 bytes. Este valor es seguro de usar en todas las configuraciones de red para evitar la fragmentación durante la transmisión. Lo recomendamos tanto si el tipo de socket es IPv4 como IPv6. La transmisión de cargas útiles mayores de 1384 bytes a menudo requiere la fragmentación de paquetes a nivel de IP. La fragmentación de paquetes IP no está bien admitida por los ISP ni por los enrutadores y dispositivos domésticos de los usuarios. En estas configuraciones de red, la fragmentación de paquetes IP no provoca errores en la API de Winsock. En su lugar, la fragmentación se manifiesta como pérdidas de paquetes para tu título. Para evitar la fragmentación de paquetes a nivel de IP, usa 1384 bytes como máximo seguro para la carga útil de tus paquetes. Para asegurarte de que tu título evite la fragmentación y para ayudar a que tu título cumpla los requisitos de XBOX asociados sobre los requisitos mínimos de red multijugador, debes aplicar las opciones de socket `IP_DONTFRAGMENT` e `IP_USER_MTU` a cada socket que abra tu título. Estas marcas solo están disponibles para los títulos de Microsoft Game Development Kit (GDK) cuando la API [XGameRuntimeIsFeatureAvailable(XGameRuntimeFeature::XNetworking)](/reference/system/xgameruntimefeature/functions/xgameruntimeisfeatureavailable) devuelve `true`. Si la característica `XNetworking` no está disponible, la llamada a `setsockopt` produce un error. A continuación se muestra un ejemplo de cómo establecer estas dos opciones de socket. ```cpp theme={null} HRESULT ApplyFragmentationSocketOptions( SOCKET s ) { int value = 1; int error = setsockopt(s, IPPROTO_IP, IP_DONTFRAGMENT, (char *)&value, sizeof(value)); if (error == SOCKET_ERROR) { return HRESULT_FROM_WIN32(WSAGetLastError()); } value = 1384; error = setsockopt(s, IPPROTO_IP, IP_USER_MTU, (char *)&value, sizeof(value)); if (error == SOCKET_ERROR) { return HRESULT_FROM_WIN32(WSAGetLastError()); } return S_OK; } ``` ## Consulte también * [Windows Sockets 2 (Winsock)](https://learn.microsoft.com/windows/desktop/WinSock/windows-sockets-start-page-2) * [Inicialización y conectividad de la red](/build/console-features/networking/initialization-connectivity-networking) * [Puerto multijugador UDP preferido](/build/console-features/networking/game-mesh/preferred-local-udp-multiplayer-port-networking) * [PlayFab Party](/build/console-features/networking/game-mesh/playfab-party-intro-networking) * [Comportamiento de los puertos en PC](/build/console-features/networking/game-mesh/pc-port-behavior) * [Comportamiento de los puertos en consolas XBOX (tema NDA)](/build/console-features/networking/game-mesh/xbox-console-port-behavior) ## Related topics - [Introducción a las redes del Microsoft Game Development Kit](/es/build/console-features/networking/introduction-networking.md) - [Introducción a Linux](/es/services/playfab/multiplayer/networking/linux-specific-requirements.md) - [Introducción al empaquetado MSIXVC2 para PC](/es/build/core-features/common/packaging/overviews/packaging-getting-started-for-PC-msixvc2.md) - [Introducción a la accesibilidad en GDK](/es/build/game-principles/accessibility/accessibility-overview.md) - [Introducción al streaming de juegos](/es/build/core-features/common/game-streaming/game-streaming-overview.md)