WO2001060022A1 - Wireless information device running multiple interactive applications - Google Patents

Abstract

A wireless information device is programmed with client software including a first application which communicates using datagrams with a second application in accordance with a bearer protocol interface, in which the device comprises a software server to mediate the communication between the first application and the second application and to control the selection of the appropriate bearer protocol interface from several such bearer protocol interfaces. The bearer is treated as connectionless and unreliable, and a server interface to the client software is session-based but unreliable, and is independent of the bearer.

Description

WIRELESS INFORMATION DEVICE RUNNING MULTIPLE INTERACTIVE

APPLICATIONS

FIELD OF THE INVENTION

This invention relates to a wireless information device running multiple interactive applications. The term 'wireless information device' (or 'WID') used in this specification covers smart phones, communicators, electronic personal organisers and other handheld electronic devices which include some kind of wireless communications capability, such as any of the following: GSM mobile radio, CDMA mobile radio, UMTS mobile radio, SMS, Bluetooth and IrDA, and WAP. An interactive application is an application that sends and/ or receives data from another such application or a related application.

DESCRIPTION OF THE PRIOR ART

Interactive games applications, such as chess, battleships, Doom or Multi-User Dungeon games ('MUDs') are currently popular amongst PC users. One conventional solution to interactive gaming involves providing a central hardware server, remote from any of the players' PCs. Game moves are transmitted between two or more PCs over the Internet to the central hardware server. The central hardware server includes the actual gaming applications, communicates moves to other game players' PCs and stores recent moves. A 'server' is a component which provides multiple shared access to one or more resources. Hence in this solution, the PCs used by players, connected to a games web site on the Internet, will typically include no actual gaming playing logic at all, but instead typically only the limited applications necessary to accept and communicate game moves and provide a display of the game environment. For example, chess played between a pair of remotely located players, each using a PC connected to the Internet, will typically require a chess application on a remote hardware server, with each player accessing the remote server and communicating moves to it via a web browser. However, accessing a remote hardware server can be costly and slow. The conventional solution of a remote, central server can be contrasted with the multi- player functionality offered by some kinds of PC games applications: for example, Microsoft Flight Simulator allows several serially or Internet connected PCs, each running the Microsoft Flight Simulator application, to allow all connected PCs to use the same virtual 'air space': each PC is associated with a single aircraft and the PCs communicate their plane's position to the other connected PCs. This allows each user to see the aircraft controlled by all other connected users flying in the same virtual 'air space', and therefore allows real-time dogfights etc. to be simulated. This functionality is achieved by the Microsoft Flight Simulator application including within it a software component that allocates outgoing data to the correct commumcations medium (e.g. serial cable or Internet) and accepts incoming data (defining the position of another's plane). This component is bearer independent, stream oriented and assumes reliability of the bearer.

The principle of a single application including a software server which can appropriately allocate incoming and outgoing data is one found in some messaging architectures, including the messaging architecture used in the EPOC™ operating system from Symbian Limited. The EPOC socket server however makes no assumption about the reliability of the various bearers and itself provides reliability. The interface to the client software is session based but is not bearer independent.

SUMMARY OF THE PRESENT INVENTION

In accordance with the present invention, there is provided a wireless information device programmed with client software including a first application, the first application being able to communicate using datagrams with a second application or applications located either on the device itself or elsewhere, with the communication taking place using a bearer in accordance with a bearer protocol interface, in which the device comprises a software server to mediate the communication between the first application and the second application and to control the selection of the appropriate bearer protocol interface from several such bearer protocol interfaces, characterised in that: (a) the bearer is treated as connectionless and unreliable, and (b) a server interface to the client software is session-based but unreliable, and is independent of the bearer.

This structure is a flexible one which leads to many advances. For example, the server interface to the client software allows the session state to be stored to a file, and later restored. This allows applications to be closed, saving their state to file, and later reopened, loading their state back from file, so that they can continue to be used as if they had never been closed and re-opened. Also, the server interface to client software may allow multiple concurrent applications of different types, or the same type, to run simultaneously, with multiple bearers being utilised as appropriate. A 'datagram' is an interface for sending and receiving packets of data.

The server may supports at least two of the following bearers: IrDA, Bluetooth, WDP, datagram or SMS text messaging on GSM, datagram (including text messaging) on CDMA, datagram (including text messaging) on D-AMPS, datagram (including text messaging) on W-CDMA. Preferably, the server supports one bearer which is free at the point of use, including IrDA, Bluetooth; and another bearer which is not free at the point of use (e.g. requiring a use based charge or a subscription charge or is advertising supported but free to a user), such as WDP, datagram or SMS text messaging on GSM, datagram or text messaging on CDMA, datagram or text messaging on D-AMPS, datagram or text messaging on W- CDMA.

Preferably, an intermediate software between a main application logic and the server interface to client software adds reliability, and/ or constrains the application-to-application communication to be of a conversational nature. It may, for example, allow its state to be stored to a file, and later restored.

In a preferred embodiment, the intermediate software adds reliability, constrains communication to be of a conversational nature, and packs requests and responses into a single datagram so as to minimize usage charges where these may be incurred by a particular bearer.

Many different kinds of applications are can be used: a two-player turn-based game, a two- player real-time game, a multi-player turn-based or real-time game, chat, data streaming, digital cash, digital loyalty schemes or other business application are all preferred applications.

Where the first application is a two-player game or a multi-player game, then one or more of the players may be computer software rather than a human end-user. The wireless information device may also send data to and receive data from a remote hardware server.

A consequence of the present invention is that it is an application resident in one person's WID that communicates with an application resident in another person's WID. It is peer to peer. This is a fundamentally different approach over the conventional central server based approach. Another benefit is that any number of applications, senders and recipients of data relating to any application, and communications methods can be used, in any combination, all mediated by the local, software server. For example, in a gaming embodiment, a wireless information device can have open two chess games with different users with moves exchanged over SMS and email, with a simultaneous game of scrabble over SMS being played with three other people, while the time between moves could be whiled away by playing battleships over IR.

In another preferred embodiment, an application sends data to a peer application using a reliable datagram protocol with all packets being sent via a session opened with a server resident on the sender's WID and being received via a session opened with a server resident on the recipient's WID. As noted above, the server is capable of routing moves over multiple types of bearer (including but not limited to local loopback, IR, SMS, WAP, and email). The datagram layer is bearer-independent and multiplexed and demultiplexed by the server, which manages the session datagram protocol. Preferably, persistent states may be saved and restored at session datagram protocol level, in which a single logical session can encompass many individual transactions (e.g. game moves). This is particularly convenient for gaming applications, which may last many weeks, and also for other kinds of applications such as electronic wallets and loyalty cards. ,

In one embodiment, a conversation protocol is used to deliver reliability, persistence, and economy. Conversation protocols are particularly relevant to turn-based games and one embodiment of the invention is suitable for non real-time transaction games.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be described with reference to the accompanying drawings in which:

Figure 1 is the protocol stack for the TOGS implementation of the present invention used for the 'Battleships' game;

Figure 2 illustrates how the GDP (Games Datagram Protocol) offers a simple interface for sending and receiving packets of data;

Figure 3 is a UML representation showing how the GDP API consists of two interfaces;

Figure 4 shows the various IDs added to the GDP datagram payload by GSDP (Games Session Datagram Protocol);

Figure 5 shows how a session between two partners is set up and then maintained;

Figure 6 the two classes which the client program API consists of; Figure 7 shows the structure of the GSDP server and its interfaces;

Figure 8 is an overview of the server-side classes in UML;

Figure 9 shows the processing that happens to a GSDP datagram as it goes from client to the GDP medium;

Figure 10 shows how receiving a packet is managed in the GSDP server;

Figure 11 illustrates how, after session setup, conversations in RGCP follow a strict request-response sequence;

Figure 12 shows how the response to a previous request by one partner shares a packet with the responding partner's next request;

Figure 13 shows the structure of a RGCP packet, which uses GSDP as a transport;

Figure 14 shows the allowable RGCP states, and all allowable transitions between them;

Figure 15 shows in UML how an EPOC RGCP implementation operates entirely client- side, and builds on the GSDP client API; and

Figure 16 shows the 'Battleships' game transitions. DETAILED DESCRIPTION

The present invention will be describe with reference to an embodiment known as TOGS (Transaction Oriented Games Server), designed for the EPOC operating system for WIDS. The EPOC operating system forms part of the Symbian platform from Symbian limited of London, United Kingdom. SDKs for this platform are readily available and enable implementation of this invention.

