Chapter 1

� If your request didn't get through, you can never receive a response, or another
request from your opponent, and you cannot issue another request yourself – you get
panicked by RGCP if you try, because that would violate the rules of conversation.
� If you receive a response, then that's 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's guaranteed to be the packet you sent.
� and so on: we could spell out many other particular cases.
Note In summary, GDP addresses the realities of communications, and
RGCP meets the basic requirements of application programs.
16.3.3 GSDP – Game Session Datagram Protocol
We could have written RGCP as a layer directly over GDP. Then, loopback would be useful
simply for testing GDP test code, and real communication with Bluetooth would be used for
playing a single game between two Symbian OS phones:
Figure 16.5
Admittedly you could play another game using another GDP protocol, say SMS. But having
only one game on each Symbian OS phone per GDP protocol is too restrictive.
I wanted to be able to run more than one game on each phone, each using whatever
protocol was really appropriate for it. And it would be quite nice to have a local facility, to
play a game against another program on the same machine for test or demo purposes.
So I decided to run all GDP implementations inside a server. Contrast the previous diagram
in which you can have only a single application per GDP protocol on each Symbian OS
phone (which is a restriction), with the diagram below. There you can have only a single
server on each Symbian OS phone, which shares GDP between all client applications
(which is exactly the kind of thing that servers are there for).
Figure 16.6