Chapter 1

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 don't 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 piggy-backing and
reliability scheme than that supported by RGCP, which takes the chat requirement into
account, and optimizes accordingly.
In my view, the first option isn't going 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 won't successfully interoperate with the existing BSP.
Note
Incidentally the chat requirement – whether verbal or protocol- assisted – is a
good reason for not removing the legend on the borders of the fleet view. At
first I thought those legends were redundant. But having played the game
with some humans, it quickly became apparent that without them it would be
hard to talk about the game.
Midgame protocol change
It would be nice if the GDP protocol could be changed midgame, so that a game could be
played using long-range messaging (SMS) when the players are far apart, and short-range,
free, messaging (Bluetooth) 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.
This could probably be kludged without changing TOGS, but I suspect the optimal solution
would involve changes at the GSDP level, if only for proper encapsulation.
Better capability and state support in TOGS
A characteristic of protocol stacks is that they don't represent complete encapsulation. For
instance, it doesn't 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 doesn't 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,