Some term explanations

'Server host': a computer, typically but not necessarily fixed rather than mobile, which runs server software which interfaces not to end-users via GUI, but to client programs through a communications network or link;

'Server': a program on the same machine as the application, which provides services to multiple applications and] also to other servers. The services are provided through an interface to client programs; 'Connectionless': each datagram is sent independent of any others, with its own addressing information;

'Unreliable': a datagram may not be delivered to its intended destination, and the originator is not notified of any such non-delivery;

'Session-based': context is established so that each datagram in a session is sent to the same destination, and each datagram is received from the same destination;

[it should be noted that a single application may use multiple sessions simultaneously]

'Reliability': a datagram is either delivered successfully and the system behaviour perceived by the sender is as though the datagram was delivered, or the datagram is not delivered and the system behaviour as perceived by the sender is as if it was not delivered; 'Conversation': a form of communications interaction in which the two end-points take strict turns to send messages;

'File': a persistent data storage object whose lifetime exceeds the time the program is open, and ideally the time during which power is available to the device. In the following section, the definitions relate to the described structure as follows:

In 'TOGS' (Transaction Oriented Games Server), • wireless information device = EPOC machine, or other computer

• bearer = GDP implementation

• server = GSDP

• bearer protocol interface = GDP

• server interface to client = GSDP client interface • software between main application logic and server interface to client, to add reliability, constrain to conversation, and pack requests and responses = RGCP

• application = two-player game

The Transaction Oriented Games Server ("TOGS") is designed to allow a single Wireless Information device to simultaneously engage in multiple games, with multiple opponents, using multiple types of bearer.

The type of games which TOGS facilitates are classical games based on moves, plays, turns, deals or other atomic transactions. Examples include chess, draughts (checkers), and cards. These types of games are not heavily real-time and do not necessarily either monopolize the attention of the players or require the dedicated use of a computer or other apparatus. They depend entirely on the exchange of information between players - in other words, while they can be played on a computer, they don't depend on playing against a computer. Players can use a computer to store the state and history of the game, or graphically represent the state: the game is played with or against other players.

TOGS enables a wireless information device to automate the maintenance of the state and the recording of the moves of multiple games, using multiple different bearer mechanism for conveying moves between different devices. For example, a single wireless information device can keep a game of chess going over a cellular messaging service such as GSM SMS, while at the same time playing a second game of chess over electronic mail, and a game of bridge over a short link wireless protocol such as Bluetooth. The range of possible games and possible bearers is not limited in any way.

The key to this implementation of the invention is the specification of a protocol stack for the playing of games, which incorporates a single local server module shared by all games and all bearers. Each WID includes its own local server module.

Individual games can define their own protocol for passing transactions. However, all games conforming to the TOGS specifications will open a session with a local Games Session Datagram Protocol ("GSDP") Server using the Reliable Games Conversation Protocol ("RGCP"). The GSDP Server then exchanges moves using the Games Datagram Protocol ("GDP"), which delivers packets to a GSDP Server on a remote device. Different implementations of GDP are needed for each type of bearer. While current implementations included a loopback mode for testing, an Infrared ("IR") module and a module using the GSM Short Message Service ("SMS"), there is no reason why GDP cannot be implemented for and layered over any other communications protocol for any type of bearer.

The implementation of the invention described here used TOGS to play a game of Battleships between two players, either on a single machine using GDP-Loopback, or on two machines using either GDP-IR or GDP-SMS. The Battleships game itself defines its own Battleships Protocol ("BSP") for packaging transactions, which are then exchanged through the GSDP server using the RGCP protocol to assure reliability. The protocol stack for this example is shown in Figure 1. This example is used for illustrative purposes. The scope of the invention is not restricted or limited to any particular game, or any number of players, and is not restricted as to the type or number of bearer implementations of GDP. Similarly, while the implementation of the invention described here runs on Symbian's EPOC operating system and is described using EPOC conventions and classes, this is in no way intended to restrict the scope of the invention, as it can equally well run on other operating systems.

A brief description of each of the layers of the TOGS stack follows.

1. GDP - Game Datagram Protocol

The purpose of GDP is to be the simplest possible interface for sending and receiving packets of data. As a client, you call a SendLfj function specifying a to-address and a some data — a datagram. A GDP implementation transfers this packet to the target address. Software on the target then executes a GdpHandleLO function whose parameters include the from-address and the data, as shown in Figure 2.

The address received by GdpHandleL should be such that it can be used to generate a reply to the sender. Point-to-point GDP implementations do not require addresses at all: the nature of the comms link is sufficient to get the reply back to the sender. Networked implementations (such as SMS) rely on addresses to specify the recipient (and then sender) or a datagram.

How the implementation sends the addresses and data is not specified. However, the GDP protocol — and its APIs — anticipate the requirements of particular implementations, such as:

• infrared: this is a point-to-point local communications protocol in which addresses do not matter very much.

• SMS: text messages are used as the transport. The address is a phone number. The datagram is encoded onto the character set supported by SMS. • loopback: any function call to the send function results immediately in a call to the handle-packet function with the same parameters. This is a conventional approach to co ms testing. Loopback is point-to-point and does not use addresses.

Other implementations, such as serial cable, TCP/IP, Bluetooth, smart e-mail messages, or push technologies such as WAP could also be used for GDP.

GDP is not limited in its application to EPOC machines. A GDP implementation may communicate with non-EPOC machines also. For this reason, a concrete GDP implementation should specify its physical data formats with sufficient precision for a non- EPOC system to be able to implement a corresponding GDP stack which connects to it.

GDP is unreliable. That means that a request through SendL() is sent on a best-efforts basis, but is not guaranteed to arrive precisely once — it may never arrive, or it may in rare circumstances arrive more than once. GDP is not responsible for taking recovery action or for returning error codes to its client.

However, GDP should make reasonable efforts and it should be possible for the end-user to understand its reason for failing — e.g., the destination machine is turned off, a cable isn't connected, there is no visual path between infrared ports, the user made a mistake in the (admittedly clumsy) mechanics of sending a text message via SMS, etc.

A GDP implementation should not fail due to time-outs in lower-level protocol stacks. GDP is designed for sending packets in games with a high concentration to action ratio, such as chess. The time between sending datagrams may be anything from several seconds to minutes, quarter-hours or even days or weeks, even while both ends have a GDP session active. If lower-level stacks do have time-outs so they can't be kept open indefinitely, the GDP implementation should manage the lower-level stack in such a way as to hide this problem from the GDP client code — for instance, by re-opening the lower-level stack when every datagram is sent, or at any rate when needed because of time-outs. A GDP implementation which times out could if necessary use receive-all to re-enable its receiver.

1.1 EPOC Implementation

The GDP API consists of two interfaces. A client will use MGdpSession to send packets via the implementation, and implement MGdpPacketHandler to handle packets received from the implementation. A GDP implementation implements MGdpSession and uses MGdpPacketHandler. Figure 3 shows it in UML. And here, in C++ declarations:

class MGdpPacketHandler

{ public: virtual void GdpHandleL(const TDesC& aFromAddress. const TDesC8& aData) = 0; } ; class MGdpSession

{ public: virtual void OpenL(MGdpPacketHandler* aHandler) = 0; virtual void Close() = 0; virtual void SendL(const TDesC& aToAddress, const TDesC8& aData) = 0; virtual void ReceiveAllLO = 0; virtual Tint GetMaxPacketLengthO = 0; virtual TBool IsNetworkedO = 0; };

MGdpSession contains the following functions: Function Description

OpenLQ Constructs everything needed for the GDP implementation, and specifies the handler for received packets.

CloseQ Destroys everything that the implementation has constructed. Finishes with delete this, so that the session is destroyed. Therefore, GDP sessions cannot be reopened after they have been closed.

SendLQ Makes best efforts to send a datagram. You need to specify a to-address (needed by networked implementations) and data. This function may leave if resources need to be reallocated (because, for instance, they have timed out since OpenLQ). Returns synchronously, but may cause an asynchronous process to be initiated for sending the datagram: errors are not reported. An implementation must make a private copy of the aData that is to be sent. The caller may re-use the data buffer any time after calling SendLQ.

ReceiveAllLQ Initiates an asynchronous process to cause any outstanding datagrams to be received. May leave if resources need to be reallocated (because, for instance, they have timed out since

OpenLO).

