Difference between revisions of "Network Protocol"
(Cleanup) |
(Redirect cleanup) |
||
Line 83: | Line 83: | ||
== Description == | == Description == | ||
− | The [[Mario Kart Wii]] traffic starts with some name resolutions. Then, it will use TCP connection to the servers and UDP packets for the | + | The [[Mario Kart Wii]] traffic starts with some name resolutions. Then, it will use TCP connection to the servers and UDP packets for the peer-to-peer data transfer. First it connects the N-server ([[Wiimmfi]] server). In a room or while racing, all consoles communicate directly to each other. In a race, only some ''active'' records are send to an N-server. |
=== Connecting to Servers === | === Connecting to Servers === | ||
Line 105: | Line 105: | ||
The [[Wii]] uses a frequency of 59.94Hz ([[NTSC]]) as time base. All clients send a status packet to one of the other clients every second pulse (around 1/30 seconds). For example, when there are three clients A, B and C, then A will send packets to B and C in turn every 1/30 seconds. This means that the individual status update is only done every 1/15 seconds. This update time is reduced to 11/30 seconds when there are 12 clients in a race. This is the main reason for lag when racing with many players. The average packet length is about 220 bytes, so the total traffic is about 8 KB/s in both directions, independent of the number of clients. | The [[Wii]] uses a frequency of 59.94Hz ([[NTSC]]) as time base. All clients send a status packet to one of the other clients every second pulse (around 1/30 seconds). For example, when there are three clients A, B and C, then A will send packets to B and C in turn every 1/30 seconds. This means that the individual status update is only done every 1/15 seconds. This update time is reduced to 11/30 seconds when there are 12 clients in a race. This is the main reason for lag when racing with many players. The average packet length is about 220 bytes, so the total traffic is about 8 KB/s in both directions, independent of the number of clients. | ||
− | == Main records | + | == Main records == |
− | Each UDP packet can be split into records, which are logical units. Sometimes, a packet is prefixed by a [[ | + | Each UDP packet can be split into records, which are logical units. Sometimes, a packet is prefixed by a [[SLOT]] record to reduce a client's needed upload bandwidth. |
=== Header === | === Header === | ||
Line 122: | Line 122: | ||
| 0x08 || 1 byte || Header length. Always 0x10. | | 0x08 || 1 byte || Header length. Always 0x10. | ||
|- | |- | ||
− | | 0x09 || 1 byte || [[ | + | | 0x09 || 1 byte || [[RACEHEADER_1]] record length. Either 0x28 or 0x00 if not present. |
|- | |- | ||
− | | 0x0A || 1 byte || [[ | + | | 0x0A || 1 byte || [[RACEHEADER_2]] record length. Either 0x28 or 0x00 if not present. |
|- | |- | ||
− | | 0x0B || 1 byte || [[ | + | | 0x0B || 1 byte || [[ROOM]] or [[SELECT]] record length. Either 0x04 (if ROOM), 0x38 (if SELECT), or 0x00 if not present. |
|- | |- | ||
− | | 0x0C || 1 byte || [[ | + | | 0x0C || 1 byte || [[RACEDATA]] record length. Either 0x40 (per player) or 0x00 if not present. |
|- | |- | ||
− | | 0x0D || 1 byte || [[ | + | | 0x0D || 1 byte || [[USER]] record length. Either 0xC0 or 0x00 if not present. |
|- | |- | ||
− | | 0x0E || 1 byte || [[ | + | | 0x0E || 1 byte || [[ITEM]] record length. Either 0x08 per player or 0x00 if not present. |
|- | |- | ||
− | | 0x0F || 1 byte || [[ | + | | 0x0F || 1 byte || [[EVENT]] record length. Either variable length or 0x00 if not present. |
|} | |} | ||
− | The CHECKSUM algorithm is described [[ | + | The CHECKSUM algorithm is described [[CHECKSUM|here]]. [[RACE]] records are sent from every client to all other clients during a race including the race preparation. |
=== Packet Structure === | === Packet Structure === | ||
Line 147: | Line 147: | ||
! Description | ! Description | ||
|- | |- | ||
− | | HEADER || 0x10 | + | | [[HEADER]] || 0x10 |
| The packet header described above. | | The packet header described above. | ||
|- | |- | ||
− | | [[ | + | | [[RACEHEADER_1]] || 0x28 |
| Race header. | | Race header. | ||
|- | |- | ||
− | | [[ | + | | [[RACEHEADER_2]] || 0x28 |
| Another race header. | | Another race header. | ||
|- | |- | ||
− | | [[ | + | | [[ROOM]] || 0x04 |
| Room records are only sent in room events. The first byte decides the sub type: | | Room records are only sent in room events. The first byte decides the sub type: | ||
* 0: ''Unknown''. | * 0: ''Unknown''. | ||
Line 164: | Line 164: | ||
* 4: Send room message (online chat). | * 4: Send room message (online chat). | ||
|- | |- | ||
− | | [[ | + | | [[SELECT]] || 0x38 |
| This record is sent while selecting character and track. It is always placed before a [[Network Protocol/USER|USER]] record. One byte decides the phase. | | This record is sent while selecting character and track. It is always placed before a [[Network Protocol/USER|USER]] record. One byte decides the phase. | ||
* 0: Race preparation. | * 0: Race preparation. | ||
Line 170: | Line 170: | ||
* 2: Track selection. | * 2: Track selection. | ||
|- | |- | ||
− | | [[ | + | | [[RACEDATA]] || 0x40 |
| Actual race data. May exist twice if there are two players on one console. | | Actual race data. May exist twice if there are two players on one console. | ||
|- | |- | ||
− | | [[ | + | | [[USER]] || 0xC0 |
| User information including a friend code and 2 Miis for both users of the client. | | User information including a friend code and 2 Miis for both users of the client. | ||
|- | |- | ||
− | | [[ | + | | [[ITEM]] || 0x08 |
| Record indicating the item status. | | Record indicating the item status. | ||
|- | |- | ||
− | | [[ | + | | [[EVENT]] || ≥ 0x18 |
| Record indicating the event status. | | Record indicating the event status. | ||
|} | |} | ||
Line 192: | Line 192: | ||
! Description | ! Description | ||
|- | |- | ||
− | | [[ | + | | [[SLOT]] || <tt>46fc.570x</tt> || 0x08 |
− | | The following message is related to the client slot "X". This is mainly used in combination with [[ | + | | The following message is related to the client slot "X". This is mainly used in combination with [[ANNOUNCE]] and [[USER]] to tie information to specific client slots. If a client has bandwidth problems, it can use another client as a proxy to reduce its own traffic during the race. Such indirect packets are also prefixed by a [[SLOT]] record. |
|- | |- | ||
− | | [[ | + | | [[STATUS]] || <tt>bb49.cc4d</tt> || 0x14+N |
| A status record with five different extensions. Byte 0x08 describes the status type. One task is to select and advice client slots to clients. | | A status record with five different extensions. Byte 0x08 describes the status type. One task is to select and advice client slots to clients. | ||
|- | |- | ||
− | | [[ | + | | [[HANDSHAKE]] || <tt>fdfc</tt> || 0x14+N |
| [[NATNEG]] records. Only CONNECT_PING is sent peer-to-peer, all other records via the server. | | [[NATNEG]] records. Only CONNECT_PING is sent peer-to-peer, all other records via the server. | ||
|- | |- | ||
− | | [[ | + | | [[QUIT]] || <tt>fefe.68</tt> || 0x03 |
| This record is sent when a client quits a room or a race. It is not prefixed by a CHECKSUM record. | | This record is sent when a client quits a room or a race. It is not prefixed by a CHECKSUM record. | ||
|} | |} | ||
Line 211: | Line 211: | ||
When a player wants to enter a friend room, it sends a "GMCP90" type 1 message to the [[MASTER]] server. This asks the server for permission to enter the room, which 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]] requests to open a peer-to-peer-connection. | When a player wants to enter a friend room, it sends a "GMCP90" type 1 message to the [[MASTER]] server. This asks the server for permission to enter the room, which 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]] requests to open a peer-to-peer-connection. | ||
− | After NATNEG is done, the players start [[HANDSHAKE]] with a few FEXX status messages. After exchanging these messages, they send each other an empty race packet ([[ | + | After NATNEG is done, the players start [[HANDSHAKE]] with a few FEXX status messages. After exchanging these messages, they send each other an empty race packet ([[ANNOUNCE]]) to indicate the successful connection. |
After that, the new player appears in the room and starts doing NATNEG with all other players. Because NATNEG is very slow and does not run in threads, only one player can join a room at the same time. 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 have not been set up yet, which are about 60 connections in a full room. | After that, the new player appears in the room and starts doing NATNEG with all other players. Because NATNEG is very slow and does not run in threads, only one player can join a room at the same time. 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 have not been set up yet, which are about 60 connections in a full room. | ||
Line 219: | Line 219: | ||
Then, same as in the room, NATNEG and a few status messages are done. | Then, same as in the room, NATNEG and a few status messages are done. | ||
− | The Wii then sends an empty record header ( | + | The Wii then sends an empty record header (ANNOUNCE) to the host and starts sending packets containing a user record. |
During the viewing phase, race packets with only [[RACEHEADER_1]] and [[EVENT]] are sent. | During the viewing phase, race packets with only [[RACEHEADER_1]] and [[EVENT]] are sent. | ||
=== Start of Event === | === Start of Event === | ||
− | At event begin, the host sends a [[ | + | 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. The track selection has three phases. |
− | # | + | # SELECT/PREPARE - The waiting screen until all consoles are ready. |
− | # | + | # SELECT/WAITING - The track selection screen and waiting until everyones has voted for a track. |
− | # | + | # SELECT/LOTTERY - The roulette that determines the track. This is already determined before it starts. |
=== Countdown === | === Countdown === |
Revision as of 18:38, 29 April 2023
Overview
This article describes the network protocol used by Mario Kart Wii.
Terminology
The following terms are used in this article.
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 the race. |
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 of the race, with a maximum of 12. Players are all users of all clients. |
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 is used in the network protocols for identification. |
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. |
UPD | User Datagram Protocol, a network protocol. |
User | A user of a client. Each client supports 1 or 2 users. The users of the client are numbered 1 and 2. |
Description
The Mario Kart Wii traffic starts with some name resolutions. Then, it will use TCP connection to the servers and UDP packets for the peer-to-peer data transfer. First it connects the N-server (Wiimmfi server). In a room or while racing, all consoles communicate directly to each other. In a race, only some active records are send to an N-server.
Connecting to Servers
When connecting to the Nintendo Wi-Fi Connection, the console starts with DNS queries to locate 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
The Wiimmfi equivalents are the same servers with "nintendowifi.net" replaced with "wiimmfi.de". Then it starts the communication with the servers and the first packet goes to mariokartwii.available.gs.nintendowifi.net. More details about the servers can be found here.
Point to Point Communication
The Wii uses a frequency of 59.94Hz (NTSC) as time base. All clients send a status packet to one of the other clients every second pulse (around 1/30 seconds). For example, when there are three clients A, B and C, then A will send packets to B and C in turn every 1/30 seconds. This means that the individual status update is only done every 1/15 seconds. This update time is reduced to 11/30 seconds when there are 12 clients in a race. This is the main reason for lag when racing with many players. The average packet length is about 220 bytes, so the total traffic is about 8 KB/s in both directions, independent of the number of clients.
Main records
Each UDP packet can be split into records, which are logical units. Sometimes, a packet is prefixed by a SLOT record to reduce a client's needed upload bandwidth.
Header
After SLOT (if it exists), the main race header (16 bytes) is as follows.
Offset | Size | Description |
---|---|---|
0x00 | 4 bytes | Start of checksum part. Always 0x0000 0000. |
0x04 | 4 bytes | Checksum record. |
0x08 | 1 byte | Header length. Always 0x10. |
0x09 | 1 byte | RACEHEADER_1 record length. Either 0x28 or 0x00 if not present. |
0x0A | 1 byte | RACEHEADER_2 record length. Either 0x28 or 0x00 if not present. |
0x0B | 1 byte | ROOM or SELECT record length. Either 0x04 (if ROOM), 0x38 (if SELECT), or 0x00 if not present. |
0x0C | 1 byte | RACEDATA record length. Either 0x40 (per player) or 0x00 if not present. |
0x0D | 1 byte | USER record length. Either 0xC0 or 0x00 if not present. |
0x0E | 1 byte | ITEM record length. Either 0x08 per player or 0x00 if not present. |
0x0F | 1 byte | EVENT record length. Either variable length or 0x00 if not present. |
The CHECKSUM algorithm is described here. RACE records are sent from every client to all other clients during a race including the race preparation.
Packet Structure
The following table shows the packet structure and the different records.
Name | Length | Description |
---|---|---|
HEADER | 0x10 | The packet header described above. |
RACEHEADER_1 | 0x28 | Race header. |
RACEHEADER_2 | 0x28 | Another race header. |
ROOM | 0x04 | Room records are only sent in room events. The first byte decides the sub type:
|
SELECT | 0x38 | This record is sent while selecting character and track. It is always placed before a USER record. One byte decides the phase.
|
RACEDATA | 0x40 | Actual race data. May exist twice if there are two players on one console. |
USER | 0xC0 | User information including a friend code and 2 Miis for both users of the client. |
ITEM | 0x08 | Record indicating the item status. |
EVENT | ≥ 0x18 | Record indicating the event status. |
Additional Records
The following table shows additional records.
Name | Record ID | Length | Description |
---|---|---|---|
SLOT | 46fc.570x | 0x08 | The following message is related to the client slot "X". This is mainly used in combination with ANNOUNCE and USER to tie information to specific client slots. If a client has bandwidth problems, it can use another client as a proxy to reduce its own traffic during the race. Such indirect packets are also prefixed by a SLOT record. |
STATUS | bb49.cc4d | 0x14+N | A status record with five different extensions. Byte 0x08 describes the status type. One task is to select and advice client slots to clients. |
HANDSHAKE | fdfc | 0x14+N | NATNEG records. Only CONNECT_PING is sent peer-to-peer, all other records via the server. |
QUIT | fefe.68 | 0x03 | This record is sent when a client quits a room or a race. It is not prefixed by a CHECKSUM record. |
Stages
This section describes what peer-to-peer data is transmitted by the clients during the different stages of a match.
Room
When a player wants to enter a friend room, it sends a "GMCP90" type 1 message to the MASTER server. This asks the server for permission to enter the room, which 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 requests to open a peer-to-peer-connection.
After NATNEG is done, the players start HANDSHAKE with a few FEXX status messages. After exchanging these messages, they send each other an empty race packet (ANNOUNCE) to indicate the successful connection.
After that, the new player appears in the room and starts doing NATNEG with all other players. Because NATNEG is very slow and does not run in threads, only one player can join a room at the same time. 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 have not been set up yet, which are about 60 connections in a full room.
Match
As soon as the client has found a room via MS, it sends an "asking for entrance" status message. When the room host is in the friend list, GPCM90 messages are used. If the host is not in the friend list, STATUS messages are being proxied by MS and/or MASTER.
Then, same as in the room, NATNEG and a few status messages are done. The Wii then sends an empty record header (ANNOUNCE) to the host and starts sending packets containing a user record.
During the viewing phase, race packets with only RACEHEADER_1 and EVENT are sent.
Start of Event
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. The track selection has three phases.
- SELECT/PREPARE - The waiting screen until all consoles are ready.
- SELECT/WAITING - The track selection screen and waiting until everyones has voted for a track.
- SELECT/LOTTERY - The roulette that determines the track. This is already determined before it starts.
Countdown
Before the countdown, the host sends a "ready?" request to all clients. Until all clients have answered this, the loading icon appears in the bottom right corner of the screen. When the clients are syncronized and all ready for the event, the countdown and the race begins.
Finish
As soon as a player finishes, he sends his final time to all the other players. Then the other players have 30 seconds left to complete the race, given that the track-specific minimum time race length has been completed. When the race is finished by either everyone crossing the finish line, 5 minutes being over, or the 30 seconds being reached, the "finished" phase is activated. The rankings will show and the next race will begin.
Links
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