Difference between revisions of "Network Protocol"

From Custom Mario Kart
Jump to navigation Jump to search
(Fix bad grammar and outdated info, replace mentions of Wiimmfi with private servers, remove pointless links section)
 
(19 intermediate revisions by 6 users not shown)
Line 1: Line 1:
This page describes the '''network protocol''' used by [[Mario Kart Wii]].
+
{{under-construction}}
  
__TOC__
+
== 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.
  
{{textbox|red center|In Progress|This article is managed by [[Wiimm]] and [[User:Leseratte|Leseratte]] and will grow slowly. Feel free to edit typos and grammatical or speech issues. If you have additional information, please complete this page.}}
+
{| class="textbox grid sortable alt"
 
+
|+ Game Features
 
+
! Term
== Introduction ==
+
! Description
 
+
|-
The analysis of the data is done with the tool
+
| ARP
[[Wiimms mkw-ana (tool)|mkw-ana]]. So the naming of mkw-ana for objects
+
| [[wikipedia:Address Resolution Protocol|Address Resolution Protocol]], a network routing protocol.
(records, stages, ...) is used here.
+
|-
Because of the very early phase of the analysis,
+
| cfc
names and structures may completely change.
+
| The console friend code. It is displayed as 16 digits in the format "XXXX-XXXX-XXXX-XXXX".
 
+
|-
You can discuss this topic at [http://forum.wii-homebrew.com/board42-kreativitaet/board329-mkw-server-project-english/ Wii-Homebrew.com] (English and German) or at [http://www.mariokartwii.com/f101/mkw-ana-mario-kart-wii-network-protocol-109421.html mariokartwii.com] (English).  
+
| Client
 
+
| A [[Wii]] system that takes part in a race, with either one or two players.
=== Terms and definition ===
+
|-
 
+
| fc, fc8
{{MKWii Network Terms}}
+
| 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".
 
+
|-
== General description ==
+
| [[GPCM]]
 
+
| The client server.
The [[Mario Kart Wii]] traffic starts with some name resolutions.
+
|-
Then it will use TCP connection to the servers and UDP packets for the player to player data transfer.
+
| [[GPSP]]
 
+
| The server that retrieves friends.
First it connects the Wiimmfi server (N-server).
+
|-
In a room or while racing, all Wiis communicate directly to each other.
+
| Guest
In a race, only some ''alive'' records are send to a N-server.
+
| 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.
 +
|-
 +
| [[Network Protocol/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 '''N'''etwork '''A'''ddress '''T'''ranslation '''NEG'''otiation.
 +
|-
 +
| 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
 +
| [[wikipedia:Transmission Control Protocol|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
 +
| [[wikipedia:User Datagram Protocol|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.
 +
|}
  
=== Connecting the Wiimmfi-Server(s) ===
+
== 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.
  
When entering the Mario Kart WFC, the Wii started with DNS queries to find out the IP addresses of the following servers:
+
=== 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
 
* gpcm.gs.nintendowifi.net
 
* gpsp.gs.nintendowifi.net
 
* gpsp.gs.nintendowifi.net
Line 46: 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]].
  
("nintendowifi.net" replaced with "wiimmfi.de" for the Wiimmfi server)
+
=== 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.
  
Then it starts the communication with nintendos servers and the first packet goes to ''mariokartwii.available.gs.nintendowifi.net''.
+
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.
  
'''→ [[MKWii Network Protocol/Server|More Details about the servers]]'''
+
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.
  
=== Point to point communication ===
+
== 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.
  
The Wii uses a frequency of 59.94Hz (based on NTSC, about 1/60s) as time base.
+
{| class="wikitable"
All clients send a status packet to one of the other clients every second pulse (~1/30s).
+
! Name
When there are for example 3 clients A, B and C, then A sends first a packet to B and then, 1/30s later, a packet to C, and again 1/30s later, the next packet to B. This means, that the individual status update is only done every 1/15s. This update time is reduced to 11/30s (~1/3s), when there are 12 clients in a race. And that's the reason for the many lagging effects when playing with many players.
+
! Size
 
+
! Description
The average packet length is about 220 bytes, so the total traffic is about 6.6 KB/s (52.8 KBit/s) in both directions, independent of the number of clients.
+
|-
 
+
| [[HEADER]] || 0x10
== Main records ("RACE" records) ==
+
| The packet header.
 
 
Each UDP packet can be split in records. Records are logical units.
 
 
 
A race packet consists of records. Mostly all packets start with the [[MKWii_Network_Protocol/CHECKSUM|CHECKSUM]] record. Sometimes, a packet is prefixed by a [[MKWii_Network_Protocol/SLOT|SLOT]]-record to reduce a client's needed upload bandwidth.
 
 
 
After SLOT and CHECKSUM, the main race header (8 byte) follows:
 
 
 
<pre>typedef struct header_t
 
{
 
/*00*/  u8 header_len;          // always 0x10 (length of checksum record + length of this header)
 
/*01*/  u8    raceheader1_len;      // length of the first race header. 0x28 or 0x00
 
/*02*/  u8    raceheader2_len;      // length of the 2nd race header. 0x28 or 0x00
 
/*03*/  u8    room_select_len;      // length of the ROOM or SELECT record. 0x04 (for room), 0x38 (for select), or 0x00
 
 
 
/*04*/  u8    racedata_len;        // length of RACEDATA. 0x40 (for 1 player), 0x80 (for 2 players) or 0x00
 
/*05*/  u8    user_len;            // length of USER. 0xc0 or 0x00
 
/*06*/  u8    item_len;            // length of ITEM. 0x08 (for 1 player), 0x10 (for 2 players) or 0x00
 
/*07*/  u8    event_len;            // length of EVENT. 0x00, or >= 0x18
 
 
 
/*08*/
 
}
 
__attribute__ ((packed)) header_t;</pre>
 
 
 
RACE records are send from every client to all other clients during a race including the race preparation.
 
 
 
The following table shows:
 
* A name used by [[mkw-ana]].
 
* Data length
 
* Description.
 
 
 
{| class="textbox alt headline grid"
 
|+ List of Records
 
! Name !! Length !! Description
 
 
|-
 
|-
| [[MKWii_Network_Protocol/RACEHEADER_1|RACEHEADER_1]] || 0x28
+
| [[RACEHEADER_1]] || 0x28
| Race header
+
| A basic race data record.
 
|-
 
|-
| [[MKWii_Network_Protocol/RACEHEADER_2|RACEHEADER_2]] || 0x28
+
| [[RACEHEADER_2]] || 0x28
| Another race header
+
| A game mode-dependent race data record.
 
|-
 
|-
| [[MKWii Network Protocol/ROOM|ROOM]] || 0x04
+
| [[ROOM]] || 0x04
| The first byte decides the sub type:
+
| Friend room lobby message record. The first byte decides the record type:
* '''0:''' ''unknown''
+
* 1: Event start message (GP, Team, Balloon or Coin Battle).
* '''1:''' Send by host: Start an event (GP, Team, Ballon or Coin).
+
* 2: A player registered another player as their friend.
* '''2:''' ''unknown''
+
* 3: A player joined the room.
* '''3:''' ''unknown''
+
* 4: Regular room message (online chat).
* '''4:''' Send a room message (online chat).
 
Room records are only sent in room events.  
 
 
|-
 
|-
| [[MKWii Network Protocol/SELECT|SELECT]] || 0x38
+
| [[SELECT]] || 0x38
| This record is send while selecting driver and track. It is always placed before an [[MKWii Network Protocol/USER|USER]] record. One byte decides the phase:
+
| This record is sent between matches to set up the next race. One byte decides the phase.
* '''0:''' Prepare the race.
+
* 0: Match setup.
* '''1:''' Before first race: Driver selection. All races track selection by user.
+
* 1: Course selection.
* '''2:''' Track lottery. Before start of the lottery, the host sends to all clients the winning user and track.
+
* 2: Voting lottery.
 
|-
 
|-
| [[MKWii_Network_Protocol/RACEDATA|RACEDATA]] || 0x40
+
| [[RACEDATA]] || 0x40 (per player)
| Actual race data. May exist twice if there are two players on one console.  
+
| Race data record, containing player position, inputs and other miscellaneous info.
 
|-  
 
|-  
| [[MKWii Network Protocol/USER|USER]] || 0xc0 ?
+
| [[USER]] || 0xC0
| A user information including a FC and 2 Miis for both users of the client.
+
| User record, including friend code and one Mii for each player.
 
|-
 
|-
| [[MKWii_Network_Protocol/ITEM|ITEM]] || 0x08
+
| [[ITEM]] || 0x08 (per player)
| Record indicating the item status
+
| Record containing each player's item status.
|-
 
| [[MKWii_Network_Protocol/EVENTHEAD|EVENT]] || >= 0x18
 
| Record indicating the event status (consists of EVENTHEAD and EVENTDATA)
 
 
|-  
 
|-  
 +
| [[EVENT]] || &ge; 0x18
 +
| Record containing item events, such as throwing an item or dropping one.
 
|}
 
|}
  
== Additional records ==
+
=== Additional Records ===
 
+
The following table shows additional records, which are not necessarily present in every race packet.
The following table shows:
 
* A name used by [[mkw-ana]].
 
* Value of the first 2-4 bytes (Record ID, big endian, hex).
 
* Length of the record.
 
* Description.
 
  
{| class="textbox alt headline grid"
+
{| class="wikitable"
|+ List of Records
+
! Name
! Name !! Record ID !! Length !! Description
+
! Magic
 +
! Length
 +
! Description
 
|-
 
|-
| [[MKWii Network Protocol/CHECKSUM|CHECKSUM]] || <tt>0000.0000</tt> || 0x08
+
| [[SLOT]] || <tt>46.FC.57.0X</tt> || 0x08
| A checksum record used for the most data records.
+
| 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.
 
|-
 
|-
| [[MKWii Network Protocol/SLOT|SLOT]] || <tt>46fc.570x</tt> || 0x08
+
| [[STATUS]] || <tt>BB.49.CC.4D</tt> || &ge; 0x14
| The following message is related to client slot '''x''' (default: for the sender). This is mainly used in combination with ANNOUNCE and USER to tie information to specific client slots.
+
| 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.
If a client has bandwidth problems, it can use another client as proxy to reduce its own traffic during the race. Such indirect packets are also prefixed by a SLOT record.
 
 
|-
 
|-
| [[MKWii Network Protocol/STATUS|STATUS]] || <tt>bb49.cc4d</tt> || 0x14+N
+
| [[HANDSHAKE]] || <tt>FD.FC</tt> || &ge; 0x14
| A status record with 5 different extensions. Byte 0x08 describes the status type. One task is to select and advice client slots to clients.
+
| [[NATNEG]] records. Type CONNECT_PING is sent through peer-to-peer, while all other types are routed through the NATNEG servers.
 
|-
 
|-
| [[MKWii Network Protocol/HANDSHAKE|HANDSHAKE]] || <tt>fdfc</tt> || 0x14+N
+
| [[QUIT]] || <tt>FE.FE.68</tt> || 0x03
| Different handshake records with different length. At the moment, an announce from Nintendo (with ip+port) and a little handshake between host and guest are known.
+
| This record is sent when a client leaves a room. It is not prefixed by a CHECKSUM record.
|-
 
| [[MKWii Network Protocol/QUIT|QUIT]] || <tt>fefe.68</tt> || 0x03
 
| This Record is sent when a client quits a rooms or a race. This record isn't prefixed by a CHECKSUM-Record.  
 
 
|}
 
|}
  
== Stages ==
+
== States ==
 
+
This section describes what data is transmitted between clients during specific stages of gameplay.
Here will be described what data is transmitted by the clients during the different stages of the game. Only peer-to-peer data will be mentioned here, not anything server-related.
 
 
 
=== Room ===
 
 
 
When a player wants to enter a friend room, he sends a "GMCP90"-Message type 1 (Ask for entrance, see server documentation for more details) via MASTER, this will either be answered with type 2 (access granted) or type 3 (denied, room full). When the host allows the new guest to enter, they start doing NATNEG to open a peer-to-peer-connection.
 
 
 
After NATNEG is done, the players start handshaking with a few FEXX-Status-Messages. After exchanging status messages, they send eachother an empty race packet ([MKWii_Network_Protocol/ANNOUNCE|ANNOUNCE]) to indicate the successful connection.
 
 
 
After that, the new player appears in the room and starts doing NATNEG with all the other players. Because NATNEG is very slow and does not run in threads (only one-by-one), only one player can join a room at the same time (others get 86420 after a timeout). This is the reason why starting a match takes a long time when the host starts a match as soon as everyone is in the room - all the peer to peer connections aren't set up yet - which are about 60 connections in a full room.
 
 
 
=== Global match ===
 
 
 
As soon as the client has found a room via MS, it sends a "Asking for entrance"-status message (same as in the room). When the room host is in the friend list, GPCM90-Messages are used. If the host is not in the friend list (more likely), STATUS-messages are being proxied by MS/MASTER.
 
 
 
Then, same as in the room, NATNEG and a few status messages are done.
 
Then, the wii sends an empty record header ([MKWii_Network_Protocol/ANNOUNCE|ANNOUNCE]) to the host and starts sending packets containing an USER record.
 
 
 
During the VIEW phase (you are seeing the other players racing), race packets with only RACEHEADER_1 and EVENT are sent.
 
 
 
=== Event begin ===
 
  
At event begin, the host sends a [[ROOM]]-message to indicate the start of an event. The players select their characters and vehicle, and the track selection starts.  
+
=== 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.
  
The track selection has three phases:
+
After completing NATNEG, the two clients send each other an empty race packet ([[ANNOUNCE]]) to indicate a successful connection.  
Phase 1: SEL/PREPARE: You'll see the string "Preparing race ..." and wait until everyone is ready.
 
Phase 2: SEL/WAITING: You'll see the track selection screen and can choose a track to drive, or you are waiting for others to complete their track choice. At this point, the engine class is already determined.
 
Phase 3: SEL/LOTTERY: Everyone has chosen a track and the lottery begins. As soon as the lottery begins, the winning user and track is already know to all clients.  
 
  
=== Count down ===
+
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.
  
Before count down, the host sends a request "Ready for event?" to all clients. Until all clients have answered "ready!", you'll see the loading icon in the bottom right corner of the screen.
+
==== Worldwide ====
If someone has a broken image or is in a CT room without having CTs, you'll all have to wait until he turns off his wii, as his console won't answer with "ready".  
+
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]].  
  
When the clients are syncronized and all ready for the event, the countdown and the race begins.  
+
Then, similarly to friend rooms, [[NATNEG]] is performed and an empty record ([[ANNOUNCE]]) is exchanged to mark the completion of the handshake.
  
=== Finished ===
+
During live view, only part of the main records are sent.
  
As soon as a player finishes, he sends his final time to all the other players. Now, the other players have 30 seconds left to complete the race (but a race has a minimum time of 2 minutes and a maximum time of 5 minutes).  
+
=== Friend Room Start ===
When the race is finished (either by everyone crossing the finish line, 5 minutes being over or the 30-seconds being reached, the phase "All finished" is activated. You'll see the rankings and the next race will begin.
+
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.
  
== Links ==
+
=== 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.
  
* [[Wiimms mkw-ana (tool)]]
+
=== Race Finish ===
* [http://www.mariokartwii.com/f101/mkw-ana-mario-kart-wii-network-protocol-109421.html Discussion at mariokartwii.com]
+
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.
* [http://forum.wii-homebrew.com/board42-kreativitaet/board329-mkw-server-project-english/ Wiimmfi-Project] (Project to create own MKWii servers)
 
  
<br/>
+
{{Network Protocol}}
{{MKWii Network Protocol}}
+
[[Category:File Format/MKW]]
[[category:File Format]]
+
[[Category:Network Protocol|!]]
[[category:Network Protocol|!]]
 
[[mk8:MK8 Network Protocol]]
 

Latest revision as of 17:15, 28 January 2024

Under Construction
This article is not finished. Help improve it by adding accurate information or correcting grammar and spelling.

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.

Game Features
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:
  • 1: Event start message (GP, Team, Balloon or Coin Battle).
  • 2: A player registered another player as their friend.
  • 3: A player joined the room.
  • 4: Regular room message (online chat).
SELECT 0x38 This record is sent between matches to set up the next race. One byte decides the phase.
  • 0: Match setup.
  • 1: Course selection.
  • 2: Voting lottery.
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.