Daytona USA 2001

Info

Daytona USA uses a Sega networking package made by DWANGO called IWANGO. This consists of two libraries; Lobby Engine and Net Engine.

The lobby engine library is used to facilitate clients connecting to a central server; handle management, players joining and creating lobbies, and the formation of teams and groups.
It also enables player chat and search. Finally it helps a game developer get the information needed to start a session using the Net Engine.

The net engine library is what actually does the multiplayer game aspect of the package. It can run in both P2P and Client/Server configuration. It supports a maximum of 16 players (though the
software developer could cap it, like how Datona only uses 4) and provides two functions for the developer to send/receive data between clients in the session. It is up to the developer
though to handle the networking logic… NE only provides the transfer and session mechanism.

Servers

The lobby server consists of two main components:

  • Access or Gate Server: The entry point for Dreamcast gates. This is a TCP server on port 9500. Sadly most Iwango games hard code the IP into the binary and do not use domain names. Daytona USA 2001 is the exception in the US and EU though, as the ip was stored in a "keyfile" which means the game does not need patching. Once connected the user can manage their handles and join a lobby server. During the initial handshake, a list of lobby servers and their IP/Ports are provided.
  • Lobby Server: This handles all the lobby, team, chat, and game launch management. It can run on any TCP port as the Access Server sends the address to connect to on login.
  • Game Server: Unknown as Daytona USA does not use this. It's used by the Net Engine to facilitate a client/server system; probably for MMOs like Rune Jade.

Protocol

Access Server

The access server is mainly string driven and each requests is done on a separate connection, like a web server.

--- Server -> Client ---
Int16: Packet size - Excludes this 16bit value.
Int16: Opcode - Response to a client request.
String: Packet data
--- Client -> Server ---
Int16: Packet size - Excludes this 16bit value.
String: Packet data

Possible requests are:

REQUEST_FILTER: Filters based on the "commodityId" (Game's UID) a list of lobby servers. Daytona does not provide one in the US/EU versions.
HANDLE_LIST_GET: Gets handles for the given Dricas/SegaNet user.
HANDLE_ADD: Adds a new handle.
HANDLE_REPLACE: Replaces a handle with a new one (not used in Daytona).
HANDLE_DELETE: Deletes a handle.

Lobby Server

--- Server -> Client ---
Int16: Packet size - Excludes this 16 bit value.
Int16: Opcode -  The command the server wants to do.
Buffer: The packet data
--- Client -> Server ---
Int16: Packet size - Excludes this 16 bit value.
Int16: Unknown - Most likely a source/target identifier. Set on initial login.
Int16: Sequence - Every time a packet is sent, this value goes up by one.
Int16: Unknown - Most likely a source/target identifier. Set on initial login.
Int16: Opcode - The command the client wants to do.
Buffer: The packet data.

Payloads are mostly string text, separated by spaces. Sometimes byte data is also jammed in though.

The Key File

While in Japan the Iwango Servers used the DRICAS system for authentication (think PSN or Xbox Live), the US and EU did not have such a system in place. To solve the issue; Sega had people download a "keyfile" VMU save
to their device which contained their SegaNet information and the IP to connect to. This file was Blowfish encrypted to avoid tampering. Because the IP is in this file, we can easily reroute Daytona to a private server.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License