Wireless File System (WFS) Library Overview

Introduction

The WFS library offers functionality that allows a non-ROM-based program, such as one started by DS Download Play, to reference an external ROM image wirelessly. In addition, functionality has been added to allow the ROM image itself to be easily mounted on an FS library file system as a networked virtual drive.

A WFS system is comprised of a single server-side program that offers a ROM image and multiple client-side programs that request that ROM image. The programs use a single port to communicate with each other via the WM library's MP communications. However, WM library functions are not called directly by the WFS library itself; rather, processing that is required for communication is offered as hook functions. For this reason, applications do not need to be reliant on a specific wireless control framework, but may instead introduce their own hook functions.

Process Flow

The WFS library process flow is approximately as follows:

1. Initialization of the context

   First, prepare and initialize a context structure for the WFS library.
   On the parent (server), WFS_InitServer is called; the ROM image is then registered by calling WFS_RegisterServerTable or WFS_ExecuteRomServerThread.
   The child (client) simply calls WFS_InitClient.
   For both the server and client, this initialization must be performed before starting wireless communication.

2. Establishing wireless communication

   After initialization has completed, an application begins wireless communication and transitions into an MP communication-ready state.
   WFS_StartClient must be called by the child (client) immediately after it has connected to the parent (server) and established its AID number.

3. MP communications hook start

   Once an application has become MP communication-ready, it uses any one port for the WFS library and executes continuous MP communication. In more concrete terms, both the parent and children call the following hook functions according to their respective MP communications timing.

   Timing	Parent (Server)	Child (Client)
   Detect a new connection with the other device	Call WFS_CallServerConnectHook.	Call WFS_CallClientConnectHook.
   Detect a disconnection from the other device	Call WFS_CallServerDisconnectHook.	Call WFS_CallClientDisconnectHook.
   Ready to send an MP packet	Call WFS_CallServerPacketSendHook to obtain packet data, and send the packet data via WM_SetMPDataToPort.	Call WFS_CallClientPacketSendHook to obtain packet data, and send the packet data via WM_SetMPDataToPort.
   Receive an MP packet from the other device	Specify the received packet data in a call to WFS_CallServerPacketRecvHook.	Specify the received packet data in a call to WFS_CallClientPacketRecvHook.

   
   
4. Generation of event notifications

   While communication continues and the above hook functions are repeatedly called, the application is notified of each type of event that occurs. Fundamentally, notifications on the parent (server) are generated so that ROM image data can be supplied to children (clients), and notifications on children (clients) are generated to signal that necessary data has been prepared. For more information on event types, see WFSEventType.

5. Reading from a ROM image

   Using WFS_RequestClientRead, a child (client) can read any ROM image from a parent (server). Aside from the difference in transmission speed, this is roughly the same functionality as CARD_ReadRom. The file system mount process, described below, is implemented using this functionality. (If a file system is not necessary, this function may also simply be used independently.)

6. File system mount

   All of the information that is necessary to mount an archive on an FS library file system is included in the information that a child (client) can reference via WFS_GetTableFormat. If an archive procedure is written by combining this data with calls to WFS_RequestClientRead, file accesses can be achieved using the FS library functions the same way as for standard ROM applications. Since a simple implementation of this type of WFS archive is offered by the WFS library as WFS_ReplaceRomArchive, you can normally call this function to use file access functionality in a simple manner.

7. Deallocating context

   Once MP communications have ended, both parent and child must deallocate the WFS library's context structures and perform a termination process.
   The parent (server) calls the WFS_EndServer function once it has disconnected from all children (clients) and ended its role as the MP communications parent (server). When this function is called, the threads automatically generated inside the WFS library are terminated, and the context structures and different kinds of memory are deallocated to the user application.
   Each child calls the WFS_EndClient function once it has disconnected from the parent (server). When this function is called, processing ends for the mounted archive and it become invalid. Note that if MP communications are ended while a child (client) is accessing a file from the parent (server), unless the WFS_EndClient function is called there will be no notification of completion and blocking of the process will continue.

The rough process flow described above is summarized in the figure below.

Revision History

2007/09/27 Added a note about the child (client) side when ending communication.
2007/06/14 Provided details about the added WFS_ExecuteRomServerThread function.
2007/06/11 Provided details on the added functions.
2007/06/06 Initial version.

CONFIDENTIAL