IsNetworkedQ Returns ETrue if the protocol is networked. In this case, a non-empty to-address is required for SendLQ calls, and a non-empty from-address is passed to GdpHandleLQ.

GetMaxPacketLengthQ Returns the maximum length of a GDP datagram, excluding addresses, which can be transmitted by the protocol implementation. MGdpPacketHandler contains the following function:

Function Description

GdpHandleLQ Called to handle a packet that has been received, specifying the data and the from-address. For networked protocols, this enables you to reply to the sender. A handler should make a copy of the aData passed to it: the buffer may be re-used by a GDP implementation immediately after GdpHandleLQ returns.

2. GSDP: Game Session Datagram Protocol

GSDP adds session capability to GDP datagrams. All GDP implementations are run on a server.

2.1 GSDP Client Program interface

A client program uses the GSDP client program interface, not the GDP interface, to send data. To the GDP datagram payload, GSDP adds, as shown in Figure 4:

• A from-port ID: this is the non-zero ID of a port used by the sending client

• A to-port ID: during an established session, this is a non-zero ID which identifies the client on the target EPOC machine (or other entity specified by a GDP address) which will receive the datagram • A game protocol ID: this is used in session setup.

When a client connects to the GSDP server on its machine, it specifies the game protocol it will use. If the client listens with its zero port ID, then an incoming packet with a zero port ID will be matched with a client's game protocol ID. Thus the game protocol ID ensures that the session is set up with a compatible partner. These IDs are all 32-bit numbers. The from-port and to-port IDs are allocated by the GSDP server in ascending sequence. The game protocol ID is a Unique Identifier ("UID"). Theoretically, neither the game ID nor the from-port ID is needed throughout the session. But they provide a useful redundancy check.

The GSDP datagram contents are passed as arguments to the GSDP send and handle functions. The session between the GSDP client and the GSDP server on the same machine carries the state required to set the non-data fields — from-port ID, to-address, to-port ID, and game protocol ID.

By using a GDP loopback implementation inside the GSDP server, two GSDP clients on the same machine may communicate with each other. Although GSDP is session-based, it is not reliable. A GSDP send is no more reliable than a GDP send: it may result in zero, one, or more receives at the destination. The GSDP client API allows you to specify the GDP implementation to be used for a GSDP session. GDP implementations are managed by the GSDP server. The GSDP server uses GDP implementations, as specified above, without any change. For a packet to reach a particular GSDP client successfully, its sender must specify the correct address, port, and game protocol ID. There are two interesting cases here:

• The to-port is non-zero: a GSDP client must be listening with the correct port ID. This is used for communication after a session has been set up. • The to-port is zero: a GSDP client must be listening with a zero port ID, and a matching game protocol ID. This is used for session setup.

These two possibilities allow a session between two partners to be set up and then maintained, as shown in Figure 5. The session is set up by the initiating partner, which sends a packet with a non-zero from-port, a game protocol ID, and a zero to-port. The session is accepted by a listening partner, which has a matching game protocol ID and a zero port ID. Once accepted, the listening partner allocates its own non-zero port ID, and sends back a packet to the initiating partner: this binds the session. Subsequent communication uses non-zero port IDs on both sides. GSDP is intended to support two-player games with an arbitrarily long think time between moves. A GSDP session must persist even when the games are saved and closed at either or both ends. A client must save its GSDP state, including addresses and port IDs. The server provides functions that are able to support the client restoring its state. The server does not hold state information on clients' behalf, beyond client-server session termination. The server queues incoming datagrams and holds them so that they can be received by a dormant client, or by a new client launched in listening mode. The queue is managed as follows:

• If an incoming datagram has a non-zero to-port ID, which matches the port ID of an active listening client, then that request is satisfied by the datagram — that is, the datagram is received.

• If the datagram has a zero to-port ID, and a game protocol ID that matches an active client with a zero port ID, a matching game protocol ID, and an outstanding receive request, then the request is satisfied and the datagram is received.

• If neither of these conditions is true, then the datagram is added to the queue.

• Whenever the game protocol ID or port ID of a client is changed, or a new receive request is issued, the queue is scanned to see if any datagrams in it match the rules above: if so, such datagrams are received. • If a datagram is received by matching the above rules, but it doesn't match other sensible rules, then the datagram is dropped — that is, it's absorbed by the GSDP server and not sent to the client, and the client's receive request is not fulfilled. Examples of such 'sensible rules' include that the game protocol IDs must match when the port ID is non-zero, and the from-address should be as expected when the to-port ID is non-zero. These rules are based on redundant information in the GSDP packet, which allows a useful check to be performed.

• Packets on the queue may be expired according to rules at the discretion of the GSDP server implementer. If the queue is too large, then packets may not be accepted onto it when received by a GDP implementation. The present EPOC implementation expires packets only when the GSDP server is stopped — which happens when all its clients are stopped. The present EPOC implementation has a maximum queue length of 10: any additional packets are dropped.

• These awkward management issues notwithstanding, the queue is necessary because a client may not be started when an initiate request from a GSDP game on another EPOC machine arrives. Also, when a client's receive request is fulfilled, it doesn't issue a new one until it has handled the previous one, which causes a transient condition whereby the client is unable to receive.

GSDP specifies no formal mechanism for releasing a GSDP port ID, which means it's important that port IDs be allocated uniquely by a given GSDP server. The EPOC GSDP server maintains the last-allocated port ID in a file in c:\System\Data\: the port ID is incremented and re-stored every time a new session is initiated or accepted. This file persists across GSDP server invocations, and guarantees unique port ID allocation provided that all port IDs are dropped by the time wraparound occurs. In practice, this is sufficient: if one port ID were allocated per second, it would take over 143 years to wrap around.

2.2 GSDP Client Program Interface: EPOC Implementation

The client program API consists of two classes: a concrete RGsdpSession class to control the session and send packets, and an abstract MGsdpPacketHandler class that you should implement for handling received packets, as shown in Figure 6.

Additionally, a private, client-side active object, CGsdpReceiveHandler, turns the client listen function into a continuously renewed receive request. This removes any responsibility from the client to implement its own active object to handle or renew the request. Here is RGsdpSession's declaration in C++, showing additional housekeeping and getter functions: class RGsdpSession : public RSessionBase

{ public: enum TGdpProtocol {

EGdpLoopback=l, EGdpIr, EGdpSms

}; public:

// Construct inline RGsdpSessionQ : iHandler(O) {};

// Open/close

IMPORT_C void ConnectL(MGsdpPacketHandler* aHandler);

IMPORT_C void CloseQ;

// Load and get GDP protocol IMPORT_C void SetGdpProtocolL(TGdpProtocol aProtocol) ;

IMPORT_C TGdpProtocol GetGdpProtocolQ const;

IMPORT_C TBool GdpIsNetworkedQ const;

// Game protocol

IMPORT_C void SetGameProtocol(TUint32 aProtocol); IMPORT_C TUint32 GetGameProtocolQ const;

// Set and get my address and port

IMPORT_C void SetMyPort(TUint32 aPort);

IMPORT_C TUint32 GetMyPortO const;

IMPORT_C TUint32 AllocMyNextPortO; // Set and get other address and port

IMPORT_C void SetOtherAddress(const TDesC& aAddress);

IMPORT_C void GetOtherAddress(TDes& aAddress) const;

IMPORT_C void SetOtherPort(TUint32 aPort);

IMPORT_C TUint32 GetOtherPortQ const; // Main protocol functions

IMPORT_C void ListenQ; IMPORT_C void StopIisteningQ;

IMPORT_C void Send(const TDesC8& aData);

// Initiate receive-all for "pull" protocols

IMPORT_C void ReceiveAUQ const; private: friend class CGsdpReceiveHandler; void Receive(TDes8& aBuffer, TRequestStatus& aStatus); void CancelReceiveQ;

CGsdpReceiveHandler* iHandler;

};

The functions of RGsdpSession include:

Function Description

ConnectLQ Connects to the GSDP server, and specifies a GSDP packet handler. The server is launched if it is not already active

CloseQ Closes the session with the server. The server may choose to terminate if it has no more clients, but the client API does not mandate this.

SetGdpProtocolLQ Sets the GDP implementation to be used by the session. Will leave if the implementation is not available, or cannot be initialized.

GdpIsNetworkedQ Indicates whether the GDP implementation is networked (requires valid addresses) or point-to-point (ignores addresses).

