There are two principle types of sockets:

A “stream socket” is oriented around a permanent connection, and is part of the TCP protocol. This connection may bounce up and down, causing jitter, but every packet sent ought to be received in the correct order by the client system. This statement glosses over some of the more technical aspects of how this is achieved, but as far as the network library is concerned, it is more or less true. This doesn’t mean that you can dispense with logic to detect out-of-sequence packets, but in principle, they should not be prevalent in the system.

A “datagram socket,” on the other hand, is one that operates on the principle of “open, send, close.” In other words, it is not permanently connected to the remote system, and as such offers no guarantee of flow control or deliverability whatsoever. In practice, this means that if you want to build a game over UDP/IP, you need to add a layer that makes sure that the packets arrive as intended. This includes checking that they are in the right order, because the only guarantee in the UDP protocol is that if the data arrives, it will be error-free.

The networking protocols that we look at here are TCP/IP and UDP/IP. The “IP” stands for Internet protocol, and deals with routing issues, which are not covered in any detail here. They mainly concern themselves with how the data gets from A to B. We are more concerned with the data itself.

Many streaming data services, including multi-player video games, use UDP. These implementations have a layer that deals with the vagaries of the UDP protocol. UDP can be very useful simply because no connection is needed, rather than despite it. Due to this, we care much less about things like dropped packets and jitter because UDP is part of the equation. In many ways, UDP makes the whole networking paradigm easier to implement, as long as we accept that there will be some natural wastage in the information exchange.

This means that we have to explicitly compensate for the following:

As long as we can compensate for this inherent lack of a permanent connection (by only exchanging data in very small, isolated chunks for example) then UDP is a great protocol. However, if we have to exchange larger, more frequent chunks of data, then the TCP protocol offers much better intrinsic flow control.

Naturally, TCP does have some overhead, which might make it less attractive, but this overhead is there to make sure that the data arrives correctly. This is vital for things like Web pages and MUDs, where any loss of information means that the page or displayed data is corrupted.

