Chapter 1

whose settings have not yet been properly initialized. This allows the GSDP server to hold
packets for:
� a new game that hasn't been started,
� an existing game that has been closed temporarily and should be reopened.
This applies until the game has been started or reopened.
Queue management
The receive queue is a scarce resource – or, more precisely, the free slots on the receive
queue are a scarce resource. They are preallocated so that a receive operation cannot fail
because of an out-of-memory error. Precisely because they are preallocated there are not
many of them.
Important
The receive queue should manage itself carefully to ensure that
message slots are not allocated and then never freed.
This means that:
� messages that cannot match any existing client should be dropped before they are
added to the queue;
� when a client is terminated, any messages for that client should be deleted from the
queue;
� if a client fails to clear a message after a reasonable period – say, 20 s or more – then
the client is 'not responding' in the sense that users of Windows applications are familiar
with. The server should drop packets for it and should arguably panic the client.
The receive-queue management in the GSDP server follows the specification of GSDP in
Appendix 3 closely. But on reflection, that specification is incomplete and may need to be
improved to support quicker deletion of nonreceived packets. The fact that the current
specification is to keep received packets on the queue, before a game has started that can
accept them is the key item of contention here.
19.3.6 Startup and Shutdown
Earlier, we made the point that connection to a transient server was a delicate affair. We
need to connect reliably in the sense that either we succeed in connecting to the one GSDP
server, or we fail and report it to the client program. We mustn't fail silently, and we mustn't
get into any situation in which there are two GSDP servers. Part of the responsibility for this
lies with the client interface, in RGsdpSession::ConnectL() – the remainder lies with the
server startup code, which we'll now describe.
Additionally, server startup has to set up the server environment that will be used to deliver
the GSDP server's services. That means, at a minimum
� a new thread, with a cleanup stack, active scheduler, and CServer object ready to
receive connection requests from clients via the kernel;
� anything specific that the server needs to do its job – in the case of the GSDP server,
that means the receive queue, GDP adapters, port number allocator, shutdown timer,
and so on.
If the server can't construct all this, then launch is considered to have failed. If it can
construct all this, then it's ready to receive client connect requests. Client connect requests
may fail too – but that's a different matter from server launch.
Server startup is a kind of bootstrap process involving the following general steps: