Overview List

# 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.

Parent (Server) | Child (Client)

(WFS initialization)
`WFS_InitServer`
`WFS_RegisterServerTable` or `WFS_ExecuteRomServerThread`
(Parent/server starts wireless communication)
.
.
.
(Parent/server establishes wireless communication)

(WFS initialization)
`WFS_InitClient`
(Child/client starts wireless communication)
.
.
.
(Child/client establishes wireless communication)
`WFS_StartClient`

(Start calling MP communications hook functions)
WFS_CallServerConnectHook---WFS_CallClientConnectHook
WFS_CallServerDisconnectHook---WFS_CallClientDisconnectHook
WFS_CallServerPacketSendHook---WFS_CallClientPacketRecvHook
WFS_CallServerPacketRecvHook---WFS_CallClientPacketSendHook
* For both the parent and child, the above functions are called repeatedly as appropriate.

(Start waiting for a request) | `WFS_EVENT_CLIENT_READY` event notification
(Internal threads will respond automatically if `WFS_ExecuteRomServerThread` was used) | (If `WFS_RegisterServerTable` was used) `WFS_EVENT_SERVER_SEGMENT_REQUEST` event notification--- `WFS_EVENT_SERVER_SEGMENT_REQUEST` event notification--- `WFS_EVENT_SERVER_SEGMENT_REQUEST` event notification--- | (Application is in direct control) ---`WFS_RequestClientRead` (Data transmission in progress) ---Completion callback | (If using a prepared archive) `WFS_ReplaceRomArchive` `FS_OpenFile`(file, "rom:/abc.data"); `FS_ReadFile`(file, buffer, length);
(Parent/server completes wireless communication) `WFS_EndServer` | (Child/client completes wireless communication) `WFS_EndClient`

## 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