For a game like Quake, however, it can be relatively unimportant that there is the occasional bit of lag, network latency, or dropped packet causing jitter because it can be compensated for. Academic studies (for example, “The Effect of Latency and Network Limitations on MMORPGs” by Tobias Fritsch, Hartmut Ritter, and Jochen Schiller [FRI01] show that players are very resilient (and tolerant) toward these kinds of issues, as long as the outcome of the game is not unduly affected.

In short, as jitter and latency increase, the game flows less and less well—but players are willing to put up with an enormous number of problems before they abandon the game completely. It’s nice to know, but not something we should build into our network handling; we must always strive for the best communication possible.

In addition to the two protocol types, there are also two ways in which we can use sockets:

We deal with these in detail later on; for now, we should just mention that blocking sockets are the usual default. The problem is that lots of functions used in socket programming run the risk of blocking the sockets.

The worst-case scenario is that a program can find itself in a busy waiting loop, blocking the socket even when there is nothing to do, as control will not be returned to the program until data arrives to be processed. One way of avoiding this is by using non-blocking sockets. Non-blocking sockets are simply not allowed to block. Each call to the socket will return regardless of the presence of data. This has its own problems, however, as polling for data in this way eats up CPU time. We look at some ways to make the polling process slightly more efficient later on in the chapter.

There is, however another option, called “multiplexing.” Multiplexing means that you need only to monitor a set of sockets, and then send or receive over the ones that actually have data. This removes the risk of causing a block on one of the sockets, and removes the need for using CPU-intensive non-blocking sockets.

Multiplexing is necessary for server applications or smart clients having more than one socket connection. For example, any system that is communicating with multiple remote hosts will benefit from multiplexing, but it is less necessary for clients that are running one connection, as they can use non-blocking sockets.

The point is this: The game should never, as a client or a server, get stuck in a loop waiting for data, because if it does so, there is a risk that nothing else in the game will be able to run. No more screen updates, database accesses, or serving other clients. Blocking is bad and has to be avoided at all costs.

The socket is at the sharp end of the network programming paradigm. It is the point of communication with the outside world. However, the data itself has to be correctly presented to the interface for the network communication to work.

For each protocol that is used (TCP, UDP, IP, etc.), the data needs to be correctly encapsulated. This essentially means that the data is put into an envelope, with the envelope itself containing information that is pertinent to the network protocol but not necessarily to the game. For example, the envelope might have instructions as to what to do with the data, usually contained in some kind of header, when it is picked apart by the recipient. This might include specific encoding, encryption, or in-game identification data. The outermost layers (envelopes) contain address information so that the transport layer knows what to do with the packet of data. This is depicted in Figure 10.1, which shows layers of data encapsulation.

Figure 10.1. Packet headers and layers.

Figure 10.1 is a very simplified representation of the layers that are involved in network communication. There can be more or fewer layers, some added by the protocol (networking) library, and some that are proprietary to the game itself.

At the heart is the payload data, which is then usually encapsulated in a layer that is part of the game logic. This inner envelope may or may not be present, depending on the complexity of the error checking and security that is deployed. Then the resulting data is treated as payload and encapsulated in a layer that is used by the network to deliver the data to the end point. To understand this separation more fully, we can look at the OSI Layered Network Model in gaming terms:

In this book, we deal with issues at several levels of this list, but not the physical, data link, or network layers. These are transparent to the network game developer. We are more interested by the logical representation of the data. The implementation of the transport and session layers are also usually transparent but included in the networking code supplied by the API developer. For PCs, the network is handled by the operating system, with drivers supplied by the network equipment manufacturer. The code-level interface to the hardware is standardized. For other platforms, the development kit supplied by the platform manufacturer will supply appropriate code used to access the specific hardware.

The presentation layer also deals with various encryption issues that we need to prevent cheating and ensure robustness as well as identify packets and check for out-of-sequence packets. These can also be a good clue as to whether there is some underhanded play going on (see Chapter 8, “Removing the Cheating Elements”).

Finally, the application layer deals with how the data is represented by the game. At this level, we are concerned with the various compression and data-decoding standards that we have used for the representation of state information in the game, and so on.

So, we build the data in the application core, then pass it to the code that represents the presentation layer (proprietary). Next we must make a call to the underlying operating system (or equivalent), giving it enough data that it can process the request. Everything else from the session layer down to the physical layer ought to be dealt with by the network library. Part of that responsibility might be in a third-party library, and some will be in the manufacturer’s own driver and development kit.

The smallest unit of communication is the socket, and provides the logical bridge between the game world and the real world.

Generally speaking, these are “listening” sockets. This means that they do nothing until data arrives, at which point the data is decoded, processed, and an answer sent, if one is available. Of course, game servers may also need to broadcast information from time to time, but they can only do this if a connection is available (a TCP stream, or previous UDP connection). Part of the server’s responsibilities, therefore, includes processing incoming data and multiplexing to make sure that no incoming updates are missed, whilst not blocking any of the pending communications.

Using a request-response mechanism simplifies things because it allows the client to indicate that it is ready to receive an update, whilst also flagging to the server that it needs to perform some processing. If the game developer chooses to allow broadcast updates over UDP (as opposed to request-response over TCP), then the control algorithms become more difficult to implement. Part of this is being able to match the incoming data with the game state and preparing some kind of response having updated that game state.

There will be times when there is so much going on that this becomes difficult, and the temptation is to allow the clients to present the results of the actions rather than working it out on the server. The networked versions of Civilization use this approach. Since the game logic is present in the clients anyway, it seemed logical. However, it does open the doors for cheating, because if the data can be unraveled, fake updates can be passed to the server. These are hard to catch, because the server does not maintain the same level of detail, nor do any of the processing.

So, however hard the implementation seems to be, it is worth making a robust server-side algorithm that can match game states properly and simultaneously handle the network connections to prevent the above scenario.

Finally, having worked out the appropriate response, the server has to have a mechanism for sending data—more importantly, sending the right data to the right client, at the right time. This is also something we deal with in this chapter.

On the face of it, the client side is much easier to appreciate. After all, all it needs to do is open a socket, send the data, and wait for a response. However, it also needs to maintain a hard real-time application and cope with network problems, whilst simultaneously accepting input from the player.

The network-communication programming is therefore the smallest part of the equation, but also has some important challenges of its own to contend with. These include response matching—which is made easier if a strict request-response mechanism is used, and only slightly more tricky if broadcasts are allowed—and inter-client communication.

In principle, the server is constantly polling to see if it has to do anything. This does not just include the network layer, as it may be polling for a number of reasons:

And polling can happen at many levels—from the system down to the interactions between clients. After all, it is no good for the game server to be able to play out the in-game decisions if the database falls over, so some polling selection needs to take place.

One part of the system should be able to choose (intelligently, we hope) between different things to poll, at a high level. This might need to be weighted according to activity in different areas of the system as a whole. Those things can select further children to perform polling for them, eventually winding up at the game-environment level, where polling for specific in-game events takes place. In this model, the game itself is just one part of a much larger system that needs to be maintained in real time. The lowest-level actors in the system then need to poll hardware (for example), connections (such as network sockets), or software event queues. Everything is governed by the need to poll specific areas at specific times.

The polling frequency might change depending on changes in the system as a whole. Intelligently scheduling polling activities and splitting the load according to actual activity is something that might be less important for some games than others. The most complex environment will be clustered servers (such as those used for Eve Online), where the communication between servers can be as important as the communication between client and server.

This means, for example, that if the network is not active, the scheduling system might choose to poll it less than another, more urgent, aspect of the system. The polling mechanism itself then needs to be applied across the various system services (i.e., sockets, in this case) to determine whether there is any work to do.

Those, in a nutshell, are the server side–polling challenges. The client side is not nearly so complex an environment.

Client-side polling is really only about the game on the one hand, and the network on the other. Leaving aside the game itself, as the game is beyond this book’s scope, we shall concentrate on the polling mechanisms that enable the network and multi-player aspects of the game.

If a request/response architecture that only reacts to the player is used (i.e., a Web game), then a robust polling mechanism might not even be necessary. After all, these tend to be oriented toward the player scheduling the action as opposed to being a flowing gaming experience, due to the nature of the connectionless communications medium. (A side note: AJAX can be used for asynchronous game-environment polling, if that proves to be something that the game developer wants to offer. In addition, games that are played through the browser, such as Adobe Flash games, are grouped together with traditional networked games for the purpose of this discussion, and will definitely need a robust polling mechanism.)

A network game client might poll for one of the following reasons:

At the same time as the network polling is going on (i.e., asking the game server for updates and monitoring the connection for replies), the client also has to continue playing the game. This includes rendering the results of the last round of data that came in in response to polling the server, and polling the player for reactions to that rendering.

So, the scheduling mechanism will also have to deal with the possibility that the client is not polling the game server uniquely—i.e., it will need to poll other, related services in order to manage all the system tasks. These system tasks then process in a sequential fashion, as does the polling mechanism itself.

As an illustration of polling, we are going to tie it in with the subject of this chapter: network programming. A server, after all, has to have a good way to poll multiple network connections, even if multiplexing is being used.

We will cover the implementation of multiplexing in the next section; for now, you can assume that the result is a list of sockets that have data waiting on them that can be polled to retrieve that data. This actually solves half the problem, as you don’t strictly need to poll anymore, but just process the data in a logical order.

The basic model that we use is called “round robin,” and applies equally to polling as data processing. The model is simplicity itself: Each socket is polled in turn, and data processed in a sequential pattern. Once a socket has been processed, the round-robin model states that control is passed to the next socket, which is then processed, and so on in a circle. When the last socket has been processed, then the processing begins anew with the first socket.

Whether you are polling the sockets for data or processing data that you know is there, the round-robin approach makes sure that

All of these are good. But the round-robin model has some basic flaws. Chiefly, it is possible to spend an inordinate amount of time processing small amounts of data, while “busier” sockets stack data that never gets processed. This is due to the fact that each socket receives the same level of attention, whilst it might not have the same level of activity. Put another way, assuming that we really are polling in a round-robin fashion, what happens when only one socket has activity, and 99 are dormant?

Clearly, the round-robin approach really only works in a system where all clients require equal attention, which is rarely going to be the case in a gaming system.

By way of an illustration, we are going to look at two possible enhancements to the basic round-robin scheduling model for real-time systems. These are

Both of these require that we maintain a dynamic list that gives us the order in which we will process the items. This list will change over time as the criteria for activity measurement changes the processing priority and amount of processing power devoted to each item.

Implicitly, the items at the top of the list should receive the most attention, as they are the ones with the most activity. Other than this premise, the processing is identical to the round-robin model described above.

Where the enhancements differ is in how this attention difference is applied. In the case of active time slicing, each item is specifically linked to a number that indicates the number of operations (or pieces of data) that may be processed by the system. More active items get a larger slice of processor time.

The most active–polling enhancement takes a slightly different approach, and simply returns to the most active items more often. This removes the need for an accurate time-slicing algorithm, which can become messy when a thread needs to be interrupted and suspended prematurely.

Both approaches can be fine-tuned to the game’s own requirements, and both retain the predictable essence of round-robin scheduling whilst allowing the dynamic flexibility that ensures that the most-deserving items get the most attention.

There are some special data types provided by the sockets.h library that are also duplicated in platform-specific socket application programming interfaces (APIs), such as WinSock. These contain information about the socket type, address, status, and so on. For example, there is a function that returns a socket identifier. In order to create the socket, and hence the identifier that represents it, it is first necessary to tell the network library everything about the nature of the connection.

The standard Unix data type for this information is called sockaddr_in. Other APIs will have something that is identical, or at least very similar. The Unix variant looks like the following:

struct sockaddr_in {
       short int           sin_family;   // address family,
                                            AF_something
       unsigned short int  sin_port;     // the port
       struct in_addr      sin_addr;     // the IP address
       unsigned char       sin_zero[8];  // padding
};

Windows also has an equivalent, as do other libraries; they are laid out in more or less the same way.

You will notice that the IP address is inconveniently contained inside a sub-structure called in_addr. The in_addr sub-structure is also defined in a way that makes it hard to access directly. For example, it actually contains one single member, s_addr, which is a four-byte number representing the IP address—not programmer friendly, in the least!

Luckily, however, there are a number of functions that can help us build the data types that we need, so we don’t need to become experts in translating numbers between arcane formatting specifications. The first of these functions is used to turn a string of IP numbers (i.e., 12.34.567.89) into an s_addr value, which can be placed in the sockaddr_in structure. The inet_addr function that provides this is used in the following way:

struct sockaddr_in my_socket_addr;
my_socket_addr.sin_addr.s_addr = inet_addr(' '12.34.567.89' ');

Again, notice that the actual IP address is assigned to the s_addr member of the sub-structure sin_addr, which is itself a member of the sockaddr_in structure, which is the base type of the variable my_socket_addr. It is all quite confusing at first, but the value of s_addr is the four-byte number mentioned previously.

In addition to the inet_addr function, there are some functions used to ensure that the byte ordering for numerical data types is correct. This is an important point, because the byte ordering (little endian or big endian) is not always the same from one platform to another.

So, the client and the server might run on hardware with different byte ordering, as might the development platform and the deployment platform (i.e., PC versus console). The two byte-ordering schemes are known as “host” and “network.” The four worker functions that can be used to translate between them are as follows:

So, the line of code from the preceding snippet now becomes:

my_socket_addr.sin_addr.s_addr = htonl (inet_addr(' '12.34.567.89' '));

The additional code is presented in bold font. We can also use the hton and ntoh functions with the preceding structure to, for example, set the port number correctly when the socket is created. This is the next step in building the network connection.

When we first start using the network, we need to open a socket that is bound to a specific IP address and port. The actual IP address and port that are used will depend on whether we are looking at the problem from the point of view of the client or server.

If we are writing a server communications layer, we bind the socket to our local IP address. If we are writing from the point of view of a client, we bind to a remote IP address representing the server (or another client). This IP address will probably have been obtained by calling a DNS function to convert a text address (for example www.mygameserver.com) to an IP address.

A socket is created with the socket() function, which takes a few key parameters. The first is the protocol family (PF_INET), along with the type of socket (SOCK_STREAM or SOCK_DGRAM). There is also the possibility to select a protocol, but we can set this to 0 to choose it based on the socket type. That way, the function will create a valid socket for stream or datagram communications without us worrying about what the value should be for each one.

The socket() call returns a descriptor that can be used to reference the socket. In standard implementations based on the traditional Unix model, this descriptor is just a simple integer number. This clearly limits the amount of available sockets to the size of an int at the operating system level.

The next part of the sequence depends on how you want to implement the network layer. It can be bound to a specific port or left unbound. The bind() function links the socket descriptor to a specific port. This is the equivalent of the IP:port convention used to connect to MUDs using a Telnet application:

telnet xxx.xxx.xxx.xxx:port

A socket will be associated with a port in the end, even implicitly, because it’s needed at the system level. You should remember that the port that we are talking about here is only local, and has no impact on the remote port, because that is dealt with when we actually connect to the remote system.

The calls used to bind the two together use the identifier returned by the socket function. What follows is the whole stanza in C code for setting up a socket and associating it with a port (which can then be used for calling or listening for data). Note that for the sake of clarity, we have left out the error-checking code that would normally be present to ensure that the socket has been allocated correctly, that the IP address could be found, and so on.

    // set up the socket address structure
    struct sockaddr_in       my_socket_addr;
    my_socket_addr.sin_family = AF_INET;
    my_socket_addr.sin_port = htons(PORT_NUMBER); // PORT_NUMBER
#defined somewhere
    my_socket_addr.sin_addr.s_addr = inet_addr("12.34.567.89");

    // set up the socket itself
    int socket_id = socket ( PF_INET, SOCK_STREAM, 0);

    // bind the socket, port, and address together
    bind ( socket_id, (struct sockaddr *)&my_socket_addr, sizeof
my_socket_addr);

    // put error checking here

There is one little trick that can be used with this code. If you want the system to pick a socket and local IP address, then you can specify a 0 for the port and INADDR_ANY as the address. Since these are all local values, it doesn’t really matter, unless the incoming call will be on a specific port.

connect ( socket_id, (struct sockaddr *)&remote_addr, sizeof
remote_addr);

listen ( socket_id, 10 );

    // listening_socket is an int, and has been created with a call
to socket()
    listen( listening_socket, 10); // wait for a connection
    // set up the master socket set
    fd_set master_socket_set;
    FD_ZERO(&master_socket_set); // remove any existing sockets
    FD_SET( listening_socket, &master_socket_set ); //put the
listener in the set
    max_socket_id = listening_socket; // need to track the biggest id
for select()

    // Off we go!
    while (1) {
      // copy the master list and call select
      fd_set tmp_socket_set = master_socket_set;
      select ( max_socket_id+1, &tmp_socket_set, NULL, NULL, NULL);
      // check to see if there are any "new" connections
      if (FD_ISSET (listening_socket, &tmp_socket_set)) // is it set?
      {
        // allocate a new socket id
        struct sockaddr_in remote_socket_addr;
        socklen_t addrlen = sizeof(remote_socket_addr);

        // accept the connection
        int new_socket = accept ( listening_socket,
     (struct sockaddr *)&remote_socket_addr, &addrlen);
        FD_SET(new_socket, &master_socket_set); // add it to the
master set
        if (new_socket > max_socket_id)
          max_socket_id = new_socket; // update the max
      } else { // there is no new connection on the listener
        // check the other sockets in a round-robin fashion
        for ( i = listening_socket+1; i <= max_socket_id; i++) {
         if (FD_ISSET(i, &tmp_socket_set)) // is there any data?
         {
           // read the data from the socket
         }
      }
   }
}

On the client side, we assume that the following tasks have already been carried out:

At this point, the server is listening and ready to receive data from the client. The first burst of data ought to be from the client to identify itself to the server. After this, assuming that the credentials are correct, the game dialog can begin.

Data is sent down a socket with the send() function. This acts rather like file handling, and the function takes a socket identifier (descriptor) as its first parameter and then a pointer to the data, the length, and some flags. To use these flags, it is necessary to look up the definition in the platform’s online guide (man page, or documentation provided in a Windows help file). In the following examples, we shall ignore them, and concentrate on making sure that the data is correctly encapsulated.

The easiest example is sending character data. This is no more extravagant than the following:

char szData [1024];
strcpy(szData, ''Hello TCP/IP'');
send ( sock_id, szData, strlen(szData), 0);

The send() function also returns the number of bytes sent. Clearly, this can be less than the actual number that the application needs to send, due to packet-size limitations. It is up to the programmer to send the rest of the data at some point in the future; if the packet length is set to 128 bytes, and there are 270 bytes to be sent, then three attempts will need to be made before all the data is transmitted.

Receiving data is no more complex. The recv() function, which takes the same parameters as send() and returns the number of bytes received, is used. The value of 0 is reserved for cases where the other side has closed the connection. A negative value is used to indicate an error.

On the server side, the server can do nothing until the client or clients connect and identify themselves. At this point, it can send a first update, and wait for further instructions thereafter. The same send() and recv() functions are used to do so.

Any data can be sent, be it character based or binary. However, there is a small problem with sending data such as integers as integers. Those who regularly deal with binary files on heterogeneous platforms will attest to this; it is worth taking a small detour here to examine the issue.

We shall assume that you are writing a game that distributes a level file across Unix (Mips/Alpha based) and Windows (Intel based) platforms. Furthermore, let us assume that these level files are created on the Windows platform. To identify blocks of data (records), you decided to use a length indicator of two bytes (classic integer), which will tell the reading application how many bytes are in the block, or record. This is sometimes known as the “record-length indicator.”

The following is a fairly simple C rendition of a possible function to write the data to a file, minus the error checking for clarity:

void WriteRecord( char * szRecordData, FILE * hFile )
{
  int nLength = strlen(szRecordData);
  fwrite ( &nLength, sizeof(int), 1, hFile); // write the length
      indicator
  fwrite ( szRecordData, sizeof(char), nLength, hFile); // write
      the data
}

Now, if you were to run the code on Intel and Motorola architectures, the resulting file would look very different. This is because the byte ordering is different on these two architectures. We saw this briefly above when dealing with IP addresses and port numbers: The network and host architectures may be different.

This means that, in binary, 128 bytes (for example) is represented as the following:

So, if you write out the value 00 80 in hexadecimal on the Intel platform and read it in blindly, using the fread() function, on the Motorola platform, then the result will be incorrect. In fact, it will be an integer with the value 32,768, because Motorola platforms expect the least significant byte to arrive first.

Typically, we have a lot of control over level files and where they end up. This might not be the case with network architectures because of the fact that we are likely to try to use a very powerful server, possibly running a different byte-ordering architecture, and we might not know the architectures of all the clients.

Using a similar approach as above, the following might be possible, to stream level data to a client:

// THE FOLLOWING IS A BAD IDEA
void SendRecord( char * szRecordData, int nSocket_ID )
{
  int nLength = strlen(szRecordData);
  send ( nSocket_ID, &nLength, sizeof(int), 0 ); // send the
      data length
  send ( nSocket_ID, szRecordData, nLength, 0); // send the data
}

This code will only ever work when both systems use the same byte ordering. Luckily, there are many solutions to work around the problem.

You should remember that whenever data is sent as binary information, such as int values, this problem will occur. It is much better, if marginally less efficient, to send information as single bytes and do the byte ordering in code, either using the ntohs or ntohl (and htons/htonl) functions or through a custom solution.

To send the number 128 using a custom solution, having chosen to use a two-byte scheme, the application would send 00 and then 80 (hexadecimal representation), explicitly in that order. To send a value of 256, the application would then send 01 followed by 00; the recipient would know that it should count the 255 in the least significant byte, add it to the 01, then add the 00 of the least significant byte—the value 00 FF, of course, being equal to 255. In this way, it is possible to replace any byte ordering that is implicit by platform with an explicit one.

There is another option: to tell the receiving system what byte ordering is in use by sending a character 1 or 0. The end result is the same. The receiving system still needs to compensate for an eventual mismatch, so it is probably better just to send explicitly byte by byte (or at least pack the data into a data string, and send the whole lot at once) or use the built-in byte-ordering functions.

sendto ( nSocket_ID, szRecordData, nLength, 0,
       &sock_addr_to, sizeof(*sock_addr_to));

shutdown ( nSocket_ID, 0 ); // receives no longer allowed
shutdown ( nSocket_ID, 1 ); // sends no longer allowed
shutdown ( nSocket_ID, 0 ); // sends/receives no longer allowed

close ( nSocket_ID );

The first example is a function to open a socket to a named host on a specific port. We assume that the server is a real name (like www.mygameserver.com), and therefore need to use gethostbyname() to look up the IP address.

This step can be omitted if the game infrastructure uses only a static IP address. This aside, the code is as follows:

// returns a socket descriptor, or an error code
int OpenSocket ( char * szHostName, int nPort )
{
  struct hostent *host_entry; // host entry for the lookup
  struct sockaddr_in remote_socket_addr;
  int nSocket_ID; // we'll return this, hopefully
  // look up the IP address
  host_entry = gethostbyname( szHostName );
  if ( host_entry == NULL ) return -1; // doesn't exist?
  // open a socket
  nSocket_ID = socket ( PF_INET, SOCK_STREAM, 0 );
  if ( nSocket_ID == -1 ) return -2; // can't get a local socket
  // create the remote address structure
  remote_socket_addr.sin_family = AF_INET;
  remote_socket_addr.sin_port = nPort;
  // get the IP address that we looked up
  remote_socket_addr.sin_addr = *((struct in_addr *)host_entry-
      >h_addr);
  // zero out the padding
  memset(remote_socket_addr.sin_zero, '',
         sizeof(remote_socket_addr.sin_zero));
  // connect the socket to the address
  if (connect ( nSocket_ID, (struct sockaddr
      *)&remote_socket_addr,
      sizeof(remote_socket_addr)) == -1)
  {
    // we don't need the socket anymore
    close ( nSocket_ID );
    return -3; // connect failed
  }
// finally, return the socket descriptor
return nSocket_ID;
}

You will also note that we have put in some very basic error checking to make sure that everything is correctly assigned and that all the various pieces are in place before returning the socket descriptor.

Once the socket is open, we might want to send a status request and then wait for updated information. It is assumed that the game is going to unfold using a request-response model. You should be aware that there are many other possibilities, however—for example, the server might want to pre-empt by broadcasting information. In addition, some level of probing might still be needed to ensure that all clients are still connected. In our model, however, we assume that this is dealt with elsewhere.

In addition, we are going to use a simple seeded random-number generator to try to add a little security. This is not very robust, and can be cracked, but it shows the principle of encapsulating sensitive data in an encoding scheme. The complete function is as follows:

int SendRequest ( int nRequest, int nSocket_ID )
{
  int nSeed;
  // pick a seed at random...
  srand(time(null));
  nSeed = (int) rand();
  // use the seed to encode the request
  int nEncodedRequest = nRequest;
  srand(nSeed);
  nEncodedRequest += rand() % 1000; // keep them numbers low
  // build the data string
  char szData [1024];
  sprintf( szData, ''%d|%d'', nSeed, nEncodedRequest );
  // finally, send...
  int nBytesLeft = strlen (nEncodedRequest);
  int nSentSoFar = 0;
  do {
    int nSent = send ( nSocket_ID, szData+nSentSoFar, nBytesLeft, 0 );
    if ( nSent == -1 ) return -1; // something went wrong!
    nBytesLeft -= nSent;
  } while ( nBytesLeft > 0 );
}

The kicker here is that the seed is sent as plain text, along with the encoded request, which makes it easy to crack if the encoding mechanism is known. This makes it much less secure than other possibilities mentioned in Chapter 8.

Also, you will notice that we’ve put in a little bit of code to make sure that all the data gets sent. A real implementation would probably put this in its own SendAll() function so that it could be reused across other data-sending functions.

Now that we can open a socket to an address and send a request, the next thing we need to be able to do is receive the response, decode it, and return the result. We assume that this result is an integer in this case:

int ReceiveResponse ( int nSocket_ID )
{
  char szData[1024];
  int nReceived = recv ( nSocket_ID, szData, 1023, 0 );
  if ( nReceived == 0 ) return 0; // nothing to report
  // get the seed, using strtok, and then the data
  int nSeed, nEncodedResponse;
  char * tok = strtok( szData, ''|'' );
  nSeed = atoi ( tok ); // we need error checking here!!
  tok = strtok( NULL, ''|'' );
  nEncodedResponse = atoi ( tok ); // we need error checking here!!
  // decode
  srand( nSeed );
  return nEncodedResponse % (rand() % 1000);
}

For the sake of simplicity, this code merely grabs a single blob of data. A real-world application will probably need to encapsulate that data such that there is a start and end tag that lets us know when all the data is received. Real-world data exchanges usually extend over several blobs of game-related data.

In a sense, the server is just the partner to the client, which has to be able to read the seed, determine the request, and provide the response. For these basic tasks, the preceding code can be re-used, but there are also some additional things that the server needs to be able to do—mainly because it is talking to multiple clients, whereas each client typically only communicates with a single server.

So, all of the preceding code works for the basic communication, but what about a solution for the multiple-client problem? We have seen one, using the select() function that lets us know when there is data pending that needs to be dealt with, but there are many variations on the basic theme, which we shall now put into code.

while (1) {
  select ( nMaxSocket+1, &socket_set, NULL, NULL, NULL) // test
      all sockets
  // omitted for brevity :
  //  CHECK THE LISTENER FIRST FOR NEW CONNECTIONS
  // pick one
  int nSocket = rand() % nMaxSocket;
  if (FD_ISSET(nSocket, &socket_set))
  {
    // process the data on nSocket
  }
}

struct ACTIVITY_ENTRY
{
  int nSocket_ID;
  int nActivityLevel;
};

int CompareActivity ( struct ACTIVITY_ENTRY sA, struct
      ACTIVITY_ENTRY sB )
{
  if ( sA.nActivityLevel < sB.nActivityLevel ) return -1;
  if ( sA.nActivityLevel > sB.nActivityLevel ) return 1;
  return 0; // they must be equal, in this case
}

Even if you have no interest in MUD development per se, open-source MUD code is worth examining as it touches on all the basic principles of a good network-game design:

The point of this list is that even if a MUD is technically text only, if you exchange “data” for “text,” quite a robust MMORPG can be built on these very solid foundations. They are well understood, and have been refined over time to take advantage of many different extensions to platform technology.

What’s more, you can add data to the text and come up with a hybrid that can be played over the Internet, over the Web, or using some kind of proprietary client without changing the core on the server. The result, if designed correctly, will still allow most, if not all, of the features intended by the initial design.

With this in mind, let’s look at each one in more detail.

Networking code is also part of some major games that have been released into open source (Quake, for example). Much of the issues that they had to deal with when the first networked version was released are still prevalent today.

The code might not be cutting edge in terms of graphics, but the network communications haven’t changed that much. The problems of latency, jitter, and lag still exist, and the solutions are largely the same. There might be some advances in intelligent prediction (Street Fighter IV, for example, uses combat prediction), but many of the solutions remain the same.

Much can be learned from these pieces of code that are more or less implementations of techniques that have grown up from action games. It is also fair to say that most MMORPGs, including ones like Second Life, are less graphically accomplished than games like Eve Online or Unreal Tournament. It is almost like they feel they don’t need it—the point is that an online game can be great fun without the high-end graphics.

However, in the same way that a single-player non-networked game with networking bolted on is not a network game, a great MUD with a terrible front-end will not win any fans beyond a hard-core set who believe in the environment even without the bells, whistles, and high-realism graphics.

Bearing these thoughts in mind, there are still some great lessons to be learned from using the source.

As you are reading this, there are probably more open-source Web-gaming projects to consult than any other kind because the Web is a cheap and easy platform to develop for. The accessibility, as well as the low expense of setting up a virtual server, makes it a great starting point for many projects.

Under the hood, Web games are great because they rely on existing networking standards for communication, display, and update, and offer a split-responsibility scripting model. These key points make it a very attractive platform to develop for.

The split-scripting model means that the client and server can both be scripted to the point that the workload can be distributed between them. This can be true for game-logic as well as rendering and data-exchange scripting.

Ultimately, this can mean that there is a lot of logic in the client. As long as this does not affect gameplay, and is only used to render the effect of that gameplay to the players, then there will be no problem in adopting this model.

Perhaps the most attractive feature of Web-game programming is that the network communication is hidden behind the existing platform architecture of the World Wide Web. In addition, open-source solutions exist for practically every aspect, from user management to content delivery and secure session management. This leaves the programmer free to concentrate on implementing the best possible game, given the limitations imposed by the Web-page environment.