The decision to make the main server concurrent was a simple one, given that it had to be able to deal with many requests, each of which -- depending on the map used -- may take a significant time to process. A concurrent server algorithm would also allow the system to scale properly on powerful hardware.
Initially, a TCP implementation was chosen, because the majority of clients would connect across the busy Internet, making a reliable connection essential and the overhead worthwhile. However, later on in the project, after the basic code structure had been developed (see Section 2.4.3), UDP capability was added. This would allow, for example, ticket-machines connected on their own, quiet network to communicate with the server in the most efficient way.
The final major consideration in designing the server algorithm was how to separate administrative connections. This could be done by treating all connections the same, and building administrative commands into the communication protocol2.6, but this would not be secure. Instead, the server was designed to listen on two different port numbers, one for administrative connections and one for end-users. Each could also be bound to particular IP addresses, allowing, for example, administrative connections only on the local network.
Therefore, the final server is concurrent, multi-ported and multi-protocol (UDP & TCP). This makes it about as general-purpose and flexible as possible and allows it to scale well.