SetGameProtocolQ Sets the game protocol, specifying a 32-bit UID. SetMyPortQ Sets my port ID, specifying the port ID as a 32-bit unsigned value. Use this function when restoring a session previously established.

AllocMyNextPortQ Allocates a unique port ID for me, and returns its value. Use this function when starting a new session.

SetOtherAddressQ Sets the address of the other partner in the communication, with a string. Used only by networked GDP implementations.

SetOtherPortQ Sets the port of the other partner in the communication, with a 32-bit unsigned value. Use this when setting up a session that has been previously established; set it to zero when starting a new session.

ListenQ Causes a ReceiveQ request to be issued. When the request completes, the received datagram will be handled using MGsdpPacketHandler: :GsdpHandleLQ . The receive request will then be renewed so that, without client intervention, any number of packets can be received

StopListeningQ Cancels any outstanding receive request started by ListenQ. You may issue this function even if no call to ListenQ has been issued, or if it has already been cancelled

SendLQ Sends a datagram using whatever current address, port, GDP implementation, and game protocol ID are specified

ReceiveAllLQ Causes the GDP implementation to do a ReceiveAllLQ. This may result in received packets that need to be handled for any GSDP session that uses the same GDP implementation, not only the GSDP session that issued the ReceiveAllLQ.

GetXxxQ Getter functions for address, port, GDP implementation, and game protocol ID

MGsdpPacketHandler is declared as class MGsdpPacketHandler

