Chapter 1

Given that a server can share GDP implementations, the question is, how should it share?
It's easy enough to ensure that a client sending a datagram can get it to the right destination,
but what happens when it reaches that device? Which client should receive it?
The answer is that a session – a connection between two specific games – must be built in
at this level in TOGS, instead of the RGCP level (which moves up the stack). Hence the
name of this level: game session datagram protocol or GSDP. Each time a client program
sends data using GSDP, the GSDP server adds session information into the GDP packet
that is actually sent. When a GSDP server receives a packet, it interprets that session
information to ensure that the packet is routed to the correct recipient. GSDP also includes
the support for setting up a session.
GSDP is still unreliable: a datagram that is sent may not be received. GSDP also makes no
assumptions about the order in which packets are sent. RGCP, the next layer up in the
stack, adds reliability and conversation enforcement, which is useful for games like
Battleships. GSDP could also be used as the basis of other protocols that add reliability in
different ways for use by different types of application.
16.3.4 BSP – Battleships Protocol
Given that RGCP delivers reliable conversation facilities for use by games, the final task was
to specify the protocols to be used by the Battleships game itself.
I called this protocol Battleships Protocol (BSP). BSP allows you to set up an RGCP session,
and play multiple Battleships games. It supports first-move arbitration, turns as hit requests,
abandoning a game midway through, starting a new game after the previous one was won,
lost, or abandoned, and terminating a game including the RGCP session.
In fact, many of these requirements are generic, and BSP could be split into two layers – one
for two-player multigame sessions, and another for the Battleships game itself.
16.3.5 Test Programs
One of the reasons for splitting up a communications stack into layers is simply to be able to
understand each layer, and to understand the stack as a whole.
So, at each stage, we could rely on the tested aspects of our code being good, and
concentrate debugging activity on the new aspects.
Of course, in real life, the development isn't a one-way cascade. You don't catch all bugs in
your test code, and you can never expect to. Even if you do, you make feature changes at
previously tested levels of the stack. You have to go up and down the stack a few times, and
maintain your test code along with the production code.
It's a fact of life that test code tends to take shortcuts, as you concentrate your efforts on the
production code. The TOGS test code can be found on the supporting website at
www.symbian.com/books.
16.3.6 Pattern Reuse
Reuse is good for software systems: it keeps them small and enhances their reliability. In
Chapter 3, it was pointed out that sometimes you can't reuse code: you have to reuse
patterns instead.