Consumer networking environments are imperfect and chaotic. Available bandwidth and transmission reliability may be considerably worse than what you encounter in your development space.
To provide the best possible experience for a diverse user base, it is useful to test your game in the context of realistic customer environments. Network simulation on Xbox One allows the simulation of limited bandwidth, packet loss, and latency—so you can see how your game behaves in variable conditions.
Network simulation is controlled by the command-line stress tool in the XDK, xbstress.exe. This tool configures various console stressors, including network simulation. For complete details, see the xbstress.exe reference page. For networking purposes xbstress controls a specialized driver on the Xbox One, which drops packets, injects latency, and limits throughput.
When using network simulation, you want to provide a “clean” network environment, so that the only network issues are the ones caused by the xbstress tool. A clean environment should meet the following criteria.
xbstress.exe has four pre-configured simulation profiles that allow you to easily simulate important networking scenarios: broken, minimum, average, and excellent. (These profiles are based on figures from various sources that monitor the ongoing quality of Internet connections.) Like other command line tools, xbstress.exe interprets the /X: command line flag as the IP address or hostname of the console where the simulation command will execute.
xbstress simulate network=minxbstress simulate network=avgxbstress simulate network=excxbstress simulate network=brokenxbstress stopThe details of the various simulation profiles are described in the following table.
| Profile | Description | Bandwidth | Packet Loss | Total Injected Latency |
|---|---|---|---|---|
| Broken | Simulates loss of connectivity. Note that even when this value is specified, development tools (debugger, remote command line tools, and PIX) continue to work properly. | No data is transmitted | 100% | No data is transmitted |
| Minimum(min) | Represents the minimum operating requirements ofXbox One. It is a certification requirement that titles be able to support this environment without freezes or crashes. | Outbound: 192 KbpsInbound: 192 Kbps | 1% | 75ms |
| Average(avg) | Represents reasonable DSL connectivity. This is the profile you should focus on when testing your title’s network performance. | Outbound: 700 KbpsInbound: 1 Mpbs | 1% | 50ms |
| Excellent(exc) | Represents excellent broadband connectivity. | Outbound: 10 MpbsInbound: 35 Mpbs | 0.5% | 30ms |
Latency is injected on both directions of the console’s networking flows. To simulate the average profile, we implement an effective latency of 50 milliseconds by injecting a 25 millisecond delay on inbound and outbound packets. If you simulate the average profile on two consoles on the same link, their effective peer to peer latency would be 50 milliseconds in both directions.
In order to verify that your networking code is robust and ready for certification, you should test your code when it is confronted with complex network conditions—situations where a console can reach some of the endpoints it uses, but where other endpoints are either unavailable or connection bandwidth is limited. You can simulate such complex network conditions by using the channel feature of xbstress.exe.
For example, you would use channels to simulate conditions like those in the following list.
To specify how access to a particular address or range of addresses should be simulated, you specify a channel for the address or range, and the connection profile to be simulated over the channel. You define a separate channel for each address or address range where you want to specify a different connection profile. Once you have specified all of the channels that apply for a simulation scenario, you use the xbStress simulate network=channels command to begin simulating the network conditions specified by your channels.
Each channel specification has three values.
To use xbstress.exe to block all access to Xbox Live, you can use the IP addresses for the Live servers as follows.
xbStress set channel=0 network=broken addresses=134.170.28.0/255.255.254.0
xbStress set channel=1 network=broken addresses=191.232.80.128/255.255.255.128
xbStress set channel=2 network=broken addresses=191.232.82.128/255.255.255.128
xbStress set channel=3 network=broken addresses=191.234.78.0/255.255.254.0
xbStress set channel=4 network=broken addresses=131.253.28.0/255.255.254.0
xbStress set channel=5 network=broken addresses=134.170.176.0/255.255.252.0
xbStress set channel=6 network=broken addresses=157.56.70.0/255.255.254.0
xbStress set channel=7 network=broken addresses=65.55.42.0/255.255.254.0
xbStress set channel=8 network=broken addresses=131.253.22.0/255.255.254.0
xbStress set channel=9 network=broken addresses=191.234.240.0/255.255.248.0
xbStress simulate network=channels
(The addresses of the Live servers are documented in Configuring Your Development Network Access.)
To block access to an individual Xbox Live service, you could also use the hostname for that service. The hostname for a particular service is listed on the reference page the service. (For example, you will find that the Achievements service reference page says that the service is hosted at achievements.xboxlive.com. So you could simulate reduced bandwidth from the Achievements service with the following command.
xbStress set channel=0 network=min addresses=achievements.xboxlive.com
xbStress simulate network=channel
xbstress.exe provides the ability to control inbound bandwidth, outbound bandwidth, packet loss, and latency individually. Use these controls when you want more fine-grained control of the simulation parameters. See the xbstress.exe reference page for details.
Network simulation does not impact all traffic coming from the Xbox One. Traffic associated with tools is exempted from network simulation in order to ensure that those tools work properly while you are debugging the issues that arise when you are challenging your network code with a simulated connection.
If for some reason network simulation causes a console to become unusable despite these exemptions, you can deactivate network simulation by unplugging the console power supply, waiting ten seconds, replacing the plug, and turning the console back on.
The following traffic is unaffected by network stress limits. Note that this list is not exhaustive, and other traffic used for system functionality might also be allowed to evade network stress limitations in some circumstances.
If you would like to exempt additional ports from network simulation for the use of your own custom tools, you can use the xbstress.exe tool to set up custom port exemptions. Your tools could then proceed to use those ports to communicate across the network.
To set up a port exemption, use the tcpportexemptions or udpportexemptions arguments to xbstress. Both arguments are followed by a semicolon-separated list of ports to be exempted from simulation. The following examples demonstrate using these commands.
xbstress set tcpportexemptions 49152;49153 command creates exemptions for TCP ports 49152 and 49153.xbstress set udpportexemptions 49153;49154 command creates exemptions for UDP ports 49153 and 49154.Using xbtrace to perform on-console network captures while also performing networking simulation can lead to potentially misleading network captures. This is because simulation effects, such as packet drops, are implemented after the capture procedure. For example, a capture could indicate that a packet was transmitted, when in fact it was subsequently dropped by the simulation driver before actually being transmitted over the network.