{ public: virtual void GsdpHandleL(const TDesC8& aData) = 0;

> ; with the following function:

Function Description

GsdpHandleLQ Handle a received packet. The server guarantees that the packet matches the game protocol and port numbers required by the protocol.

2.3 GSDP Server module

The purpose of the GSDP server is to allow GDP drivers to be shared between multiple games on a single EPOC machine. To achieve this, the GSDP server:

• Runs the GDP implementations on behalf of all games on an EPOC machine

• Associates an origin, a destination address, a destination port number, and a game protocol with each client session, so that from the client's perspective,

GSDP is a session protocol rather than a stateless datagram protocol • When sending a packet, selects the right GDP implementation, and adds the correct port numbers and game protocol ID into the packet's datagram content

• When receiving a packet, uses the port number and protocol ID to select which client should receive it This functionality is reflected in the server's client interface, and in its internal structure. The structure of the server and its interfaces is shown in Figure 7.

2.3.1 GSDP Server: Client Interface

The client interface (that's the interface within the server used by a client program) consists of a header file, gsdp.h, and corresponding functions exported from the DLL. Another header file, gsdpdef.h, includes definitions that tie the client interface and the server together — mainly the request codes passed in the various messages. All other header files are private to either the client alone, or the server alone. The GSDP server is a transient server: it's started when a client program needs it, and terminates itself when no more client programs need it.

On EPOC, the GSDP API used by a client program is defined in gsdp.h as follows:

// gsdp.h

#ifndef _GSDP_H #define _GSDP_H #include <e32base.h>

// Game session datagram protocol interface specification class MGsdpPacketHandler

{ public: virtual void GsdpHandleL(const TDesC8& aData) = 0;

}; class CGsdpReceiveHandler; class RGsdpSession : public RSessionBase { public: enum TGdpProtocol { EGdpLoopback = 1, EGdpIr, EGdpSms }; public: // Construct inline RGsdpSessionQ : iHandler(O) {};

// Open/close

IMPORT_C void ConnectL(MGsdpPacketHandler* aHandler);

IMPORT_C void CloseQ; // Load and get GDP protocol

IMPORT_C void SetGdpProtocolL(TGdpProtocol aProtocol);

IMPORT_C TGdpProtocol GetGdpProtocolQ const;

IMPORT_C TBool GdpIsNetworkedQ const;

// Game protocol IMPORT_C void SetGameProtocol(TUint32 aProtocol);

IMPORT_C TUint32 GetGameProtocolQ const;

// Set and get my address and port

IMPORT_C void SetMyPort(TUint32 aPort);

IMPORT_C TUint32 GetMyPortQ const; IMPORT_C TUint32 AUocMyNextPortQ;

// Set and get other address and port

IMPORT_C void SetOtherAddress(const TDesC& aAddress);

IMPORT_C void GetOtherAddress(TDes& aAddress) const;

IMPORT_C void SetOtherPort(TUint32 aPort); IMPORT_C TUint32 GetOtherPortQ const;

// Main protocol functions

IMPORT_C void ListenQ;

IMPORT_C void StopListeningQ;

IMPORT_C void Send(const TDesC8& aData); // Initiate receive-all for 'pull' protocols

IMPORT_C void ReceiveAllQ const; private: friend class CGsdpReceiveHandler; void Receive(TDes8& aBuffer, TRequestStatus& aStatus); void CancelReceiveQ;

CGsdpReceiveHandler* .Handler;

}; const Tint KMaxGsdpAddress=40; const Tint KMaxGsdpData=100; #endif

The interface follows the communications stack pattern that we've talked about before: requests are passed down the stack using functions of the RGsdpSession class, while data is passed up the stack by calling GsdpPacketHandler::GsdpHandleLQ.

The client interface uses EPOC active objects, but hides them from the interface, so that: • As a client, you do not have to write a derived active object class — you just derive from MGsdpPacketHandler and implement GsdpHandleLQ

• As a client, you can issue ListenQ to receive any number of packets, and StopListeningQ to stop receiving them.

Internal to the client interface, there is a derived active object class — CGsdpReceiveHandler — that maintains the outstanding receive request, calling RGsdpSession's private, non-exported ReceiveQ and CancelReceiveQ functions in order to do so.

• Message passing functions

The majority of the client interface consists of message-passing functions that compose the parameters of the client interface function into a message, send the message, receive the response, and return the result to the client.

• Listening and receiving

The client interface for receiving data consists of two functions: IMPORT_C void ListenQ; IMPORT_C void StopListeningQ;

RGsdpSession::ListenQ makes the client interface start maintaining an outstanding receive request. StopListeningQ tells the client interface to stop maint_L_ning that request.

• Connecting and Disconnecting

The client interface and receive handler functions assume the server is already there, and that the client has already connected to it. The client connects to the server using ConnectLQ, which sets a handle value to associate with the session. The client disconnects using CloseQ, which zeroes the handle.

2.3.2 GSDP Server: Server Implementation

The Figure 8 diagram contains a quick overview of the server-side classes in UML.

The majority of the work for clients is done in CGsdpSession. GSDP datagrams are sent by simply wrapping them up and then using one of the GDP protocol implementations to send them. On receipt, the process is reversed. The server owns a list of CGsdpGdpAdapters, which both handle datagram wrapping and unwrapping, and own the specific GDP protocol implementations, so that there is one adapter for each GDP protocol. Adapters are shared between all sessions that use them. The server also uses a port number allocator to allocate unique port IDs to GSDP-initiating clients.

Receiving datagrams is more complicated than sending them, because an incoming datagram must be associated with the correct session. Incoming datagrams go onto a queue, and items are only taken off that queue when an appropriate client issues a receive request.

As you can see from the diagram, it is the server class, CGsdpServer, that holds everything together.

Startup and shutdown are handled in conjunction with a derived active scheduler class, a shutdown timer, and some support from the CGsdpSession destructor. 2.3.3 Sending Datagrams

The purpose of the GSDP server is to send datagrams using a given GDP protocol, but wrapping them to include port IDs and game protocol ID. The next diagram, Figure 9, shows the processing that happens to a GSDP datagram as it goes from client to the GDP medium.

Before the processing in this figure takes place, the client has already done some setup using GSDP functions:

• The client has started a GSDP session • The client has specified a GDP protocol, which causes the GSDP server to attach that protocol to the server-side session

• The client has specified a game protocol ID, its own port ID, and the other partner's address and port ID. The server simply stores these values in its CGsdpSession member variables The client is then ready to send a GSDP datagram:

• The client calls SendQ, which causes a EGsdpReqSend message to be sent to the server

• The server-side session uses an inter-thread read to get the data to send

• The data is then wrapped up to include the game protocol ID, my port ID as the from-port ID, and the other port ID as the to-port ID

• This datagram is then sent to the other address, using GDP send

The GDP implementation may then do any processing required to send the datagram. A loopback implementation will make a simple function call. A real implementation, such as the infrared implementation, will use a system of active objects to open the communications resources needed, send the datagram, and then close the communications resources again. However, GDP is not required to report the success of this operation back to the server. Provided the system of active objects used by the GDP implementation is reasonably well behaved, the implementation has no further effect on server design or performance. When a packet is sent, the GDP adapter is used to send the client's datagram, along with the relevant game protocol and port information, to the GDP destination address.

2.3.4 Receiving Datagrams Figure 10 shows how receiving a packet is managed in the GSDP server.

The steps in receiving a datagram are:

• The datagram arrives via a GDP implementation

• It is handled by the GDP adapter's GdpHandleLQ function • The GDP adapter parses the GSDP header information — game protocol ID, from-port, and to-port — and passes the datagram to the receive queue

• The receive queue allocates a slot for the incoming datagram, and adds it to the queue

• The receive queue then checks to see whether any session can receive the packet: this means the session must have an outstanding receive request, and either a matching port ID, or a zero port ID and a matching game protocol ID

• If a session can receive it, the message is sent to the client using inter-thread write, the receive message is completed, and the datagram slot is returned to the receive queue's free list • On the client side, this will eventually cause the CGsdpReceiveHandler active object's RunLQ to be scheduled, which calls the client's GsdpHandleLQ function and then renews the receive request to the server

For unwrapping, the datagram is passed from the GDP implementation to the GDP adapter and handled by its GdpHandleLQ function. The receive queue is a list of datagrams (referred to as 'packets' in its API) waiting to be received by clients. Packets are added to the list by the ReceiveQ function. A packet just added to the list is offered to all sessions to see whether it can be received. When a session changes its settings or issues a receive, it checks the receive queue using CheckPacketsQ to see if there are any packets waiting for that session. By this means, a packet is delivered to a session as soon as possible.

3. RGCP

RGCP is the Reliable Game Conversation Protocol, which addresses the requirements of application programs.

Firstly, two programs communicate to each other using a session: once the session is set up, there is simply an 'other' partner, and there's no need to choose who it is.

Secondly, each party in the session takes it in turns to send a request, and receive a response — or, looked at the other way, to receive a request, and send a response. This is a conversation, and it is clearly a natural paradigm for a turn-based game.

Finally programs want reliable behavior rather than the underlying unreliability of real communications systems. 'Reliability' means that system behavior, as you perceive it, is consistent with what actually happened.

So: • If your request did not get through, you can never receive a response, or another request from your opponent, and you cannot issue another request yourself - that would violate the rules of conversation.

• If you receive a response, then that is an indication that your request did get through and was handled according to conversation rules by the other party. You can rely on that.

• If the packet you send arrives, then it is guaranteed to be the packet you sent.

We could spell out many other particular cases, but in summary, GDP addresses the realities of communications, and RGCP meets the basic requirements of application programs.

After session setup, conversations follow a strict request-response sequence, as shown in Figure 11. In order to save costs (GSDP datagrams using cellular networks have a financial cost to its sender), the response to the previous request by one partner shares a packet with the responding partner's next request, so that in terms of the lower-level GSDP communication, the picture is given in Figure 12.

RGCP uses essentially the same methods as GSDP for session setup, but it adds reliability by allowing packets to be re-sent. RGCP also provides for normal session termination (rather than simply abandoning communications, which is the best you can do in GSDP). Because RGCP is a conversation protocol, it is relatively easy to provide reliability. At most, one packet needs to be stored for potential re-sending (though in bad cases it may be re-sent many times).

The conversation protocol paradigm is clearly suitable for two-player, turn-based games. It can also be adapted for various situations that are not strictly conversational. For instance, a player may take multiple moves either by piggy-backing them into a single RGCP request, or by sending them in individual RGCP requests, with the other player acknowledging each one and sending a 'no-move' request in turn.

A single RGCP session may be used to play more than one game, if the request-response protocol for the game protocol ID supports it. The request-response protocol would then have to support not only game moves, but also game initialization, termination, and choosing who has the first move. (BSP does this).

3.1 Packet Structure RGCP uses GSDP as a transport. An RGCP packet has the following structure, shown in Figure 13:

• GDP header with from-address and to-address

• GSDP header with game protocol ID, from-port ID, and to-port ID • RGCP sequence number (or zero for unsequenced packets)

• RGCP response packet

• RGCP request packet

The request and response packets have identical formats: • One-byte length in range 0-127, giving the total length of opcode plus data

• One-byte opcode specifying the operation to be performed (if the length is 1 or greater)

• Data bytes, 0-126 bytes long

Certain opcodes are reserved for RGCP protocol functions. The meaning of all other opcodes depends on the particular type of conversation, as identified by the GSDP game protocol ID. The minimum length of an RGCP datagram is 7 bytes, plus GSDP headers, plus GDP headers. The 7 bytes comprise four for the sequence number, one for a zero- length response, and two for the request (a length of one, and the request opcode).

Once a GSDP session has been bound, only sequenced packets are accepted, with sequence numbers starting at 1 after session establishment. The receiver maintains a record of the last-received sequence number and drops packets whose sequence number is less than or equal to this, eliminating duplicates. The RGCP transmitter maintains the last-sent packet, and re-sends it identically on request. The last-sent packet is deemed acknowledged when a corresponding response/request packet is received. The last-sent packet is deleted when it has been acknowledged, and cannot then be re-sent.

RGCP defines three request opcodes: • Oxff: initiate — also used to indicate initiate-response

• Oxfe: terminate

• 0x00: should not be used Other opcodes may be defined by specific RGCP implementations. Responses are uniquely associated with their corresponding requests, so a response opcode system is not strictly necessary. RGCP protocol designers may, however, find it convenient and/ or safer to use the same opcodes for responses as they use for requests.

3.2 States and Transitions

Figure 14 shows the allowable states, and all allowable transitions between them (except reset transitions, which have been omitted for clarity, but which are possible from any state to blank).

RGCP states correspond precisely to underlying GSDP states, with the distinction that GSDP's bound state is divided into two major states, requesting and waiting, that correspond to whether it is this partner's turn to 'talk' or not. That is natural: this is precisely what a conversation protocol is all about. The additional responding state is a brief transition state between waiting and requesting. All of these states may be of arbitrary duration, except responding, which must complete in the duration of a single synchronous function call.

This implies that an RGCP response should be a response to the request that contains information about the result of the other partner's move — not a responding movt, which would take arbitrary time.

3.3 Packet Handling

RGCP's rules for handling incoming packets, delivered to it by GSDP, may be summarized as follows: • [If the port IDs and game protocol ID don't match those for the session, incoming packets won't even be received.]

• If the packet's RGCP headers are malformed it is dropped. • If the sequence number is zero, and it's a terminate request, then the RGCP session is immediately terminated: no response is sent.

• If the sequence number is zero, and it's an initiate request, and the current state is listening, then an initiate response is formulated accepting the initiate, the GSDP session is bound, and the RGCP state changes to requesting. The sending sequence number is incremented to 1 so that this becomes the first sequence number of an ordinary packet from the listening partner. In all other circumstances, a zero sequence number packet is dropped.

• If the sequence number is less than or equal to the last-received sequence number, then the packet is dropped.

• If the sequence number increments the last-received sequence number by more than one, then the packet is dropped.

• [We now assert that it is a normal in-session response/request datagram, so the state must be waiting.] • The last-received packet sequence number is incremented.

• The response is handled, and then we check that the RGCP stack hasn't been terminated by higher-level function calls.

• The state is changed to responding; the request is handled, and we check again that the stack hasn't been terminated. If no response has been written, we produce a null response.

• [The response is not sent at this stage: rather, the partially-written send buffer is maintained until an RGCP request is sent. At that point, the response and request are sent in a GSDP datagram.]

• The state changes to requesting.

3.4 RGCP EPOC Implementation

The EPOC RGCP implementation operates entirely client-side, and builds on the GSDP client API. As usual, one concrete class (CRgcpSession) owns the session and handles sending, while another abstract class (MRgcpHandler) specifies virtual functions that should be implemented by the client. Figure 15 shows it in UML (omitting some housekeeping and getter functions):

Here is CRgcpSession's declaration in C++: class CRgcpSession : public CBase, public MGsdpPacketHandler

{ public: enum TState {

EBlank, EListening, Elnitiating, EResponding, ERequesting, EWaiting

}; enum TOpcode

{ EReserved=0, Elnitiate=0xff, ETerminate= Oxfe

}; public: // Construct/ destruct

IMPORT_C CRgcpSessionQ;

IMPORT_C void ConstructL(TUint32 aGameProtocol);

IMPORT_C -CRgcpSessionQ;

IMPORT_C void SetHandler(MRgcpHandler* aHandler); // Initialization

IMPORT_C void SetGdpProtocolL(RGsdpSession::TGdpProtocol aGdpProtocol);

// State inline TState StateQ const; inline TBool IsBlankQ const; inline TBool IsInitiatingQ const; inline TBool IsIisteningQ const; inline TBool IsRespondingQ const; inline TBool IsRequestingQ const; inline TBool IsWaitingQ const; inline TBool IsBoundQ const;

// State transition functions

IMPORT_C void Initiate(const TDesC& aOtherAddress);

IMPORT_C void ListenQ;

IMPORT_C void TerminateQ; IMPORT_C void SendResponse(TInt aOpcode, const TDesC8& aData);

IMPORT_C void SendResponse(TInt aOpcode);

IMPORT_C void SendResponseO;

IMPORT_C void SendRequest(TInt aOpcode, const TDesC8& aData);

IMPORT_C void SendRequest(TInt aOpcode); IMPORT_C void ResendQ;

// Persistence

IMPORT_C void ExternalizeL(RWriteStream& aStream) const;

IMPORT_C void InternalizeL(RReadStream& aStream);

IMPORT_C TStreamld StoreL(CStreamStore& aStore) const; IMPORT_C void RestoreL(const CStreamStore& aStore, TStreamld aStreamld);

// Access to GSDP stuff inline const RGsdpSession& GsdpQ const; private:

// Help with sending void DoSendRequest(TInt aOpcode, const TDesC8& aData); void DoSendResponse(TInt aOpcode, const TDesC8& aData); void DoTerminate(TBool aClientlnitiated);

// Handle incoming datagrams void GsdpHandleL(const TDesC8& aData); void CrackPackefL(const TDesC8& aData, TInt& aSeqNo,

TInt& aResponseOpcode, TInt& aRequestOpcode); void HandlePacket(TInt aSeqNo,

Tint aResponseOpcode, Tint aRequestOpcode); void HandleTerminateRequestQ; void HandlelnitiateRequestQ; private:

TState iState;

RGsdpSession iGsdp;

MRgcpHandler* iHandler;

// Send apparatus Tint iNextSendSequenceNo;

RDesWriteStream iSendWriter;

TBuf8<KMaxGsdpData> iSendBuffer;

// Receive apparatus

Tint iLastReceivedSequenceNo; TBuf8<KMaxGsdpData> iReceiveBuffer;

TBuf8<126> -Response; // Rather wasteful

TBuf8<126> iRequest; // Rather wasteful

};

The main functions are:

Function Description

ConstructLQ Construct the session class, specifying a game protocol.

Internally, the function constructs an RGsdpSession object for communicating down the stack.

SetHandlerQ Sets a handler for incoming packets. Prior to setting the handler, you can store and restore state, but cannot invoke any communication functions. Specify 0 to unset the handler: communications functions will be stopped (without issuing a Terminate Q). Specify a non-zero value to set a handler: if the state demands it, a GSDP ListenQ will be issued. SetGdpProtocolLQ Set the GDP protocol to be used. State 0 Get current state. A group of IsXxxQ functions also allow you to test whether the session is in a particular state. IsBoundQ is included, to mean any of responding, requesting, or waiting.

Initiate Q Valid only from blank state. Specify the other address, and the state changes to initiating. An initiate request with zero sequence number is sent to the other address in a GSDP datagram (together with a null response). The datagram is held in the re-send buffer

ListenQ Valid only from blank state. State changes to listening. TerminateQ Valid from any state. From bound states, sends a terminate request to the other partner. State changes immediately to blank. The handler function RgcpTerminatedQ is called.

SendResponseQ Valid only from responding state. State changes to requesting. Specify an opcode and data up to 126 bytes in length. If specified, the opcode must not be one of those reserved by RGCP. An overload with no data parameter is provided: the data defaults to 0 bytes. A further overload with no opcode parameter can be used to generate a nώiimal response with no opcode.

SendRequestQ Valid only from requesting state. State changes to waiting. Specify an opcode and data up to 126 bytes in length. The opcode must not be one of those reserved by RGCP. An overload with no data parameter is provided: the data defaults to 0 bytes. The previous response (and this request) is sent in a single GSDP datagram. The datagram is held in the re-send buffer.

ResendQ Valid only from initiating and waiting states. Re-sends the last GSDP datagram from the re-send buffer. ExternalizeLQ Externalize state to stream, including all GSDP information and the re-send buffer.

InternalizeLQ Internalize state from stream, including all GSDP information and the re-send buffer.

StoreLQ Store state by creating a stream, externalizing, closing the stream, and returning its ID.

RestoreLQ Restore state by opening the specified stream, internalizing from it, and then closing the stream.

GsdpQ Get a const version of the underlying GSDP session, so that GSDP settings can be interrogated.

Here's MRgcpHandler's declaration in C++: class MRgcpHandler

{ public: virtual void RgcpHandleResponse(TInt aOpcode, const TDesC8& aData) = 0; virtual void RgcpHandleRequest(TInt aOpcode, const TDesC8& aData) = 0; virtual void RgcpHandleTerminated(TBool aClientlnitiated) = 0; virtual void RgcpHandleBoundQ = 0; virtual void RgcpStartRequestingQ = 0;

};

MRgcpHandler includes the following functions:

Function Description

RgcpHandleResponseQ Handle response. Called in waiting state, this function takes opcode and data parameters. If the response was null, the opcode passed to this function is zero. After this function returns, state changes to responding (unless you called TerminateQ to set the state to blank). RgcpHandleRequestQ Handle request. Called in responding state, this function takes opcode and data parameters. You can call SendResponseQ from within this function to send a response. If you do not call SendResponseQ, then after this function returns, a default null response will be constructed. After this function returns, state changes to requesting (unless you called TerminateQ to set the state to blank).

RgcpHandleTerminatedQ Handle termination. Called in any state (except blank). Takes a parameter indicating whether the termination resulted from a client API call, or in response to a terminate request received from the other partner.

RgcpHandleBoundQ Handle session binding. Called in initiating or Ustening states. If called in initiating state (because an initiate- response was received), then state afterwards changes to responding (unless you called TerminateQ to set the state to blank). If called in listening state (because an initiate- request was received), then state afterwards changes to sending (unless you called TerminateQ to set the state to blank) .

RgcpStartRequestingQ Called when the state has changed to requesting. May be used to set an indicator to indicate the state transition. May be used to generate a synchronous request. You cannot generate such a request from RgcpHandleBoundQ or RgcpHandleRequestQ.

3.5 Taking RGCP Forward

RGCP's manual resend system and response piggybacking are tailored to the requirement of relatively expensive protocols, to avoid sending more datagrams than necessary. For protocols such as infrared, which are fast and free, this is too heavyweight. It produces the oddity that, when playing Battleships over IR, you don't see a response to your move until the other player has decided what move to take. That is OK over SMS, but over infrared it feels odd. It would be possible to add either another layer, or a fairly compatible modification, to RGCP:

• This could allow responses to be sent immediately, without waiting for a piggyback packet

• Given the possibility of an immediate response, require an immediate response in some situations and, if one does not arrive, re-send automatically

4. BSP

BSP, the Battleships Protocol, builds on RGCP to allow players to play the two-player game. Within the span of a single conversation (or 'session'), multiple Battleships games may be played. Outside a session, you cannot play a game. A session is set up by one partner initiating and the other listening. Partners specify whether they want to move first, or move second, or don't care. The decision is arbitrated in favour of the initiating parmer (who will go first if they so requested, or if neither party cares, or if the other partner asked to go second). Normal play consists of a sequence of move requests. The game may be finished by being won by one partner (and therefore lost by the other), or the player whose turn it is to move may abandon it. If the game is finished in either of these ways, the session remains active and another game can be started. This time, the player who lost or abandoned gets preference of first move. The RGCP session may be terminated, at any time, which of course terminates any game currently in progress.

4.1 BSP — Battleships Protocol This is a sample protocol for a Battelships game utilizing the TOGS stack.

4.2 States

The possible states of a Battleships application are: State Meaning blank No conversation is established. The game is in an arbitrary state (either a neutral state if the program has just started, or the state at the end of the last game if a conversation has been terminated).

Initiating You have chosen whom to play against, and initiated a conversation with them. You have also specified your first-move preferences. The game is initialized to a neutral position.

Listening You have chosen to play and are waiting to accept a conversation initiated by someone else. You have also specified your first-move preferences. The game is initialized to a neutral position.

Starting You are bound in a session and have sent a start request to the other player, specifying your first-move preferences. The game is initialized in a neutral position.

Accepting You are bound in a session and are expecting to receive a start request from the other player. You have specified your first-move preferences and the game is in a neutral position. my-turn A game is in progress, and it's your turn to move. opp-turn A game is in progress, and it's your opponent's turn to move, finished The game has been won, lost, or abandoned (which amount to sub-states of finished).

Restarting You are going to restart the game, but you don't yet have your first move preferences.

The game transitions are shown in Figure 16 and are described in more detail below:

From To Occurs When blank initiating Player specifies first-move preferences and the address of player to connect to. An RGCP initiate-request is sent. blank listening Player specifies first-move preferences and starts RGCP listening. listening starting RGCP initiate-request is received and a response sent, so that the RGCP session is bound. You send a start-request, specifying your first-move parameters. initiating accepting RGCP initiate-response is received, so that the RGCP session is bound. accepting my-turn You handle a start request from the other player. You arbitrate who has the first turn, and it's you. You send a start-response indicating this. accepting opp-turn You handle a start request from the other player. You arbitrate who has the first turn, and it's the other player. You send a start- response indicating this, and then immediately send a no- operation request. starting my-turn You receive a start response from the other player that indicates you have first turn: the next request from the other player will be a no-operation request. starting opp-turn You receive a start-response from the other player that indicates the other player has first turn: the next request from the other player will be their move request. my-turn opp-turn Through the GUI, you specify a move: this is composed as a move request and sent to the other player. opp-turn my-turn You receive a move request from the other player, to which you respond. my-turn finished You abandon the game: you send an abandon request to the other player. opp-turn finished You receive a move request that causes you to lose the game (in which case you immediately send a move-response and a no- operation request, so the other player knows they have won); or you receive a move response indicating that you won the game; or you receive an abandon request. finished accepting You are in BSP finished state and RGCP requesting state. This can happen because the other player abandoned, or you won. Through the UI, you specify your first-move preferences. You send a restart request with no parameters. finished restarting You are in BSP finished state and RGCP waiting state. This can happen because you abandoned, or you lost. You receive a restart request from the other player, to which you respond.. restarting starting You have first-move parameters from the UI. You send a start request specifying your first-move parameters any blank You terminate the game, or you receive a terminate request from the other player to terminate it. If you terminated the game, you send an RGCP terminate request to the other player.

BSP combines a multi-game session protocol with the specifics of the Battleships game. It would be possible to separate out these aspects into two layers. A truly general protocol may or may not be worthwhile: other games could re-use BSP's patterns without re-using its code. In any case, patterns differ between games. A game that can be tied, for instance (as opposed to only won or lost), may require a different approach. It would be possible to improve on the first-move selection here, by changing only the UI, to select random first- move preferences. BSP itself would not have to be altered. 5. Taking TOGS Further

5.1 Chat Channel

BSP is sufficient to implement the rules of Battleships and to make the game playable. But a game of Battleships played between two players in a room, using old-style paper-and-pencil methods, would not be simply a set of hit requests and responses. There would be comments, taunts, discussions about when to play the next game, etc. Chat adds to the psychology and interest of a real Battleships game, just as much as user-controlled fleet layout. It would be attractive to build in a chat channel to Battleships to support this kind of chat. However, BSP is built on RGCP — a conversational protocol in which players take it in turn to send and receive messages. That is basically unsuitable for chat. A favoured scheme to implement a chat channel would be to implement it at the GSDP level, so that the Battleships game has another connection to the GSDP server. That is easy — EPOC's client-server architecture supports multiple independent connections from any thread.

At the UI level, there would be no need to alter the start-new-game dialog (chat initiate/listen details are the same as for the game). The view would have to be altered to include chat data — or, as in tpg, a multi-view approach could be used. The persistent form of the game would have to be altered to include a log of chat — perhaps on a different stream from the main game data, so that chat could be added optionally without breaking the format of existing games. With this scheme, each chat message would be a different GDP datagram from the datagram containing each BSP response/request pair. That's unfortunate, because of the real cost of a text message. There are many options for addressing this:

• Do nothing: the user pays the cost of each message, but no higher-level protocol needs to be altered • Save datagrams at connection time: you do not need to send two initiate packets. In the BSP initiate packet, send the initiating partner's GSDP port ID allocated for chat, and in the BSP initiate-response, send the listening partner's GSDP port ID allocated for chat. This relies on GSDP's support for allocating a port ID without participating strictly in the initiate/listen protocol. • Save datagrams at hit-request time: include an optional message with each hit request, and also with the initiate request.

• Low-level protocol piggy-backing: implement a completely different piggybacking and reliability scheme than that supported by RGCP, which takes the chat requirement into account, and optimizes accordingly.

The first option probably does not go far enough, while the final option is probably going too far. The middle two options require alterations to BSP, but not to the underlying TOGS protocols. If BSP is changed, then a different game protocol ID needs to be assigned, otherwise the changed BSP will not successfully interoperate with the existing BSP.

5.2 Mid-game Protocol Change

It would be attractive if the GDP protocol could be changed mid-game, so that a game could be played using long-range messaging (SMS) when the players are far apart, and short- range, free, messaging (IR) when they meet. If the GDP protocol were changed, this would imply a change in the addressing information used by the players. However, the GSDP port IDs must not be changed: they are what define the game session.

An optimal solution would involve changes at the GSDP level, if only for proper encapsulation.

5.3 Better Capability and State Support in TOGS

A characteristic of protocol stacks is that they don't represent complete encapsulation. For instance, it does not make much sense to use RGCP without being aware of the underlying realities of GSDP and GDP, even perhaps the realities of a particular GDP protocol. RGCP adds value to these layers, but does not entirely encapsulate them.

As a consequence, an RGCP application such as Battleships needs access to the underlying specifics. For instance, is the current GDP protocol networked, and does it require receive- all? What GDP protocols does the GSDP server support? How can I set, store, and restore a particular GDP and GSDP configuration?

At the moment, TOGS handles these issues with ad-hoc exposure and pass-through of getter and setter functions up and down the stack. A better system would be to use the capabilities pattern at each level:

• Define a struct that includes all capability and setting information for a given level

• Define getter and setter functions for this struct, which change its members

• Define getter and setter functions for a protocol level, which get a struct from the level's current settings, or set the settings from the values in a struct

Clearly, a different struct would be required for each level in the protocol stack. The capabilities pattern is particularly worthwhile for a protocol layer with many capabilities, especially if that layer often resides towards the bottom of a stack.

5.4 Other Games TOGS is not designed for Battleships alone. Any turn-based game could be implemented on a TOGS stack, using GDP, GSDP, and RGCP unchanged, but replacing BSP and the Battleships game.

Suitable games would include Chess, Checkers (Draughts), Backgammon, Tic-Tac-Toe (Noughts and Crosses), Connect Four, Scrabble, and many other games, including two- player card games.

The developer investment required to produce a good game on top of TOGS is not high, since you do not have to build in the intelligence required for a human-versus-computer version of these games. You only have to specif and implement the protocols required to communicate moves, the rules needed to referee attempted moves, and a GUI. Other games will probably use a variant of BSP. However, the details will be subtly different. Board games are based on a single shared game state (the board and pieces on it) that is public to both players. Battleships is a game of two halves, in which each player's initial fleet disposition is initially unshared, but as the game progresses it is selectively revealed to the other player. Many games include some combination of shared state and unshared state. In Scrabble, for instance, the knowledge of your letters is private to you, the unused letter pool is unknown to anyone, and the board state is completely public. Many card games rely on guessing unshared state for much of the interest in the game. The whole intrigue in multi-player Diplomacy (though not the two-player version) arises from selective, and not always truthful, sharing of state between players.

The degree of shared state will have some effects on your game protocol. A key rule in gaming is to n__inimize disclosure — that is, do not share things at the protocol level and hide them at the UI level. For instance, in Battieships, it would be possible to exchange the entire state of each player's board at the beginning of the game, so that the response to hit requests could be instant. But then a knowledgeable player could find out the state of the opponent's game, and win in 20 moves.

5.5 Single-player Games Solo Ships was an attractive and useful single-player version of Battleships — possible because Battleships is really two half-games.

Another single-player form of Battleships would involve the computer as a genuine opponent. The basic game design would use two CGameEngines, but only one CGameAppView. Instead of having an app view, the other engine would have a CGameComputerPlayer, which would make hit requests on behalf of the computer.

For a minimum level of skill, the computer player could make random hits on unknown squares. The engine includes some trivial logic to mark squares as sea, if they are diagonally adjacent to partial known ships, or directly adjacent to complete known ships, so random hits on unknown squares would not be a bad start for the computer player. For a greater level of skill, the computer player could treat Battleships as a constraint satisfaction problem (CSP), a standard form of problem for which artificial intelligence research has developed many general methods. A little data from a few hits will generate enough constraints that a CSP approach can considerably improve on a purely random hit request. And a carefully chosen initial hit strategy will do better than a purely random initial hit strategy.

Many of the two-player games mentioned above could be improved by the addition of the option for a computer opponent. In the case of the more complex games, such as Chess, the barriers to entry are high, as engines suitable for deployment on EPOC already exist, and have in some cases been ported from bodies of code that have evolved over two or three decades.

5.6 Infrastructure Improvements

Besides improving the game — or using a different game — there are many things we could do to improve the facilities for games in general, as provided by both EPOC and the TOGS stack.

EPOC Release 5 and TOGS as they stand provide an attractive enough platform for turn- based games played at both short and long distance. Probably, the attraction of the longdistance option is limited by the trickiness involved in using GDP-SMS. In future EPOC releases, with much better integrated phones, SMS and other text messaging protocols will become transparently easy to use, which will boost the appeal of TOGS-based games enormously. In forthcoming releases, EPOC will begin to use Unicode. TOGS has done all that is sensible to prepare for Unicode, but has taken an inactive approach to converting between character- and byte-oriented data. That will need addressing for real Unicode builds.

TOGS is designed specifically for two-player turn-based games and can also support two- player chat. For multi-player games, or for real-time games, GDP and GSDP will still be useful, but alternatives to RGCP, tailored for multi-player or real-time requirements, will be needed. Some GDP implementations are clearly more suitable than others for real-time: any kind of pull protocol (such as receive-all for GDP-SMS) is clearly ruled out.

EPOC will also include a media system with better sound facilities and, eventually, support for an increasing range of graphics and video formats. This has obvious application to games. In the longer term, it is possible that many aspects of EPOC's architecture may evolve to support real-time games: this requires sound, graphics, and communications improvements, some of which will be delivered in software, some on silicon. Here are some more ideas for taking TOGS forward with EPOC.

5.7 Better Long-distance Messaging

GDP-SMS provides a messaging transport that shows the viability and usefulness of long- range wireless messaging. It is the cheapest and fastest way to send a message to another EPOC machine, using only a mobile phone to access a communications network. Ultimately, the UI behind this kind of messaging will be very simple, because the phone metaphors (initiate = send first message, listen = wait to receive first message, address = phone number) are well understood by end-users.

Presently, there are a couple of rough edges on GDP-SMS:

• The user has to pull messages, using Receive All, rather than having the network and system push them

• The user has to be careful to set up the phone and the EPOC machine so that GDP-SMS can link correctly to the phone, both for sending and receiving messages

• Receive All marks non-GDP messages as 'read' • SMS is supported only on GSM networks

More tightly integrated telephony will address push, setup, and the distinction between GDP and other messages.

In the SMS world, Nokia has defined Smart Messaging protocols which could be exploited to deliver a much more satisfactory method of distinguishing between GDP messages, end- user text messages, and other types of Smart Message.

Smart Messaging is a solution for today. In the near future, WAP's wireless datagram protocol (WDP) is a better and more general solution. WDP, like all aspects of WAP, is bearer-independent, and so will support other bearers such as North America's TDMA. When EPOC includes WDP support, it will be an excellent basis for GDP. EPOC will also deliver its own bearer-independent messaging infrastructure designed to ensure that an even wider generality of incoming messages are routed to the application that is intended to handle them.

5.8 Better Short-distance Messaging

The IR implementation of GDP works very well, and enables two players in the same room to have a good game of Battieships.

One oddity that end-users notice when playing Battleships over IR is that you don't get the hit response immediately — only when the other player takes a turn. That makes sense in the case of SMS, where you're not in direct touch with the player and can't distinguish between time being used to send a message, and the time the other player needs in order to think about their next move.

But in IR, the economics and the game dynamics are different. This led me to propose an enhancement which uses time-outs for acknowledgements, and doesn't piggy-back responses, for use when appropriate for the GDP protocol. I dubbed this enhancement QRGCP.

When EPOC supports Bluetooth short-range messaging, a GDP-BT driver would make a very nice addition to the suite.

We decided that GDP-IR was a point-to-point protocol, even though IrDA supports a kind of networking with addresses valid for a session. The decision for IR was easy: addresses are user-hostile, and the line-of-sight requirement has a clear end-user meaning in relation to a point-to-point connection.

With Bluetooth, the decision will be more difficult. The whole point of Bluetooth is to enable piconets to be setup up between multiple devices in sub-10-meter proximity but without line-of-sight communication. During the lifetime of a piconet, Bluetooth nodes enter and exit in arbitrary sequence. During the lifetime of a particular set of nodes in a piconet, each node has a fixed address — but that address has no lasting meaning, and is probably even more user-hostile than the addresses used in IrDA. GDP-BT will probably need to be a networked GDP protocol, and will need to use a friendly form of EPOC machine address rather than the transient Bluetooth node address.

5.9 The clipboard (see baclipb.h, the source code for Word application, and documentation in the EPOC SDK).

Sending a datagram is equivalent to pasting to the clipboard. Clipboard text can be copied into an e-mail, sent to any internet e-mail address, received onto an EPOC machine, and copied from the e-mail to the clipboard. Receive all is equivalent to checking the clipboard for GDP data and copying it if some exists. The clipboard file could possibly be monitored so that explicit GDP receive-all isn't needed: if the clipboard is monitored, a system for preventing undesired immediate local loopback is needed.

Claims

1. A wireless information device programmed with client software including a first application, the first application being able to communicate using datagrams with a second application or applications located either on the device itself or elsewhere, with the communication taking place using a bearer in accordance with one or more bearer protocol interfaces, in which the device comprises a software server to mediate the communication between the first application and the second application and to control the selection of the appropriate bearer protocol interface, characterised in that:

(a) the bearer is treated as connectionless and unreliable, and

(b) a server interface to the client software is session-based but unreliable, and is independent of the bearer.

The wireless information device of Claim 1 in which the server interface to the client software allows the session state to be stored to file, and later restored.

3. The wireless information device of Claim 1 or 2 in which the server supports at least two of the following bearers: IrDA, Bluetooth, WDP, datagram or SMS text messaging on GSM, datagram or text messaging on CDMA, datagram or text messaging on D-AMPS, datagram or text messaging on W-CDMA.

4. The wireless information device of Claim 3 in which the server supports one bearer which is free at the point of use, including IrDA, Bluetooth; and another bearer which is not free at the point of use, including WDP, datagram or SMS text messaging on GSM, datagram or text messaging on CDMA, datagram or text messaging on D-AMPS, datagram or text messaging on W-CDMA.

5. The wireless information device of any preceding claim in which an intermediate software between a main application logic and the server interface to client software adds reliability, and/ or constrains the application-to-application communication to be of a conversational nature.

6. The wireless information device of Claim 5 in which the intermediate software allows its state to be stored to a file, and later restored.

7. The wireless information device of Claim 5 in which the intermediate software adds reliability, constrains communication to be of a conversational nature, and packs requests and responses into a single datagram so as to minimize usage charges where these may be incurred by a particular bearer.

8. The wireless information device of any preceding Claim in which an application is one of the following: a two-player turn-based game, a two-player real-time game, a multi- player turn-based or real-time game, chat, data stteaming, digital cash, digital loyalty schemes or other business application.

9. The wireless information device of Claim 8 in which the first application is a two- player game or a multi-player game, and one or more of the players is computer software rather than a human end-user.

10. The wireless information device of any preceding Claim in which the server interface to client software allows multiple concurrent applications of different types, or the same type, to run simultaneously.

11. The wireless information device of any preceding Claim which sends data to and receives data from a remote hardware server.

12. Computer software which when running on a wireless information device renders that device a wireless information device as claimed in any preceding Claim.

13. Computer software carrier media programmed with the software of Claim 12.