Xbox One supports use of the Windows Socket (Winsock) API over designated sockets or socket ranges, using your choice of TCP or UDP. However, Xbox One requires that you specify the characteristics of every socket you use in the XboxNetworkingManifest node within your app manifest. These descriptions are used by the Xbox One system software to ensure that apps share network resources effectively and securely.
Note that only Winsock communications require you to specify secure socket connection information. If you communicate with a server using IXMLHttpRequest2 (IXHR2) or WebSockets, you do not need to add anything to the manifest for those activities.
The way you work with Winsock on Xbox One is essentially the same as the way you work with Winsock on Windows and the socket programming model on other platforms. The main difference from working on other platforms is that you must declare the sockets and traffic patterns you use in the app manifest, as described later in this topic.
You must #include <winsock2.h>
in your source files, and you must link with ws2_32.lib.
The following Winsock functions are not supported on Xbox One.
Xbox One supports TCP and UDP. It does not support raw sockets.
Xbox One apps use Secure Sockets through Winsock for all client communication. Secure Sockets protect communication using industry-standard protocols (IPsec) for secure, encrypted, robust communication channels. Secure sockets are configured by specifying a simple description of your title’s socket use in the app manifest for your title. By describing the way your title uses sockets, the console can ensure that no other application on the console will be allowed to use the same local ports as your title might be using when it is executing, and certification and development tools can provide better insight into your title’s communication patterns. Reference topics for the Secure Sockets API are located under the Windows.Xbox.Networking namespace.
The Secure Socket infrastructure and network manifest declarations must be used for all client data that is passed through the WinSock API. It is not necessary to use secure communication (authentication and encryption) for private development tool or debugging traffic. However, insecure communication has to be declared as such in your app manifest. Note that including debug usages in your certification submission will cause your submission to be rejected—no insecure traffic is allowed in an app or title that is released to consumers. Communication to dedicated servers and title services has to be secured as well.
To specify a secure socket, first create a SocketDescription element in the app manifest for each socket your title is going to use. Provide a SocketDescription for every socket, both local and remote ones. You will use these socket descriptions in the SecureDeviceAssociationTemplate that is discussed later in this topic.
Note that you can combine the *GameData and *Chat usages on the same socket if you use that socket for both kinds of data, but you cannot combine *Debug usages with *GameData or *Chat. If you specify an invalid combination of flags, the manifest will be invalid and you’ll get an error when attempting to use the secure sockets APIs.
Once you’ve described the sockets you will use, you need to describe how pairs of sockets are combined to make a specific traffic flow. You do this by creating a SecureDeviceAssociationTemplate element in the app manifest:
A template consists of a name for the association, the SocketDescription name of the initiator and acceptor sockets, a MultiplayerSessionRequirement value, and a collection of SecureDeviceAssociationUsage values in an AllowedUsages element. The value you assign to MultiplayerSessionRequirement describes whether you intend for the association to be created only when both endpoints are participating in a multiplayer session.
Using Winsock to communicate with a peer console requires some additional setup code beyond the usual Winsock initialization.
Note that the process of establishing the SecureDeviceAssociation is frequently a long operation, depending on network connectivity and template requirements. You should avoid blocking user action waiting for this asynchronous operation, by creating associations as soon as you know they’ll be needed, rather than waiting until they are required for progress.
If you are writing tools for Exclusive Partition apps that use sockets to communicate with a dev kit, you should create appropriate socket descriptions (with *Debug usages) and device association templates in your app manifest for the socket connections to be used by those tools. If this is impractical or impossible, then tools may use ports 4600 and 4601. Those ports are reserved on retail consoles, but are designated for tool communications on dev kits. Developers using those ports for tools do not need to add those ports to their app manifest in order to use them during development. Note that these ports are not supported for Shared Partition apps.
If you are using Xbox Live Compute, secure sockets are available on the server, and you use them in the same way as you would on Xbox One consoles. If your needs require a direct socket connection to another server besides WebSockets or HTTP, please contact your Developer Account Manager.
While there is a theoretical maximum payload size on Xbox One, the actual maximum for a given connection varies depending on the network connection type, and the connection type can vary while a title is running. Instead of attempting to determine the actual maximum transmission unit (MTU) and react to changes in the MTU while your title is running, you should design your networking code to assume a max UDP payload per packet of 1,264 bytes. This value is safe to use under all networking configurations in order to avoid in-transmission fragmentation. We maintain this guidance regardless of socket type (secure or insecure; IPv4 or IPv6).
Note that if you try to send payloads greater than 1,264 bytes, you will not receive an error. In fact, doing so may work in some network configurations, but not in others. We recommend that you use 1,264 as a safe maximum that works for all configurations.
The network stack takes some time to initialize when your title is launched. And if you attempt to initialize WinSock too soon, it will fail because the network stack is not yet prepared to support that operation. To ensure that you can initialize WinSock successfully, your code should not call WSAStartup until a call to GetNetworkConnectivityLevel returns XboxLiveAccess as the current connectivity level.
Xbox Live Services API Reference
Windows Sockets (Winsock) Reference