Wiimmfi/Connection Status

Peer-to-peer connection

All Wii and NDS games use the server only for login, matchmaking and as delivery agent for messages. Gaming data is sent peer-to-peer. The problem is, that the clients usually live behind a router with NAT (Network Address Translation). This client can't send messages and can't connect without help of a server. And this is the reason for NATNEG (NAT NEGotiation).

For Mario Kart Wii the connection goes like this:

A guest searches a host in the matchmaking table using a TCP connection to server MS.
The guest tries to connect the host. It uses either server GPCM, if the host is known as friend, or server MS otherwise as delivery agent. STATUS packets are used for the communication. The servers are able to interpret these packets.
After the guest gets the permission to enter the room, a peer-to-peer connection will be established:
1. A random NATNEG-ID is exchanged.
2. Host and guest send records to the server NATNEG.
3. If server NATNEG received both messages, it sends back a CONNECT message to both clients. The message contains the IPv4 address and the open port of the opponent.
4. Each client sends back a CONNECT_ACK message to the server to confirm the CONNECT message.
5. After establishing the peer-to-peer connection, each client reports SUCCESS.

Local net

For a local network, the communication of both clients is done directly without using any server as delivery agent.

Connection Status (bit fields)

The Connection Status is a special feature of Wiimmfi. Server SV collects data from GPCM, MS, MASTER and NATNEG and creates 6 bit fields for each room member:

LOCAL: A bit is set, if 2 players have the same public IPv4. In this case, both clients use the same LAN and NATNEG is usually not needed. The bits are always set for both peers.
CONNECT2: A bit is set, if connection was accepted by the host. In this case, the host sends a "GPCM STATUS type-02" message using server GPCM or MS as delivery agent. The bits are always set for both peers.
NN_CONNECT: The NATNEG server sent a CONNECT message (NATNEG connection finished) to both clients. The bits are always set for both peers.
NN_ACK: The NATNEG server received a CONNECT_ACK message of a client.
NN_SUCCESS: The NATNEG server received a REPORT message of a client with status SUCCESS. If the status is FAIL, then the related bits in NN_CONNECT and NN_ACK are cleared.
CLIENT: The client confirmed a connection. All other bits except LOCAL are ignored.

The slot index is used for the bit number. If for example players at slot 2 and 5 did NN_CONNECT, then bit 5 for player 2 and bit 2 for player 5 are set. If a player left a room (detected by GPCM or MASTER), all slot related bits are cleared.

Visualization

Server SV and mkw-ana print a summary as a character vector. The connection status is also visible at the MKW status page. The following table shows the character and color selection, highest priority first:

char

description

\

Self reference and mirror line. All other bits are ignored.

Δ

Client confirmed connection (NATNEG used). All other bits are ignored.

○

Client confirmed connection (local network). All other bits are ignored.

▪

NN_SUCCESS and CONNECT2 are set. LOCAL is ignored.

.

NN_SUCCESS set, but not CONNECT2. LOCAL is ignored.

A

NN_ACK and CONNECT2 are set. LOCAL is ignored.

a

NN_ACK set, but not CONNECT. LOCAL is ignored.

C

NN_CONNECT and CONNECT2 are set, but not NN_ACK. LOCAL is ignored.

c

NN_CONNECT set, but neither NN_ACK nor CONNECT2. LOCAL is ignored.

L

LOCAL and CONNECT2 set, but not any NATNEG flag.

l

LOCAL set, but neither CONNECT nor any NATNEG flag.

2

CONNECT2 set, but neither LOCAL nor any NATNEG flag.

▲

All bits are cleared (not any connection).

Examples:

Connection Issues

If a player enters a room, it starts with a row (and also a column) of red triangles. Each red triangle tells us, that the pair of clients has not established the peer-to-peer connection. For this case, the traffic is redirected through a proxy for both directions. Usually (but not always) the host is the proxy. And if a player is the proxy for many connections, it needs much more upload bandwidth than usual. The result may be loss of packets so that players see others jumping. Usually, every 7 seconds a NATNEG is completed and a red triangle is exchanged by a cyan rectangle. But for unknown reasons (a MKW bug), some clients stop the NATNEG process. And so, the red row stays.

A solution for the moment and only for private rooms is, that the room owner kicks the players from his room, if they have many red triangles.

It is planned to calculate a goodness value, show this value at the status page and also archive it in race and kick histories. Later with more experience, an auto-kick feature for red players is planned.

Column »conn fail«

Column »conn fail« shows a connection failure rating. Each missed step counts as 0.25 (4 steps for a complete connection). So a complete missed connection counts as 1.00.

The connection failure rating of a room is calculated by adding the squares of the single ratings, and then getting the square root. So one 4.0 rating (room rating 4.0) counts more than four 1.0 ratings (room rating 2.0).

Network Protocol

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