Difference between revisions of "Network Protocol"

From Custom Mario Kart
Jump to navigation Jump to search
(General cleanup)
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 used in the article:
  
{{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.}}
+
;ARP: [http://en.wikipedia.org/wiki/Address_Resolution_Protocol Address Resolution Protocol], a network routing protocol.
 
+
;cfc : The console friend code. It is displayed as 16 digits using format ''''xxxx-xxxx-xxxx-xxxx'''.
 
+
;client : A Wii system that take part of the race.
== Introduction ==
+
;fc, fc8 : The [[friend code]] (8 bytes = 64 bits) of the first user of a client. Sometimes a friend code 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 : [[GPCM|Client server]].
The analysis of the data is done with the tool
+
;GPSP : [[GPSP|Server to retrieve friends]].
[[Wiimms mkw-ana (tool)|mkw-ana]]. So the naming of mkw-ana for objects
+
;guest : All non host clients.
(records, stages, ...) is used here.  
+
;home-client : The observed client (client, where the network traffic comes from).
Because of the very early phase of the analysis,
+
;host : The client, which has opened the room.
names and structures may completely change.
+
;MASTER : [[MASTER|Master matchmaking server]].
 
+
;mii : The Mii avatar of a user.
You can discuss this topic at [http://forum.wii-homebrew.com/board42-kreativitaet/board329-mkw-server-project-english/ Wii-Homebrew.com] (English and German).
+
;MS : [[MS|Matchmaking retrieving server]].
 
+
;N-server : One of [[Network Protocol/Server|Nintendos servers]].
=== Terms and definition ===
+
;NAS, NASWII : [[NAS|Login server]].
 
+
;NATNEG : [[NATNEG|Server to enable client-to-client connections]] behind firewalls. The name '''NATNEG''' is a combination of '''NAT''' ('''N'''etwork '''A'''ddress '''T'''ranslation) and '''NEG''' ('''NEG'''otiation).
{{Network Protocol Terms}}
+
;packet : A packet is a technical network packet. [[Mario Kart Wii]] uses ARP, TCP and UDP (including name resolution) packets.
 
+
;player : A player, that take part of the race (max=12). Players are all users of all clients.
== General description ==
+
;player id : 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 : [http://en.wikipedia.org/wiki/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 : [http://en.wikipedia.org/wiki/User_Datagram_Protocol User Datagram Protocol], a network protocol.
 +
;user : A user of a client. Each client supports 1 or 2 users. The users of  client are numbered 1 and 2.
  
 +
== Description ==
 
The [[Mario Kart Wii]] traffic starts with some name resolutions.
 
The [[Mario Kart Wii]] traffic starts with some name resolutions.
 
Then it will use TCP connection to the servers and UDP packets for the p2p data transfer.
 
Then it will use TCP connection to the servers and UDP packets for the p2p data transfer.
Line 31: Line 40:
  
 
=== Connecting the Wiimmfi-Server(s) ===
 
=== Connecting the Wiimmfi-Server(s) ===
 
+
When entering the [[Nintendo Wi-Fi Connection]], the console starts with DNS queries to locate the IP addresses of the following servers:
When entering the Mario Kart WFC, the Wii starts with DNS queries to find out the IP addresses of the following servers:
 
 
* gpcm.gs.nintendowifi.net
 
* gpcm.gs.nintendowifi.net
 
* gpsp.gs.nintendowifi.net
 
* gpsp.gs.nintendowifi.net
Line 62: Line 70:
  
 
== Main records ("RACE" records) ==
 
== Main records ("RACE" records) ==
 +
Each UDP packet can be split in records. Records are logical units. A race packet consists of records. Sometimes, a packet is prefixed by a [[Network Protocol/SLOT|SLOT]]-record to reduce a client's needed upload bandwidth.
  
Each UDP packet can be split in records. Records are logical units.
+
=== Header ===
 
 
A race packet consists of records. Sometimes, a packet is prefixed by a [[Network Protocol/SLOT|SLOT]]-record to reduce a client's needed upload bandwidth.
 
 
 
 
After SLOT (if it exists), the main race header (16 byte) follows:  
 
After SLOT (if it exists), the main race header (16 byte) follows:  
  
<pre>typedef struct header_t
+
{| class="wikitable"
{
+
! Offset
/*00*/  u32   checksum_start        // always 0x0000 0000 (start of checksum part)
+
! Type
/*04*/  u32   checksum              // Checksum record
+
! Description
/*08*/  u8 header_len;          // always 0x10 (length of this header)
+
|-
/*09*/  u8     raceheader1_len;      // length of the first race header. 0x28 or 0x00
+
| 0x00 || u32 || always 0x0000 0000 (start of checksum part)
/*0a*/  u8     raceheader2_len;      // length of the 2nd race header. 0x28 or 0x00
+
|-
/*0b*/  u8     room_select_len;      // length of the ROOM or SELECT record. 0x04 (for room), 0x38 (for select), or 0x00
+
| 0x04 || u32 || Checksum record
 
+
|-
/*0c*/  u8     racedata_len;        // length of RACEDATA. 0x40 (for 1 player), 0x80 (for 2 players) or 0x00
+
| 0x08 || u8 || always 0x10 (length of this header)
/*0d*/  u8     user_len;            // length of USER. 0xc0 or 0x00
+
|-
/*0e*/  u8     item_len;            // length of ITEM. 0x08 (for 1 player), 0x10 (for 2 players) or 0x00
+
| 0x09 || u8 || length of the first race header. 0x28 or 0x00
/*0f*/  u8     event_len;            // length of EVENT. 0x00, or >= 0x18
+
|-
 
+
| 0x0a || u8 || length of the 2nd race header. 0x28 or 0x00
/*10*/
+
|-
}
+
| 0x0b || u8 || length of the ROOM or SELECT record. 0x04 (for room), 0x38 (for select), or 0x00
__attribute__ ((packed)) header_t;</pre>
+
|-
 +
| 0x0c || u8 || length of RACEDATA. 0x40 (for 1 player), 0x80 (for 2 players) or 0x00
 +
|-
 +
| 0x0d || u8 || length of USER. 0xc0 or 0x00
 +
|-
 +
| 0x0e || u8 || length of ITEM. 0x08 (for 1 player), 0x10 (for 2 players) or 0x00
 +
|-
 +
| 0x0f || u8 || length of EVENT. 0x00, or >= 0x18
 +
|}
  
 
(The CHECKSUM algorithm is described here: [[Network Protocol/CHECKSUM|CHECKSUM]])
 
(The CHECKSUM algorithm is described here: [[Network Protocol/CHECKSUM|CHECKSUM]])
Line 91: Line 105:
 
RACE records are send from every client to all other clients during a race including the race preparation.
 
RACE records are send 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, including:
 
The following table shows the packet structure and the different records, including:
 
* A name used by [[mkw-ana]].
 
* A name used by [[mkw-ana]].
Line 113: Line 127:
 
| The first byte decides the sub type:
 
| The first byte decides the sub type:
 
* '''0:''' ''unknown''
 
* '''0:''' ''unknown''
* '''1:''' Send by host: Start an event (GP, Team, Ballon or Coin).
+
* '''1:''' Send by host: Start an event (GP, Team, Balloon or Coin).
 
* '''2:''' ''unknown''
 
* '''2:''' ''unknown''
 
* '''3:''' ''unknown''
 
* '''3:''' ''unknown''
Line 188: Line 202:
 
=== Event begin ===
 
=== 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.  
+
At event begin, the host sends a [[Network Protocol/ROOM|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: <br/>
 
The track selection has three phases: <br/>
Line 209: Line 223:
 
== Links ==
 
== Links ==
 
* [[Wiimms mkw-ana (tool)]]
 
* [[Wiimms mkw-ana (tool)]]
 +
* [https://forum.wii-homebrew.com/index.php/Board/329-Wiimmfi-Project Wii-Homebrew.com]
 +
* [[mk8:MK8 Network Protocol|MK8 Network Protocol]]
  
 
{{Network Protocol}}
 
{{Network Protocol}}
 
[[Category:File Format/MKW]]
 
[[Category:File Format/MKW]]
 
[[Category:Network Protocol|!]]
 
[[Category:Network Protocol|!]]
[[mk8:MK8 Network Protocol]]
 

Revision as of 12:15, 29 April 2023

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 used in the article:

ARP
Address Resolution Protocol, a network routing protocol.
cfc
The console friend code. It is displayed as 16 digits using format 'xxxx-xxxx-xxxx-xxxx.
client
A Wii system that take part of the race.
fc, fc8
The friend code (8 bytes = 64 bits) of the first user of a client. Sometimes a friend code 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
Client server.
GPSP
Server to retrieve friends.
guest
All non host clients.
home-client
The observed client (client, where the network traffic comes from).
host
The client, which has opened the room.
MASTER
Master matchmaking server.
mii
The Mii avatar of a user.
MS
Matchmaking retrieving server.
N-server
One of Nintendos servers.
NAS, NASWII
Login server.
NATNEG
Server to enable client-to-client connections behind firewalls. The name NATNEG is a combination of NAT (Network Address Translation) and NEG (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 take part of the race (max=12). Players are all users of all clients.
player id
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.
UDP
User Datagram Protocol, a network protocol.
user
A user of a client. Each client supports 1 or 2 users. The users of 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 p2p data transfer.

First it connects the Wiimmfi server (N-server). In a room or while racing, all Wiis communicate directly to each other. In a race, only some alive records are send to a N-server.

Connecting the Wiimmfi-Server(s)

When entering 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

("nintendowifi.net" replaced with "wiimmfi.de" for the Wiimmfi server)

Then it starts the communication with the servers and the first packet goes to mariokartwii.available.gs.nintendowifi.net.

More Details about the servers

Point to point communication

The Wii uses a frequency of 59.94Hz (based on NTSC, about 1/60s) as time base. All clients send a status packet to one of the other clients every second pulse (~1/30s). 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.

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 ("RACE" records)

Each UDP packet can be split in records. Records are logical units. A race packet consists of records. 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 byte) follows:

Offset Type Description
0x00 u32 always 0x0000 0000 (start of checksum part)
0x04 u32 Checksum record
0x08 u8 always 0x10 (length of this header)
0x09 u8 length of the first race header. 0x28 or 0x00
0x0a u8 length of the 2nd race header. 0x28 or 0x00
0x0b u8 length of the ROOM or SELECT record. 0x04 (for room), 0x38 (for select), or 0x00
0x0c u8 length of RACEDATA. 0x40 (for 1 player), 0x80 (for 2 players) or 0x00
0x0d u8 length of USER. 0xc0 or 0x00
0x0e u8 length of ITEM. 0x08 (for 1 player), 0x10 (for 2 players) or 0x00
0x0f u8 length of EVENT. 0x00, or >= 0x18

(The CHECKSUM algorithm is described here: CHECKSUM)

RACE records are send 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, including:

  • A name used by mkw-ana.
  • Data length
  • Description.
List of Records
Name Length Description
HEADER 0x10 The packet header described above
RACEHEADER_1 0x28 Race header
RACEHEADER_2 0x28 Another race header
ROOM 0x04 The first byte decides the sub type:
  • 0: unknown
  • 1: Send by host: Start an event (GP, Team, Balloon or Coin).
  • 2: unknown
  • 3: unknown
  • 4: Send a room message (online chat).

Room records are only sent in room events.

SELECT 0x38 This record is sent while selecting driver and track. It is always placed before an USER record. One byte decides the phase:
  • 0: Prepare the race.
  • 1: Before first race: Driver selection. All races track selection by user.
  • 2: Track lottery. Before start of the lottery, the host sends to all clients the winning user and track.
RACEDATA 0x40 Actual race data. May exist twice if there are two players on one console.
USER 0xc0 A user information including a FC 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:

  • A name used by mkw-ana.
  • Value of the first 2-4 bytes (Record ID, big endian, hex).
  • Length of the record.
  • Description.
List of Records
Name Record ID Length Description
SLOT 46fc.570x 0x08 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.

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.

STATUS bb49.cc4d 0x14+N 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 fdfc 0x14+N NATNEG records. Only "CONNECT_PING" is send peer-to-peer, all other records via server: Natneg.
QUIT fefe.68 0x03 This Record is sent when a client quits a rooms or a race. This record isn't prefixed by a CHECKSUM-Record.

Stages

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 (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. The wii then sends an empty record header (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.

The track selection has three phases:
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.

Countdown

Before countdown, 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.
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".

When the clients are syncronized and all ready for the event, the countdown and the race begins.

Finished

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). 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.

Links