Chapter 1

Appendix 3: TOGS Guide and Reference
Overview
In this appendix, I describe the main constituents of TOGS – Transaction Oriented Games
Stack:
� GDP, providing unreliable datagram service
� GSDP, adding sessions
� RGCP, adding reliability and request/response conversation support
� BSP, implementing the processing for Battleships.
I'll describe each of these protocols in the following way:
� Introduce it and say why it's there
� Describe the protocol in the abstract
� Outline the Symbian OS implementation
� Point out what future development is needed on this protocol.
GDP
GDP is the Game Datagram Protocol. Its purpose is to provide the simplest possible
interface for sending and receiving packets of data. As a client, you call a SendL() function,
specifying a to-address and some data – a datagram (see Figure A3.1). A GDP
implementation transfers this packet to the target address, where software executes a
GdpHandleL()function whose parameters include the from-address and the data.
Figure A3.1
The address received by GdpHandleL() should be such that it can be used to generate a
reply to the sender.
The address format is defined by the GDP implementation. A networked GDP
implementation requires addresses. A point-to-point GDP implementation doesn't require
addresses: it relies on physical connectivity to get a datagram to the other endpoint. Both the
SMS and Bluetooth protocols are address-based. Clearly, loopback is a point-to- point
protocol.
GDP is not limited in its application to Symbian OS machines – a GDP implementation may
communicate with machines running other operating systems as well. For this reason, a
concrete GDP implementation should specify its physical data formats with sufficient
precision for another system to be able to implement a corresponding GDP stack that
connects to it.
GDP is unreliable. That means a request through SendL() is sent on a best-efforts basis,
but it's 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 for these events to its clients. However, GDP should make
reasonable efforts and it should be possible for the end user to understand its reason for