Wiimmfi/Connection Status

The Connection Status is a special feature of Wiimmfi. Server SV collects data from GPCM, MS, MASTER and NATNEG and creates 5 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 hosts 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.

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 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.
▪	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 hasn't 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 proxy for many connections, it needs much more upload bandwidth than usual. The result may be lost 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 an 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.