Chapter 1

Symbian OS 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 Symbian OS
GSDP server maintains the last-allocated port ID in a file in c:\System\Data\: the port ID is
incremented and restored 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 was allocated per second, it would take over 143 years to wraparound.
Symbian OS Implementation – Client-side
On Symbian OS, the GSDP client API is defined in gsdp.h and delivered in gsdp.dll. The
client 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 (see Figure A3.4).
Figure A3.4
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's RGsdpSession's declaration in C++, showing additional housekeeping and getter
functions:
class RGsdpSession : public RSessionBase
{
public:
// construct