Difference between revisions of "Network Protocol"
(Moved to HEADER) |
(Fix bad grammar and outdated info, replace mentions of Wiimmfi with private servers, remove pointless links section) |
||
Line 5: | Line 5: | ||
=== Terminology === | === Terminology === | ||
− | The following terms are used | + | The following terms are commonly used when explaining the game's network protocol. |
{| class="textbox grid sortable alt" | {| class="textbox grid sortable alt" | ||
Line 19: | Line 19: | ||
|- | |- | ||
| Client | | Client | ||
− | | A [[Wii]] system that takes part in | + | | A [[Wii]] system that takes part in a race, with either one or two players. |
|- | |- | ||
| fc, fc8 | | fc, fc8 | ||
Line 61: | Line 61: | ||
|- | |- | ||
| Player | | Player | ||
− | | A player that takes part | + | | A player that takes part in a race, with a maximum of 12. |
|- | |- | ||
| Player ID | | Player ID | ||
Line 67: | Line 67: | ||
|- | |- | ||
| Profile ID, pid, fc4 | | Profile ID, pid, fc4 | ||
− | | The Profile ID is a short version of the friend code with only the lowest 4 bytes (32 bit). It | + | | The Profile ID is a short version of the friend code with only the lowest 4 bytes (32 bit). It acts as a unique identifier for each player. |
|- | |- | ||
| TCP | | TCP | ||
Line 75: | Line 75: | ||
| A packet can be split into logical records. Each record has its own meaning and its own data structure. | | A packet can be split into logical records. Each record has its own meaning and its own data structure. | ||
|- | |- | ||
− | | | + | | UDP |
| [[wikipedia:User Datagram Protocol|User Datagram Protocol]], a network protocol. | | [[wikipedia:User Datagram Protocol|User Datagram Protocol]], a network protocol. | ||
|- | |- | ||
| User | | User | ||
− | | A | + | | A player at the console. Each client supports 1 or 2 users. The users of the client are numbered 1 and 2. |
|} | |} | ||
== Description == | == Description == | ||
− | + | [[Mario Kart Wii]]'s network traffic begins with some domain name resolutions. The game then connects to various servers through TCP connections to check for server availability, perform the login process and queue for matchmaking among other things. In a friend room or while racing, consoles communicate directly with each other using UDP connections. While in a match, "keepalive" records are sent to the servers in order to maintain connectivity. | |
=== Connecting to Servers === | === Connecting to Servers === | ||
− | When connecting to the [[Nintendo Wi-Fi Connection]], the console | + | When connecting to the [[Nintendo Wi-Fi Connection]], the console runs various DNS queries to obtain the IP addresses of the following servers: |
* gpcm.gs.nintendowifi.net | * gpcm.gs.nintendowifi.net | ||
* gpsp.gs.nintendowifi.net | * gpsp.gs.nintendowifi.net | ||
Line 100: | Line 100: | ||
* mariokartwii.ms19.gs.nintendowifi.net | * mariokartwii.ms19.gs.nintendowifi.net | ||
* naswii.nintendowifi.net | * naswii.nintendowifi.net | ||
− | + | Private servers generally follow the same naming scheme, while replacing "nintendowifi.net" with their own domain. More details about each server's purpose can be found [[Network Protocol/Server|here]]. | |
=== Point to Point Communication === | === Point to Point Communication === | ||
− | The [[Wii]] uses a frequency of 59.94Hz ([[NTSC]]) as time base. | + | The [[Wii]] uses a frequency of 59.94Hz ([[NTSC]]) as its time base. Clients send a status update to one of the other clients every other frame, which is approximately 1/30th of a second. |
− | + | For instance, if client A is in a room with two other clients B and C, the latter will receive an update from A every 1/15th of a second. This delay increases with the number of players, reaching up to about 1/3rd of a second with a full room of 12 clients. This latency is the primary cause of lag in larger rooms. | |
− | + | ||
+ | The average packet length is approximately 220 bytes, resulting in a total traffic of about 7 KB/s in both directions, independent of the number of clients. | ||
+ | |||
+ | == Race Packets == | ||
+ | [[RACE]] packets are sent from each client to all other clients in the room. The packet is split into multiple records, which act as logical units. The packet header includes a CRC32 checksum to detect corrupted packets. The following table shows the packet structure and the different records. | ||
{| class="wikitable" | {| class="wikitable" | ||
Line 117: | Line 121: | ||
|- | |- | ||
| [[RACEHEADER_1]] || 0x28 | | [[RACEHEADER_1]] || 0x28 | ||
− | | | + | | A basic race data record. |
|- | |- | ||
| [[RACEHEADER_2]] || 0x28 | | [[RACEHEADER_2]] || 0x28 | ||
− | | | + | | A game mode-dependent race data record. |
|- | |- | ||
| [[ROOM]] || 0x04 | | [[ROOM]] || 0x04 | ||
− | | | + | | Friend room lobby message record. The first byte decides the record type: |
− | + | * 1: Event start message (GP, Team, Balloon or Coin Battle). | |
− | * 1: Event start | + | * 2: A player registered another player as their friend. |
− | * 2: | + | * 3: A player joined the room. |
− | * 3: | + | * 4: Regular room message (online chat). |
− | * 4: | ||
|- | |- | ||
| [[SELECT]] || 0x38 | | [[SELECT]] || 0x38 | ||
− | | This record is sent | + | | This record is sent between matches to set up the next race. One byte decides the phase. |
− | * 0: | + | * 0: Match setup. |
− | * 1: | + | * 1: Course selection. |
− | * 2: | + | * 2: Voting lottery. |
|- | |- | ||
− | | [[RACEDATA]] || 0x40 | + | | [[RACEDATA]] || 0x40 (per player) |
− | | | + | | Race data record, containing player position, inputs and other miscellaneous info. |
|- | |- | ||
| [[USER]] || 0xC0 | | [[USER]] || 0xC0 | ||
− | | User | + | | User record, including friend code and one Mii for each player. |
|- | |- | ||
− | | [[ITEM]] || 0x08 | + | | [[ITEM]] || 0x08 (per player) |
− | | Record | + | | Record containing each player's item status. |
|- | |- | ||
| [[EVENT]] || ≥ 0x18 | | [[EVENT]] || ≥ 0x18 | ||
− | | Record | + | | Record containing item events, such as throwing an item or dropping one. |
|} | |} | ||
− | == Additional Records == | + | === Additional Records === |
− | The following table shows additional records. | + | The following table shows additional records, which are not necessarily present in every race packet. |
{| class="wikitable" | {| class="wikitable" | ||
! Name | ! Name | ||
− | ! | + | ! Magic |
! Length | ! Length | ||
! Description | ! Description | ||
|- | |- | ||
− | | [[SLOT]] || <tt> | + | | [[SLOT]] || <tt>46.FC.57.0X</tt> || 0x08 |
− | | The following | + | | The message following this record is to be forwarded to client slot '''X'''. If a client has bandwidth problems, it can use another client as a proxy to reduce its own traffic during a match. Such indirect packets are also prefixed by a [[SLOT]] record. |
|- | |- | ||
− | | [[STATUS]] || <tt> | + | | [[STATUS]] || <tt>BB.49.CC.4D</tt> || ≥ 0x14 |
− | | A status record with | + | | A status record with various purposes. Byte 0x08 describes the record type. For example, it can be used to allow or deny access to a room. |
|- | |- | ||
− | | [[HANDSHAKE]] || <tt> | + | | [[HANDSHAKE]] || <tt>FD.FC</tt> || ≥ 0x14 |
− | | [[NATNEG]] records. | + | | [[NATNEG]] records. Type CONNECT_PING is sent through peer-to-peer, while all other types are routed through the NATNEG servers. |
|- | |- | ||
− | | [[QUIT]] || <tt> | + | | [[QUIT]] || <tt>FE.FE.68</tt> || 0x03 |
− | | This record is sent when a client | + | | This record is sent when a client leaves a room. It is not prefixed by a CHECKSUM record. |
|} | |} | ||
− | == | + | == States == |
− | This section describes what | + | This section describes what data is transmitted between clients during specific stages of gameplay. |
− | === Room === | + | === Joining a Room === |
− | When a | + | ==== Friend Room ==== |
+ | When a client wants to join a friend room, it sends a "GPCM90" type 1 message to the [[MASTER]] server. This asks the server for permission to enter the room, which will either be answered with a type 2 message (access granted) or a type 3 message (access denied). If access is granted, the new client and the host begin exchanging [[NATNEG]] messages to establish a peer-to-peer connection. | ||
− | After NATNEG | + | After completing NATNEG, the two clients send each other an empty race packet ([[ANNOUNCE]]) to indicate a successful connection. |
− | + | The new player then appears in the room and starts doing NATNEG with all the other clients. Because NATNEG is very slow and does not run in threads, only one client can join a room at a time. Additionally, starting a match as soon as every client is in the room will cause significant delays, as the peer-to-peer mesh network (which can involve up to 66 connections with 12 clients) is incomplete. | |
− | === | + | ==== Worldwide ==== |
− | As soon as | + | As soon as a client has found a room through [[MS|matchmaking]], it sends an "asking for entrance" status message. If the room host is in the client's friend list, GPCM90 messages are used; otherwise, the [[STATUS]] messages are proxied through MS and/or [[MASTER]]. |
− | Then, | + | Then, similarly to friend rooms, [[NATNEG]] is performed and an empty record ([[ANNOUNCE]]) is exchanged to mark the completion of the handshake. |
− | |||
− | During | + | During live view, only part of the main records are sent. |
− | === Start | + | === Friend Room Start === |
− | + | When the room host wishes to start playing, they send a [[ROOM]] message to indicate the beginning of an event. Each player chooses their character and vehicle, and the match setup begins. The setup has three phases: | |
− | + | * '''Prepare''': The waiting phase before players can interact with the game to view their rating or vote for a track. In this phase, the game is working in the background to synchronize the time, race settings and various other information across clients. | |
− | + | * '''Voting''': The voting phase, which lasts until every player has voted. | |
− | + | * '''Lottery''': The lottery that determines the track to play. While the winning track is already decided before the lottery even begins, the game uses this time to preload the track and finish synchronizing all the necessary information. | |
=== Countdown === | === Countdown === | ||
− | Before the countdown, the host sends a "ready?" request to all clients. | + | Before the countdown begins, the host sends a "ready?" request to all clients. While waiting for the clients to respond, the loading icon will appear in the bottom right corner of the screen. Once every client is synchronized, the match can start. |
− | |||
− | |||
− | |||
− | == | + | === Race Finish === |
− | + | As soon as the race leader reaches the finish line, their completion time is sent to all the other players, who then have a limited time to complete the race. When the race is finished by either everyone crossing the finish line, the [[Online Time Limit|maximum race time limit]] being reached or the aforementioned limited time running out, the "finish" phase is activated. The rankings will be displayed and the next race will begin. | |
− | |||
− | |||
{{Network Protocol}} | {{Network Protocol}} | ||
[[Category:File Format/MKW]] | [[Category:File Format/MKW]] | ||
[[Category:Network Protocol|!]] | [[Category:Network Protocol|!]] |
Latest revision as of 17:15, 28 January 2024
Overview
This article describes the network protocol used by Mario Kart Wii.
Terminology
The following terms are commonly used when explaining the game's network protocol.
Term | Description |
---|---|
ARP | Address Resolution Protocol, a network routing protocol. |
cfc | The console friend code. It is displayed as 16 digits in the format "XXXX-XXXX-XXXX-XXXX". |
Client | A Wii system that takes part in a race, with either one or two players. |
fc, fc8 | The friend code of the first user of a client. Sometimes it is extended by ".1" or ".2" to identify the user of the client. A friend code is displayed as 12 digits using format "XXXX-XXXX-XXXX". |
GPCM | The client server. |
GPSP | The server that retrieves friends. |
Guest | All non-host clients. |
Home client | The observed client where the network traffic comes from. |
Host | The client who has opened the room. |
MASTER | The master matchmaking server. |
Mii | The Mii avatar of a user. |
MS | The matchmaking retrieving server. |
N-server | One of Nintendo's servers. |
NAS, NASWII | The login server. |
NATNEG | The server that enables client to client connections behind firewalls. It stands for Network Address Translation NEGotiation. |
Packet | A packet is a technical network packet. Mario Kart Wii uses ARP, TCP and UDP (including name resolution) packets. |
Player | A player that takes part in a race, with a maximum of 12. |
Player ID | An alternative name for Profile ID. |
Profile ID, pid, fc4 | The Profile ID is a short version of the friend code with only the lowest 4 bytes (32 bit). It acts as a unique identifier for each player. |
TCP | Transmission Control Protocol, a network protocol. |
Record | A packet can be split into logical records. Each record has its own meaning and its own data structure. |
UDP | User Datagram Protocol, a network protocol. |
User | A player at the console. Each client supports 1 or 2 users. The users of the client are numbered 1 and 2. |
Description
Mario Kart Wii's network traffic begins with some domain name resolutions. The game then connects to various servers through TCP connections to check for server availability, perform the login process and queue for matchmaking among other things. In a friend room or while racing, consoles communicate directly with each other using UDP connections. While in a match, "keepalive" records are sent to the servers in order to maintain connectivity.
Connecting to Servers
When connecting to the Nintendo Wi-Fi Connection, the console runs various DNS queries to obtain the IP addresses of the following servers:
- gpcm.gs.nintendowifi.net
- gpsp.gs.nintendowifi.net
- gamestats.gs.nintendowifi.net
- gamestats2.gs.nintendowifi.net
- mariokartwii.available.gs.nintendowifi.net
- mariokartwii.natneg1.gs.nintendowifi.net
- mariokartwii.natneg2.gs.nintendowifi.net
- mariokartwii.natneg3.gs.nintendowifi.net
- mariokartwii.master.gs.nintendowifi.net
- mariokartwii.gamestats.gs.nintendowifi.net
- mariokartwii.gamestats2.gs.nintendowifi.net
- mariokartwii.ms19.gs.nintendowifi.net
- naswii.nintendowifi.net
Private servers generally follow the same naming scheme, while replacing "nintendowifi.net" with their own domain. More details about each server's purpose can be found here.
Point to Point Communication
The Wii uses a frequency of 59.94Hz (NTSC) as its time base. Clients send a status update to one of the other clients every other frame, which is approximately 1/30th of a second.
For instance, if client A is in a room with two other clients B and C, the latter will receive an update from A every 1/15th of a second. This delay increases with the number of players, reaching up to about 1/3rd of a second with a full room of 12 clients. This latency is the primary cause of lag in larger rooms.
The average packet length is approximately 220 bytes, resulting in a total traffic of about 7 KB/s in both directions, independent of the number of clients.
Race Packets
RACE packets are sent from each client to all other clients in the room. The packet is split into multiple records, which act as logical units. The packet header includes a CRC32 checksum to detect corrupted packets. The following table shows the packet structure and the different records.
Name | Size | Description |
---|---|---|
HEADER | 0x10 | The packet header. |
RACEHEADER_1 | 0x28 | A basic race data record. |
RACEHEADER_2 | 0x28 | A game mode-dependent race data record. |
ROOM | 0x04 | Friend room lobby message record. The first byte decides the record type:
|
SELECT | 0x38 | This record is sent between matches to set up the next race. One byte decides the phase.
|
RACEDATA | 0x40 (per player) | Race data record, containing player position, inputs and other miscellaneous info. |
USER | 0xC0 | User record, including friend code and one Mii for each player. |
ITEM | 0x08 (per player) | Record containing each player's item status. |
EVENT | ≥ 0x18 | Record containing item events, such as throwing an item or dropping one. |
Additional Records
The following table shows additional records, which are not necessarily present in every race packet.
Name | Magic | Length | Description |
---|---|---|---|
SLOT | 46.FC.57.0X | 0x08 | The message following this record is to be forwarded to client slot X. If a client has bandwidth problems, it can use another client as a proxy to reduce its own traffic during a match. Such indirect packets are also prefixed by a SLOT record. |
STATUS | BB.49.CC.4D | ≥ 0x14 | A status record with various purposes. Byte 0x08 describes the record type. For example, it can be used to allow or deny access to a room. |
HANDSHAKE | FD.FC | ≥ 0x14 | NATNEG records. Type CONNECT_PING is sent through peer-to-peer, while all other types are routed through the NATNEG servers. |
QUIT | FE.FE.68 | 0x03 | This record is sent when a client leaves a room. It is not prefixed by a CHECKSUM record. |
States
This section describes what data is transmitted between clients during specific stages of gameplay.
Joining a Room
Friend Room
When a client wants to join a friend room, it sends a "GPCM90" type 1 message to the MASTER server. This asks the server for permission to enter the room, which will either be answered with a type 2 message (access granted) or a type 3 message (access denied). If access is granted, the new client and the host begin exchanging NATNEG messages to establish a peer-to-peer connection.
After completing NATNEG, the two clients send each other an empty race packet (ANNOUNCE) to indicate a successful connection.
The new player then appears in the room and starts doing NATNEG with all the other clients. Because NATNEG is very slow and does not run in threads, only one client can join a room at a time. Additionally, starting a match as soon as every client is in the room will cause significant delays, as the peer-to-peer mesh network (which can involve up to 66 connections with 12 clients) is incomplete.
Worldwide
As soon as a client has found a room through matchmaking, it sends an "asking for entrance" status message. If the room host is in the client's friend list, GPCM90 messages are used; otherwise, the STATUS messages are proxied through MS and/or MASTER.
Then, similarly to friend rooms, NATNEG is performed and an empty record (ANNOUNCE) is exchanged to mark the completion of the handshake.
During live view, only part of the main records are sent.
Friend Room Start
When the room host wishes to start playing, they send a ROOM message to indicate the beginning of an event. Each player chooses their character and vehicle, and the match setup begins. The setup has three phases:
- Prepare: The waiting phase before players can interact with the game to view their rating or vote for a track. In this phase, the game is working in the background to synchronize the time, race settings and various other information across clients.
- Voting: The voting phase, which lasts until every player has voted.
- Lottery: The lottery that determines the track to play. While the winning track is already decided before the lottery even begins, the game uses this time to preload the track and finish synchronizing all the necessary information.
Countdown
Before the countdown begins, the host sends a "ready?" request to all clients. While waiting for the clients to respond, the loading icon will appear in the bottom right corner of the screen. Once every client is synchronized, the match can start.
Race Finish
As soon as the race leader reaches the finish line, their completion time is sent to all the other players, who then have a limited time to complete the race. When the race is finished by either everyone crossing the finish line, the maximum race time limit being reached or the aforementioned limited time running out, the "finish" phase is activated. The rankings will be displayed and the next race will begin.
Information:
Nintendo's Servers –
Friend Code –
Nick –
Dumping Network Traffic
Record Types:
HEADER –
ROOM –
SELECT –
USER
RACEHEADER_1 –
RACEHEADER_2 –
RACEDATA –
ITEM –
EVENT
NATNEG –
ANNOUNCE –
QUIT –
STATUS –
PARAM-STRING
Wiimmfi Extensions:
Online Status –
Connection Status –
Wiimmfi packets –
Server SV
Software:
Wiimms mkw-ana