Wiimm saved all of his network dumps together with videos of the races for later analysis. This was a good decision and helped a lot when developing Wiimmfi.
mkw-ana is a hex dumper, that can identify different packet types and split them into different sub-records. Known values are printed in user-friendly formats instead of simple hex numbers.
Leseratte was already involved in the mkw-ana development and helped in many ways to develop Wiimmfi. By a few days we had created a master plan:
So Wiimm developed a retrieving tool that asked the GameSpy servers for the nicknames. A problem was that GameSpy only sends back the nicknames of friends. So the tool asks for friends, and then for friends of the friends, and so on.
The tool run until GameSpy server shutdown in June 2016. By the time it was shutdown, about 2.9 million nicknames for different Wii and NDS games were retrieved.
At this day Wiimm started with the development of the Wiimmfi Portal as an information centre.
The patcher created 3 images that share a new savegame. The images are for Nintendo WFC, Wiimmfi and AltWFC. So it was possible to use all 3 servers and compare dumps. The first profiles were created at Nintendo WFC and imported to Wiimmfi.
In the following 2 weeks we (the tester team) made many tests with many dumps and Wiimmfi was improved step by step. Sometimes the testers had to wait 15 to 30 minutes for a server update and the next test.
At the beginning of this phase we used the NATNEG server, created by Nagato (written in python). All other servers were written in PHP. The standalone servers (= not web servers) used a tool named NCAT (a NETCAT variant) as the main server, and a PHP script for each instance.
And so Wiimm had written a new NATNEG server in C. It supports a communication channel to accept jobs for faked UDP packets. The MS server used this channel. Another advantage is that the standalone NATNEG server doesn't need a database as all protocol data is stored in an internal memory array.
In the following days we tested much, and improved the server step by step.
The Wiimmfi portal allows users to login and to manage their consoles and profiles. It also has support for a per-user rights system and was a base for the later ban system. A valid account at Wii-Homebrew.com is needed for login, as it shares a database with Wiimmfi.
OPENHOST was ready to use.
Two days later is was possible to reactivate old profiles via the portal.
For each error code, a list with class and error description is printed. For some codes, solutions to fix the error are also offered.
Server SV (SuperVisor) is connected to the other servers NATNEG, MASTER+MS and to each instance of GPCM. It collects status data and observes connections and disconnections. With this information, server SV is able to create a very exact room model and can also determine race starts.
The old status page is available as mkw0.
There are many advantages with the new server:
mkw-ana is also able to send kick and ban requests to the JOB server. After checking rights of the user sending the requests, JOB will execute the job and thus kick or ban the player in question.
If you wish to test the backend, try the tool mkw-ana. It supports the same backend as the Wiimmfi servers, but with other commands.
Wiimm implemented the watchdogs, because the MASTER+MS crashed on an attack with invalid packets and we had to restart it manually. From the watchdog implementation, until July 2016, only one watchdog-restart for the MASTER is counted.
The combination of both servers into one process reduces the database lookups and queries again. Additionaly, the MS can now send messages as MASTER directly without using NATNEG as delivering agent.
SAKE is used by the games to share user-created content like ghosts and Miis in Mario Kart Wii or friend lists in Wii Speak Channel.
RACE is a Mario-Kart-specific server used to manage the in-game rankings of tracks and competitions.
NCAT is used as network server in combination with Wiimmfi's PHP scripts. For each connection (TCP/IP) or packet (UDP/IP), a new sub-process is created to manage the single connection or packet. So we have an own independent instance for each network client.
It was a solution to have a stable and well tested server without the need to develop and test such a management server. And when an instance crashes, it had no impact to the NCAT server or the other instances. A disadvantage is that a new sub-process is created for each network client, using more processing power.
NCAT can also used for non-interactive connections to the backends of servers. It allows a script to send commands to the servers and to collect the output.
The NAS server is written as a PHP script, run by an Apache web server. The devices send their request for authentication as POST data, and NAS replies in the usual way.
On login NAS checks parameters, maintenance mode and login restrictions like disabled games or bans. It also manages new consoles and new profiles. Login data needed by the other servers is stored into the database.
At Wiimmfi, the GPCM is a combination of NCAT and PHP scripts. NCAT is the server and creates an own PHP instance for each connecting client. So each GPCM process manages exactly one client.
GPCM uses UNIX sockets for communication. The communication is needed to deliver messages between the clients (client → own GPCM → friend GPCM → friend client) and from and to other servers. The MASTER server is informed about logins and logouts for an optimized management.
A main server (supervisor) manages all external connections and creates a sub-process for new clients. Each sub-process can handle any number of clients; the limit is changeable at runtime. If the limit set to NULL, the supervisor manages all clients by itself. So a single process and a multi process server is available. The single process is faster, but the multi process is more efficient and stable if one process terminates unexpectedly. So the multiprocess method was preferred at the beginning.
Each sub-process communicates with the supervisor using an unnamed socket to exchange status messages and to deliver file descriptors of clients. The supervisor redirects messages for other clients to the sub-processes. This is very fast. After sending a PING from the supervisor's backend to a sub-process the answer arrives in 50–100 microseconds. In this time the message is queued and send, the sub-process is woken up and the message received and analysed, a reply is queued and send, the supervisor is woken up and the message received and analysed and last not least a summary is printed at the backend.
The supervisor collects status data of all clients. So the supervisor knows all relevant data for statistics. It would be possible to follow all connections and disconnections of guests and hosts to create better status pages.
Data transfer with the servers MASTER and JOB is done by SEQPACKET connections. SEQPACKET is only available for UNIX sockets, and is a network stream (like TCP) with record support (like UDP). Once connected, the connection is only closed if one server is halted. At restart, the connections are established again.
GPCM allows push messages to MASTER and JOB for status changes of profiles. A test version of the JOB server already uses this to deliver some status values to mkw-ana.
The new GPCM supports a backend like the other C servers. It is available for the supervisor via such backend, and can be used to send commands to each sub-process.
OPENHOST is already implemented, but has some small issues. It needs more tests.
We tested the new GPCM at the Wiimmfi test server in March and April. Therefore, MKW Intermezzos were patched to use the test server. Overall, the new GPCM must be tested more intensively.
At the moment, the new GPCM runs as server SV (SUPERVISOR).
Another point is the gpcm-to-gpcm communication. Before SV, each GPCM opens a UNIX stream socket of other GPCM to deliver status messages. With the new SV, the GPCM use only one UNIX stream socket and use SV as delivery agent. Also MASTER use SV as delivery agent to e.g. kick a player.
At Wiimmfi, GPSP is implemented as a combination of NCAT and PHP scripts. NCAT is the server and creates an own instance for each connection. Usually, a connection is closed within a second.
In the beginning, MASTER was inplemented as a PHP script. A NCAT server creates a client for each TCP/UDP packet, which results in a very low performance. The MASTER was the most database-querying server of Wiimmfi.
Very early Wiimm decided that the MASTER is the first server to be rewritten. In June 2014 he started with the development of the C server. At July 5, 2014 it replaced the old multiprocess NCAT+PHP version.
The next step was the integration of the MS server into the MASTER code. At the end of 2014 a first version was implemented and running at the test server. It took a long time until all issues are solved. So it was activated at Wiimmfi in January 2016. The combination of both servers into one process reduces the database lookups and queries even further.
The MASTER+MS is now fully implemented. Only special game specific features will be added if needed.
At Wiimmfi, MS was implemented as an NCAT and PHP script combination. NCAT is the server and creates an own instance for each connection. Usually, a connection is closed within 5 seconds.
In August 2014, Wiimm had rewritten the MS to solve different problems.
In January 2016, the PHP version was replaced by a combined MASTER+MS server written in C. The combination of both servers into one process reduces the database lookups and queries again and allows to implement special game specific features.
When playing with other players, the clients (games) must create a client-to-client connection to exchange game data. Because of firewalls and network address translations (NAT) a server must be used to open the gates. And this server is NATNEG.
At the beginning of the development, Wiimmfi used the NATNEG server of Nagato written in python, using an SQLite database.
Two weeks before official Wiimmfi start, Wiimm finished his own NATNEG server written in C. It is a standalone NATNEG server and doesn't need a database, because all protocol data is stored in an internal memory array. It also supports 2 UNIX sockets: One for the delivering of faked UDP packets and one for maintenance. The maintenance port accepts commands and sends back the output. NCAT can be used to establish the bidirectional connection.
Since June 2015, there are 3 instances of NATNEG at 3 different servers. In December 2015 the new backend and the restart feature were implemented. Since January 2016, watchdog will restart NATNEG after a crash; but a crash never happened.
Mid-2015, Leseratte used the AltWFC SAKE server to understand how basic data storage worked, and implemented bugfixes and additional features needed by Mario Kart Wii.
In March 2016, Wiimm and Leseratte reimplemented the SAKE server with all its improvements in PHP in order to use it on Wiimmfi, run by an Apache web server.
The first test implementation in Python has been written by Leseratte in mid-2015, and in March 2016, at the same time as the SAKE server, it has been reimplemented in PHP by Wiimm and Leseratte, run by an Apache web server.
All the details and protocols needed for competitions were found out by Leseratte with some help by PokeAcer. Leseratte has then developed the server software needed to deliver the competitions to the Wiis, and has also improved and updated amibus first test patcher so that it now uploads old competition data to Wiimmfi and permanently patches the Wii competition download to the Wiimmfi servers.
The competition service has been developed from January 2016 to June 2016, with the first competition starting on May 10th. The server then moved from Leserattes development server to the actual Wiimmfi server in July. The PHP scripts of COMPETITION are run by an Apache web server.
mkw-ana connects to the JOB server to get information about the current room and its players. It also sends kick and ban jobs. Special rights at the Wiimmfi server are needed for such kick and ban jobs.