- Azure PlayFab Party For client-to-client communication, titles are encouraged to use the PlayFab Party APIs. They provide similar functionality to Secure Sockets in the XBOX One Software Development Kit. These APIs also provide secure communication, network address translation (NAT) traversal through communication relays, and voice and text chat functionality.
- Datagram Transport Layer Security (DTLS)
Titles can also choose to encrypt their packet payloads by using DTLS. Titles can implement this through either the
OpenSSLorBcryptAPIs, or use middleware that encapsulates such an implementation. All communication, regardless of content, must be encrypted and authenticated through title services. For more details about the requirements for this solution, see Secure Game Communication for Microsoft Game Development Kit Titles.
Title communication between the Microsoft Game Development Kit (GDK) and XBOX One Software Development Kit title versions
Titles are encouraged to use the GDK for all XBOX console hardware. This allows the use of a unified network implementation. In certain scenarios, a title might still want to support network communication between an XBOX One Software Development Kit and the GDK title version. For this scenario, XBOX One Software Development Kit titles can’t use the Secure Sockets APIs because they aren’t network-compatible with Azure PlayFab Party APIs in the GDK. The same applies for XIM APIs that were built on top of Secure Socket functionality. Titles that used Secure Sockets or XIM in the XBOX One Software Development Kit title version must update the title’s network stack to either Azure PlayFab Party or DTLS communication. We recommend Azure PlayFab Party as the solution for all client-to-client communication. Azure PlayFab Party also simplifies voice and text chat functionality. Titles that use dedicated servers or relay servers with the XBOX One Software Development Kit title version can do the same to enable network communication with the GDK title version. All communication protocols should always be authenticated, secured, and adhere to security best practices.Network initialization
In the Microsoft Game Development Kit (GDK), your title is started as soon as possible during the Game OS startup process. You can start loading assets from the hard drive and begin initializing the graphics stack. This means that your code is executing before the network services have even been started, which leads to a period of time where it’s not safe to use the Win32 network APIs. We define this time period as the network initialization period, after which the network is considered initialized. Network initialization typically takes a few seconds, which can be very noticeable in your code. Network initialization in XBOX One ERA titles would implicitly and arbitrarily stall otherwise real-time-safe network APIs, such asWSAStartup or bind. In the Microsoft Game Development Kit (GDK), network initialization is now an explicit concept that you must interact with to use any Win32 networking or security APIs.
Microsoft Game Development Kit (GDK) titles must wait until the XNetworkingConnectivityHint::networkInitialized Boolean is set to true before calling into any networking API in Winsock, WinHTTP, IP Helper, BCrypt, WinCrypt, Schannel, or any other networking Win32 API. Calling into any of these APIs before the network is initialized results in indeterminate behavior up to and including random process crashes.
Furthermore, this same concept applies on all suspend/resume cycles. On suspend, Microsoft Game Development Kit (GDK) titles should close all network and security handles. Microsoft Game Development Kit (GDK) titles should then treat the resume handler the same as the initial title launch from a networking perspective and again wait for the network to become initialized.
For more information, including code examples that show how to wait for network initialization, see Network initialization and connectivity.
Port behavior
In XBOX One ERA titles, you predefined every single socket flow that your title performed in the network manifest. In the Microsoft Game Development Kit (GDK), the manifest has now been removed. Ports on XBOX One consoles now behave in the same way that they do for Windows PC - you callbind on whatever port you want, and that port allows all outbound and solicited inbound traffic on both Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). Unsolicited inbound UDP and TCP traffic is blocked. This means that TCP peer-to-peer network topologies are no longer allowed. Microsoft Game Development Kit (GDK) titles should use UDP for their game flows.
Microsoft Game Development Kit (GDK) titles now also have direct access to the preferred local UDP multiplayer port. This port represents the best port to your peers and servers that the platform has to offer for the reason that it’s backed by troubleshooting and user configuration. We highly recommend that you adjust your multiplayer and voice traffic to use this port to improve your overall connectivity success rates.
For more details about port behavior, see XBOX console port behavior and Preferred UDP multiplayer port.