Expectation: More Go for Less Dough

The gaming user community is always changing. As new DSL, fiber, and cable modem solutions are bringing lower cost, higher bandwidth connectivity the home user, expectations rise among casual and die hard on-line gamers alike: more, better, faster! And their personal measure of connection success is ping. The perception remains: "good ping" means "good play". The game hosting companies, game publishers, and individuals who host network game servers are on the hook to deliver the goods. A rented server with a T1 connection for 32 players hosting a Half-Life Counterstrike server might have gone for $150 per month a couple of years back. Now they can be had for $25. So how is a game server hosting company supposed to make money?

One way hosting companies have managed to make this happen is with higher performance hardware. Newer P4-generation and recent dual-core machines, running server class flavors of Windows or Linux, are able to host multiple game engines on the same system.

Another cost management development for gaming hosts is the "self-managed" game server. In the same way that tools like Webmin 1) have enabled web server hosting companies to offer $5 per month web hosting to thousands by lowering their own administrative costs, a refined set of public domain and cheap game administration remote admin tools have made it relatively easy for the game server hosting companies to pass on routine maintenance issues for their rented servers to even mildly technical customers, whether it be uploading of new game maps and player files to stopping and starting different configurations of game server processes.

Server Squeeze: How to Get More

So the network and the server hardware are in place. There are as many customers as the infrastructure can bear. What else can be done to improve the performance, and possibly the capacity, without adding more hardware? One approach that remains is to get the server software itself to run better.

This means working to "adjust" the server binaries to improve their performance. This assumes, of course, that you have access to the source code for the game server programs. If you are a game developer or part of the mod community for your favorite game, you may already have access to the game source. If you are a big enough customer of the game (for example a large gamer café owner), or a big sales enabler (by virtue of the large number of servers you host for Company X's latest release), you may be able to negotiate access to the source or convince the vendor to make some performance improvements of their own on your behalf.

Assuming you have access to the source, you can take several steps down the optimizing path, including application of processor-agnostic general optimization and optimization targeted to your server hardware's specific processor type, including 64-bit architectures.

General Optimization

A good first step toward beefing up your server program is to compile it with an effective optimizing compiler. One choice is the Intel C/C++ Compiler 2), available in both Linux and Windows flavors. If the server is a Windows system, the software developer can use their pre-existing Microsoft DevStudio IDE to manage projects and compiles, with the Intel C and C++ compilers underneath. If the server is a Linux system, the user can choose to use the Eclipse software development CDT environment or good, old fashioned command line editors and "make".

How to start? For this exercise, a solid game engine example was selected: Richard Stanway's R1Q2 3). This is a tightened and enhanced version of the Quake 2 engine, which was release to the Open Source community by ID Software back in 2001. Older code? Yes, but many game programmers cut their teeth on Q2 mod development. It's a known space and a good reference point. Rich's R1Q2 was coupled with code from the LOX Q2 mod, an "extreme weapons" mod built by David S. Martin and friends, and enhanced by Geoff Joy and others. The LOX mod is a good example of performance challenging code, as the massive number of events that can be created by a single player with the right weapon selections and feature combinations can bring an otherwise healthy server to its knees.

Again for this example, the target server platform is Linux, the default choice among server hosting companies where game server engines have a Linux server offering. The test server used was a vanilla Red Hat Enterprise Linux 3 (Taroon Update 4) server, running on a 3.7 GHz Pentium 4 with 1 Gig of RAM, spinning a standard Serial ATA hard drive. Note that all of the steps being discussed here, including the optimization techniques and compiler features, are applicable to or available on Windows as well.

Step One:

Get the code. Unwrapping the code and doing a straight gcc compile using the ---O2 optimization switch with the provided makefiles generated usable binaries that performed as expected. A pair of client machines running on an isolated net connected without issue and achieved pings from varying from 15 to 35 ms. Since this code has had some level of grooming, compiler warnings were minimal.

Step Two:

Perform reference benchmarking. In this case, two client machines were connected to the server, running its standard version of binaries, from a local network connection. Their static pings were recorded, as were their pings when the server was stressed. In this case, the stress test involved having the players from both client test machines launch 4 napalm grenades per second from a fixed location on the servers default level, generating at least 128 in-game explosions per second. Client "freeze" behavior, typical in this server stress condition, was monitored, as was the frequency of "RATEDROP" warnings, issued from the server when a significant drop in server-client data exchange rate is detected.

Step Three:

Get the Intel compiler. The Intel C/C++ compiler package is available for demo download, with academic, non-commercial, and commercial licenses. The software installs on nearly all major Linux distributions, including those not supporting RPM.

Step Four:

Update the makefiles to enable optimization options. In this case, that meant changing "CC=gcc" to "CC=icc". The R1Q2 makefile required no dependency changes or LDFLAGS changes. The LOX makefile required a minor change to the LDFLAGS setting to accommodate the new library home for a couple of key string functions.

For round one of our compiler optimization exercise, CFLAGS was changed to add the -02 optimization switch. This is the most commonly recommended option, performing many optimizations for speed without significant regard to the impact on code size, including but not limited to:

• Inlining
• Forward substitution
• Constant propagation
• Dead static function, code, and store elimination
• Tail recursions
• Partial redundancy elimination

One thing that became clear during the initial build with the Intel compiler was that the number of warnings increased, going from 4 to 62. Most of the warnings were variable type checking issues. Some of them warranted further investigation. In this case, only minor code changes were required. The newly rebuilt binaries were tested and results gathered.

For the next round of optimization, the -02 CFLAGS option was changed to -03. This option, according to the documentation, contains "more aggressive optimizations, such as prefetching, scalar replacement, and loop and memory access transformations". This includes all of the features of the -02 optimization, plus loop unrolling, code replication to eliminate branches, and padding of certain power-of-two arrays to improve cache use. Again, the newly built binaries were tested and results were gathered.

For round three, the binaries were built with an added switch: -axN. This switch enables processor-targeted optimization, in this case specifically for Intel Pentium 4 and compatible chips. Once again the new binaries were tested.

The final round of compiler switch optimization called for changing the -axN switch to -axP. This option optimizes the output for Intel Pentium 4 processors with Streaming SIMD Extensions 3 (SSE3) instruction support. Once more the resulting binaries were tested.

Test Results

The two client machines used for the test included:

• Machine 1 - a 2.9 GHz Pentium 4 with 512 Mbytes of RAM, running an R1Q2 Quake 2 client in OpenGL mode at 1024 x 768 resolution
• Machine 2 - a 1.3 GHz Celeron with 512 Mbytes of RAM, running a stock 3.20 ID client in software rendering mode at 1024 x 768 resolution

Here is a summary of the results:

Compile Optimization Conclusions

The above results show that there is no significant ping difference between the gcc -O2 and icc -O2 behavior during relatively inactive periods, put perceived lag on the client side is reduced somewhat. Similarly, frame drop warning rates and recovery times after stress events are mildly better with the icc compiler. Results are somewhat more significant when going to a -O3 optimization level and even more dramatic when including the processor targeting options -axN and -axP.

The above tests are not a perfect model for behavior in a dynamic environment, where players will be connecting from across the company or across the globe. But they do serve to demonstrate the opportunity for improvement.

Clearly, ping is not the only measure of performance. While the improvements made to the test programs did improve ping somewhat, most of the impact was seen in the server's ability to maintain smooth gameplay, or to restore smooth gameplay after periods of intense activity. And this is what it is all about.

Additional Steps to Improve the Binaries

The gains demonstrated above may be significant enough for some. If still more performance improvement is required, there are a number of additional steps that can be taken. While these steps are beyond the scope of this article, they are worth mentioning as areas of future exploration, especially for developers of new game offerings.

One of these steps is to apply profilers to determine where the hotspots (bottlenecks) are in the game server program. Tools such as Intel's VTune Performance Analyzer product can be employed to locate the sources of program slowness, identify key algorithms that can be improved, and point toward other opportunities to optimize program behavior.

Another approach that can work hand in hand with performance analysis is addition of threading techniques to the software. Individual hotspots in the program can be threaded, using available threading libraries and new or modified code, to streamline program operations and to take advantage of the performance gains offered by new dual core processor technologies.

Other Ways to Improve Server Performance

There are, of course, fundamental things that a game server administrator can do to ensure that the game being hosted is optimally configured and makes best use of all the work that went into coding and compiling it well. Several key server configuration parameters may be adjustable for a particular game, significantly impacting overall performance. While these vary from game to game, they can include:

• Practical player limit (i.e. don't let the user adjust this number past their purchased limit or sell player count limit packages that exceed the game engine's ability to deliver)
• Hard ceiling to connected ping of players (i.e. players with ping greater than a specific limit are not allowed to connect or are disconnected during game play to protect playability for the rest)
• Limited bandwidth or disabled downloading of maps, models, audio, and other optional "level-specific" content.
• Limited bandwidth or disabled uploading of player-specific content, such as "skins" and "sprays", where such features are supported by the game.
• Cap on frames per second performance (may be expressed as max number of player updates per second)

A last option: you can always change the game. A novel approach to minimizing server performance impact from level-specific content download, adopted by Richard Stanway in his R1Q2 package, involves outsourcing of map / texture / audio downloads to an HTTP server. This means that the map download function can be optionally offloaded to a separate system, perhaps one on a separate subnet to minimize network impact, with transfers running at a higher UDP data rate than the game's existing TCP connections can support. The downside to doing this with an existing, released game is that it will probably require client-side changes as well. This sort of approach would work well applied to the design of a new game server engine, and could readily be applied to a rewrite of an existing engine where the server code has been released to the Open Source community.

This type of distributed data transfer between the game server and the client is also another excellent application for threading techniques. In environments supporting several Massive Multiplayer servers, these could even be scaled up to support deployment in clustered environments, with specific components of the cluster performing particular aspects of client updating and content download activity.

About the Author

Doug Helbling is a software engineer for Intel's software development product deployment team. He works to develop Linux product delivery solutions, various game mods and case studies. His latest project includes an optimization study of GarageGames' Torgue engine.

1) Webmin web-based interface for system administration http://www.webmin.com

2) Intel C/C++ compilers and related software products http://www.intel.com

3) R1Q2 Quake 2 release http://www.r1ch.net/stuff/r1q2

Introduction

As online gaming becomes a billion dollar industry and game companies are making revenue from subscription charges, new problems emerge which need to be taken very seriously. Online games containing graphical glitches, sound defects and poor performance will not be very popular. However, an online game with security flaws and mass-cheating will simply fail.

Several security issues related to online gaming are shared with other network applications, however online gaming has a unique set of problems that need to be dealt with. The aim of creating a secure game is not only to ensure customers credit card numbers are protected, but to ensure that all players receive a fair and entertaining experience. Otherwise, they won’t play.

This rest of this article looks at some of the security related issues in online gaming. Note that not all of the issues will apply to all types of games.

Copy Protection

This has traditionally been the most important aspect of security in computer games. There are many different technologies that provide copy protection, but nearly all of them can be overcome. However, piracy is not so relevant to online games, as the game companies make money from subscriptions. Money can be made from selling boxed-versions of online games by giving added-value content such as manuals, maps, and the box itself.

Hacking the Client

Many online games store game logic and player data on the server, and store graphics and sound on the client. This makes it difficult for hackers to cheat by altering statistics such as health or ammunition; however it gives them full ability to change the graphics in a game. For many gamers, the ability to make modifications (known as mods) to games is almost as important as playing the game itself. However, imagine if one player modifies the game so that he can see through walls, and plays against somebody who can’t. You can guess who will win. A simple solution to this problem is by ensuring all players are using the same modifications.

Packet Sniffing

There are many programs available that let users examine, modify, send or block packets that are being transmitted to and from their computer. This causes several problems for online games such as blocking packets that may have a negative effect on a player, or replaying packets that shoot an enemy player, even though you have no ammunition left. Such situations can be avoided by keeping important variables on the server, and by encrypting packets. Even encrypted packets can be repeated though; therefore a sequence number system should be used so that the server can verify the packets.

Area of Interest Management should also be used to minimize the data that the client has to receive. If a tree falls in a forest and no one is around to hear it fall, does it make a sound? In a virtual world using AoIM algorithms, the answer is no. AoIM algorithms limit network traffic in a virtual world to only what is necessary for each player. In a large virtual world, there could be thousands of players, with millions of variables that are constantly changing. If the client were to be kept updated with all variables, it could easily use up more bandwidth than available, causing network congestion and increasing latency. To put very simply, AoIM solves this problem by dividing the world into different geographical zones, and then only sending data regarding the zone that is directly related to each player.

Social Abuse

Players in virtual worlds can have a lot of freedom to do as they please. This could include running around causing sexual and racial abuse. Such abuse reduces and spoils the fun and can damage the popularity of the game. There are two ways around this problem; first of all by allowing other players to report such abuse. This requires adequate logging facilities so any allegations can be proved and then the offending player can be dealt with accordingly. Another solution to limit the damage in the first place is to give players the option of censorship. This relies on intelligent game software detecting offensive behavior and hiding it from players who wish to be protected. Another form of social abuse could be using a game for commercial or advertising purposes, or tricking people into giving out credit card numbers etc. This can be prevented again by reporting such abuse, and by educating users.

Hacking Accounts

Since a password is the key to accessing account information and the player’s character, it is important that the same password protection techniques are used as in other sensitive applications. These can include encryption when transmitting sensitive data, and educating players not to use obvious passwords or inadvertently giving them out. In some situations, server authentication may also be necessary to ensure hackers have not setup bogus servers that can be used to collect a user’s password.

Denial of Service

Such attacks can be used to reduce the responsiveness of other players. This is hard to avoid when using a peer-to-peer topology, however in client-server based games, simply not distributing other players IP addresses will avoid this problem. Attacks on game servers are also possible. This is unlikely to give any specific player an advantage, but it is likely to make the game unplayable for everybody. Using server software that drops non-game packets and technology such as XenoService will help to reduce the effects of such attacks.

Internal Misuse

This could be either accidental or deliberate. System administrators responsible for the virtual world are probably enthusiastic players in the game itself. But can they be trusted not to abuse their god-like position? Or perhaps a system administrator decides to make a few changes to the game world without fully considering possible implications. Therefore powers should be restricted where possible, monitoring is necessary, and procedures must be set in place and followed.

Backup

Due to the complexity and nature of virtual worlds, it is essential to keep several versions of backups from different time periods. For example, if a serious bug is found after many players have taken advantage of it, this could cause a major unbalance in the economics of the world. It is often better to restore the game from a time before the bug was taken advantage of, than letting play carry on as is – even if it means losing several days worth of play. Most players would prefer this than having to start again from scratch.

Cheat Detection

By logging access to game servers, recording important events (e.g. player advancement), and keeping track of key quantities such as the number of rare items in the game, game administrators can identify or verify where cheating is taking place.

Disconnecting

A player may disconnect from a game seconds before being killed, perhaps then reconnecting with another character and finishing off the battle. Although two can play at that, nobody will die, the game becomes boring and good players will stop playing. This can be solved by game design, for example by making a character go into an auto-pilot mode for a period of time after disconnection.

Disciplinary Measures

Games should include a comprehensive list of terms and conditions that will allow termination of players who break the rules. However, it is essential mistakes are not made, as one wrongly banned customer could cause an uproar. Also, it could be difficult to stop banned users from signing up again, especially from free systems that do not require credit cards numbers.

Conclusion

It is probably impossible to make a perfectly secure online game; however it is certainly possible and desirable to reduce and limit misuse, allowing customers a good experience in a virtual world. Good design and programming, increased user awareness, ongoing maintenance and supervision will help to achieve this.

References

Becker, David, ZDNet Article, Cheaters take profits out of online gaming, June 2002
http://zdnet.com.com/2100-1104-933853.html

Internet Security Systems, Packet Sniffing
http://www.iss.net/security_center/advice/Underground/Hacking/Methods/Technical/Packet_sniffing/default.htm

Gamasutra, How to Hurt the Hackers: The Scoop on Internet Cheating and How You Can Combat It
http://www.gamasutra.com/features/20000724/pritchard_01.htm

Nathaniel Baughman, Brian Neil Levine, Cheat-Proof Playout for Centralized and Distributed Online Games, 2001
http://citeseer.nj.nec.com/baughman01cheatproof.html

Wired, Blizzard of Cheaters Banned
http://www.wired.com/news/games/0,2101,55092,00.html

XenoService
http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/xeno.pdf

• Simplified administration.
• Ease of maintenance.
• Ease of locating resources.

• Difficult to scale.
• High cost of ownership.
• Little or no redundancy.

• Some scalability.
• Some redundancy.
• Simple load-balancing.

• Scalability limited to hardware.
• Higher cost of ownership than centralized model.
• Difficult to add more resources.

• Structured communications flow.
• Quick location of resources.
• Resources can be in disparate locations.

• Timeliness of information can be limiting.
• Propagation of "bad" data can occur.
• Difficult to extend and add new resources.

• Highly extensible and scalable.
• Highly fault tolerant.
• Dynamic addition of new resources.

• Scalability overhead can be large.
• Difficultly in synchronizing data and state.
• Extremely difficult to manage all resources.

• Redundant, loosely-coupled, game-specific resources.
• A mechanism for the discovery of these resources.
• The ability to dynamically switch between resources that provide the same service or information.
• A trust relationship between resources and metrics by which to measure that trust.

• Uniquely identifiable.
• Locatable.
• Ability to communicate with other resources.
• Ability to synchronize internal state with other similar resources.

• Map System: The world in which the game takes place.
• Events System: Unique activities that are time sensitive, such as weather, changes in environment and non-player character (NPC) campaigns.
• Player System: The management of player state and related information. (Note that in this example our players make up part of this system.)
• NPC System: The management of NPC state and related information. This could include monsters, wildlife and other non-player characters.
• Time System: The global clock. A simple resource to synchronize time amongst all resources.

• Creation of resources.
• Discovery of resources.
• Communication between resources.
• Trust metrics.
• Dynamic resource switching.

• Some ISPs and networks don't support multicasting yet. Bastards. So if you want to implement multicasting in a game, you're better off adding it as an option. Internet multicasting is rarely supported, but hopefully it will be in the future.
• Multicasting only makes a worthwhile gain in performance when network data is replicated, realistically only worth bothering when there is support for more than four players.
• Multicasting requires some more coding and programmers are lazy to even look into it. As you will see, in fact it requires very little additional code. The corporate "Quality Digital TV via Multicasting" idea seems to put game programmers off the subject altogether, I suspect it has something to do with hacker ethics, so long live the .org's!
• The openness of multicast groups may make your packets easier to sniff. Usually UDP packets can only be intercepted between their source and destination, but now they can be captured anywhere on the network; by joining the right group, anyone can get a carbon-copy!

SOCKADDR_IN addrLocal;
// We want to use the Internet address family
addrLocal.sin_family = AF_INET;
// Use any local address
addrLocal.sin_addr.s_addr = INADDR_ANY;
// Use arbitrary port - but the same as on other clients/servers
addrLocal.sin_port = htons(uiPort); 
// Bind socket to our address
if(SOCKET_ERROR == bind(hUDPSocket, (LPSOCKADDR)&addrLocal, 
                        sizeof(struct sockaddr)))
  {cout << "Euston, we have a problem";}
// Ready to switch to multicasting mode[code]And then just make a call to [i]setsockopt()[/i], and here's a prototype for your convenience *grin*:

[code]int WSAAPI setsockopt(SOCKET s, int level, int optname,
                      const char FAR * optval, int optlen);

struct ip_mreq {
  struct in_addr imr_multiaddr;   /* multicast group to join */
  struct in_addr imr_interface;   /* interface to join on    */
}

struct ip_mreq mreq;
mreq.imr_multiaddr.s_addr = inet_addr("234.5.6.7");
mreq.imr_interface.s_addr = INADDR_ANY;
nRet = setsockopt(hUDPSocket, IPPROTO_IP, IP_ADD_MEMBERSHIP,
                  (char*)&mreq, sizeof(mreq));

SOCKADDR_IN addrSrc;
nRet = recvfrom(hUDPSocket, (char *)&Data, sizeof(Data), 0,
                (struct sockaddr*)&addrSrc, sizeof(addrSrc));

nRet = setsockopt(hUDPSocket, IPPROTO_IP, IP_DROP_MEMBERSHIP,
                  (char*)&mreq, sizeof(mreq));

char TTL = 32 ; // Restrict to our school network, for example
setsockopt(hUDPSocket, IPPROTO_IP, IP_MULTICAST_TTL,
   		(char *)&TTL, sizeof(TTL));

// Set the local interface from which multicast is to be transmitted
unsigned long addr = inet_addr(YOUR_IP_ADDRESS_STRING);
setsockopt(sSocket, IPPROTO_IP, IP_MULTICAST_IF, (char *)&addr,
sizeof(addr));

SOCKADDR_IN  addrDest;
szHi[50];

addrDest.sin_family = AF_INET;
// Target multicast group address
addrDest.sin_addr.s_addr = inet_addr("234.5.6.7");
// Port on which client is set to receive data packets
addrDest.sin_port = htons(uiPort);
// Something unoriginal to send
strcpy(szHi,"Hello Multicast Group!");

nRet = sendto(hUDPSocket, (char *)szHi, strlen(szHi), 0,
              (struct sockaddr*)&addrDest, sizeof(addrDest));

• The players send out a broadcast message to the entire network, however this would create huge traffic and will probably be restricted to sub networks. Broadcasting on the Internet would create an enormous amount of traffic, so it is not allowed.
• The players connect to an intermediate, "known" master server IP, which tells them of each other's existence. These servers are costly to run and their uptime is often undependable.
• The players go to a chatroom hoping to find other players and play together. This will not connect all the players as some may be in different chatrooms. And the process of finding someone may take a while.

nRet = setsockopt(hUDPSocket, IPPROTO_IP, IP_ADD_MEMBERSHIP,
                  (char*)&mreq, sizeof(mreq));
if(WSAESOCKTNOSUPPORT == nRet)
  {
  // Multicasting not supported. Damn.
  }

struct Client
  {
  SOCKADDR_IN addrRemote;
  /* ... Game specific info here ...*/
  BOOL bSupportMulticast;
  }

int SendToAll(char *Data)
  {
  if(bServerSupportMulticast)
    {
    // First send multicast, then send individually
    // to those who don't support it
    for(int index = 0; index < MAX_CLIENTS; index++)
    {
      if(Clients[index].Exist && Clients[index].bSupportMulticast)
      {
        // At least one client supports multicasting, so use it
        SendMulticast(Data, addrMulticast);
        break;
      }
    }
    for(int index = 0; index < MAX_CLIENTS; index++)
      {
      if(Clients[index].Exist && !Clients[index].bSupportMulticast)
        {
        OldSendToClient(Data, Clients[index].addrRemote);
        }
      }
    }
  else
    {
    // Use the old method all the way regardless of support
    // as we ourselves don't support it
    for(int index = 0; index < MAX_CLIENTS; index++)
      {
      if(Clients[index].Exist)
        {
        OldSendToClient(Data, Clients[index].addrRemote);
        }
      }
    }
  }

Disclaimer: I am writing this article under the assumption that noone else has written one like it; I certainly have not found one. With all the people writing games today, I'm certain the wheel has been re-invented many times over, so please e-mail me if you find another article exactly like this.

When I was writing Cycles3D, I realized I needed a game-find server. In haste, I wrote a server executable that ran from my own computer, but that didn't last long. It was buggy, and when I graduated from college, I lost my dedicated connection. I got back to it later on -- thinking at the conceptual level, that is. I wanted something generic that would run with all my future games, and adopted the idea of a generic game-find server that worked with a paradigm that is parallel to that of a DNS server, only the "domain names" would resolve to the IP addresses of games in progress. While discussing it in a programming chat room, it was suggested that I actually use a DNS server to do it. Putting the two together, the idea of the GNS: Game Name System server, was born.

What is DNS?

Figure 1: A graphical representation of a DNS server hierarchy.

Servers on the internet are assigned names according to the Domain Name System. Each server has a special name that consists of alpha-numeric characters seperated by periods. Every part of the name represents a part in a hierarchy of servers. For example: with clubs.yahoo.com, the top-level domain is com, the next level is yahoo, and the last level is clubs. When you want to go to clubs.yahoo.com, your computer first communicates with the com server, which directs your computer to the yahoo server, which directs you to the clubs server. At that point, you get the IP address of clubs.yahoo.com, and then you connect to it with your browser.

You'll notice that some of the shapes in the picture are doubled. This represents the fact that for every complete domain name, there can be more than one DNS server at each level. The com level server, for example, has many mirrors, because it would not make sense that every computer in the world on the internet resolve IP addresses through the same server. Imagine the traffic and resource usage it would take!!

What is GNS?

Figure 2: A graphical representation of a GNS server hierarchy.

A GNS server is a superset of the DNS server. It has all the code functionality a typical DNS server does. If you want to find Steve's Unreal Team Fortress game, you would have to resolve the name

stevesgame.awesomegamenet.3_2_1.tf.unreal

to the IP address of his computer.

The top-level domains in the GNS are not com or org like with DNS, but rather, can be the names of video games: Quake, Unreal, or Cycles3D. The lower level domains could be a variety of things, depending on the game. For popular 3D shooters, they could be a hierarchy that goes from add-on, to version, to third-party servers like Awesomegamenet (which is non-existent as far as I know) or BattleNet. Who says this has to be written in stone, however? The top-level domains could in fact be the BattleNet's and GameSpy's of our day, while game names appear at lower levels. The point I'm trying to make here is that the concept of DNS may not only apply to finding websites, but also, to finding video games.

I said earlier that the GNS server is a superset of the DNS server...what more could it do than just resolve names to IP addresses? Well, let's be creative for a moment. Who says they have to just point to games? Why not rankings, too? Obviously, clan servers would have to join the hierarchy...and game statistics (like player count and frags) may not only be retrieved from one specific game, but to all the games in a specific sub-domain.

I know what you're thinking: "Who is this guy? Why doesn't he get with the times, and use GameSpy? We already have all the technology we need to find people and games over the Internet!" Well, you're absolutely correct. I do not know; however, how GameSpy works. Maybe it already works this way (in which case I hide behind my disclaimer). Still, I think that the development of a client and server side package for this concept would be a great help to small time developers or individuals who can write video games, but don't want to invest a great deal of time in this particular aspect of their games. The best part is, 90% of the GNS package has already been programmed by those who write DNS servers and clients! Now lets see if we can get them to release their source code so we can finish the other 10% :).

Figure 1: The reality of network games; what everyone sees (click for animation)

Figure 2: Latency causes the game to go in different directions for each player (click for animation)

Figure 3: Overly compensating for latency makes the game look bad. (click for animation)

Figure 4: The target (the blue thing) has two elements: A position, and a velocity.

for each frame {
  target.x_velocity = target.x_velocity + target.x_acceleration;
  target.y_velocity = target.y_velocity + target.y_acceleration;
  target.z_velocity = target.z_velocity + target.z_acceleration;

  target.x_position = target.x_position + target.x_velocity;
  target.y_position = target.y_position + target.y_velocity;
  target.z_position = target.z_position + target.z_velocity;

  laser.x = (laser.x + target.x_position) / 2;
  laser.y = (laser.y + target.y_position) / 2;
  laser.z = (laser.z + target.z_position) / 2;
}

Figure 5: The server and other clients can calculate where the laser is on your screen (the target), but rather than just placing it there, it makes the laser quickly converge to that target. This makes the game run more smoothly for everybody. (click for animation)

laser.x = (laser.x * 99 + target.x_position) / 100;
laser.y = (laser.y * 99 + target.y_position) / 100;
laser.z = (laser.z * 99 + target.z_position) / 100;

Option Explicit
Private Sub SetAddress()
  gPort = txtPort.Text
  gIPAddress = txtIPAddress.Text
End Sub

Private Sub cmdClient_Click()
  Call SetAddress
  frmClient.Show
  Unload Me
End Sub

Private Sub cmdServer_Click()
  Call SetAddress
  frmServer.Show
  Unload Me
End Sub

Private Sub Form_Load()
  ' Only connection(0) listens, all others are connections
  sktConnection(0).Close
  sktConnection(0).LocalPort = gPort
  sktConnection(0).Listen
  ReDim gHandles(1) As String
  gHandles(0) = "Cornflake Server"
  AddToServerLog ("Server is Listening on port " & gPort)
End Sub

Private Sub sktConnection_ConnectionRequest(Index As Integer, ByVal requestID As Long)
  ' Now accept the new connection
  'A connection was requested from the server.
  Dim i As Integer
  Dim iConnection As Integer
  'Make sure this is control 0 in the array.
  'This is the only one that can accept connections.
  If Index = 0 Then

	'Search for available Winsock control.
	For i = 1 To gNumConnections
  	If sktConnection(i).State = sckClosed Then
    	iConnection = i
    	Exit For
  	End If
	Next i

	'If none was found, create a new one.
	If iConnection = 0 Then

  	' Tell the world there's a new connection
  	gNumConnections = gNumConnections + 1

  	'Load a new Winsock control for this connection.
  	Load sktConnection(gNumConnections)

  	' This connection needs a handle
  	ReDim Preserve gHandles(gNumConnections) As String
  	ReDim Preserve gSentYN(gNumConnections) As Boolean
  	ReDim Preserve gMessages(gNumConnections) As String

  	' Catch this user up on the previous conversation
  	' This way they don't get resent the chat session to date
  	gMessages(gNumConnections) = gTotalincoming

  	' set their handle
  	gHandles(gNumConnections) = "unknown"

  	' Add to the servers connections
  	lblActiveConnections.Caption = gNumConnections & " Active Connections"
  	iConnection = gNumConnections
	End If

	'Set port for this control to 0. (Randomly assigns an available port.)
	sktConnection(iConnection).LocalPort = 0

	'Have this control accept the connection.
	sktConnection(iConnection).Accept requestID

	' Send the welcome message
	sktConnection(iConnection).SendData "Welcome to the CornflakeZone, enter your handle"
  End If

End Sub

Private Sub sktConnection_DataArrival(Index As Integer, ByVal bytesTotal As Long)
  'Data has arrived at the server from an open connection.
  Dim newdata As String

  'Get the data.
	sktConnection(Index).GetData newdata

  If gHandles(Index) = "unknown" Then

	' Store it internally
	gHandles(Index) = newdata

	' Announce the new arrival
	AddToTotalIncoming (newdata & " just joined")
  Else
	'Pass the index of the connection from which the data came.
	AddToTotalIncoming (gHandles(Index) & ":: " & newdata)
  End If
End Sub

Private Sub tmServerTimer_Timer()
  txtTotalIncoming.Text = gTotalincoming
  'Send the new data to the group
  Call BroadcastMessage
End Sub

Private Sub BroadcastMessage()
  Dim i
  Dim myMessage As String
  Dim conn_index As Integer

  ' Set the default connection index
  conn_index = -1

  ' Loop through all connections excluding the servers
  ' Hence we start at 1
  For i = 1 To gNumConnections
	' if this connection has not had an update then
	If gSentYN(i) = False And sktConnection(i).State = sckConnected Then
  	' Get the message we need to deliver
  	myMessage = Left(gTotalincoming, Len(gTotalincoming) - Len(gMessages(i)))
  	' update the message store for this user
  	gMessages(i) = gTotalincoming
  	' Get the index of this connection
  	conn_index = i
  	Exit For
	End If
  Next i

  ' This is so we know to
  ' send the data to everyone
  If conn_index = -1 Then
	For i = 1 To gNumConnections
  	gSentYN(i) = False
	Next
  End If

  If conn_index > -1 Then
	' check the connection's open
	If sktConnection(conn_index).State = sckConnected Then
  	' send the data
  	sktConnection(conn_index).SendData myMessage
  	'signal that we've sent to this user
  	gSentYN(conn_index) = True
	End If
  End If

End Sub

Private Sub sktClient_DataArrival(ByVal bytesTotal As Long)
  Dim newdata As String
  ' Get the arriving data and print it out.
  sktClient.GetData newdata

  ' add the data to the output
  txtOutput.Text = newdata & txtOutput.Text
End Sub

Private Sub sktClient_Error(ByVal Number As Integer, Description As String,
                        	ByVal Scode As Long, ByVal Source As String,
                        	ByVal HelpFile As String, ByVal HelpContext As Long,
                        	CancelDisplay As Boolean)
  ' This should handle any winsock errors.
  Call AddToOutput("Error: " & Description)
End Sub

• FD_READ: This message indicates that you have just received data, and you must use the recv() function to get it.
• FD_WRITE: This means that there is room in the buffer to send, and we must send using the send() function.
• FD_CONNECT: Used only by the client program. This message indicates that the server has received the connection request and has accepted.
• FD_ACCEPT: Used only by the server program. This message indicates the receipt of the connect() request and you must send back an accept().
• FD_CLOSE: This message indicates that the other side’s socket has shut down. This can be for several reasons.

int PASCAL FAR WSAAsyncSelect(SOCKET s, HWND, hwnd, unsigned int wMsg, long lEvent);

• s – the socket instance for which we want to enable event notification.
• hwnd – identifies the window to which the messages will be posted, since WinSock uses PostMessage() to get the notification to you (hey, now we know how it does it!).
• wMsg – the message type for the notification message(s).
• lEvent – a bit mask identifying the events for which we want notification. Ex: FD_READ | RD_WRITE | FD_CONNECT.

// the message we'll use for our async notification
#define WM_WSAASYNC (WM_USER +5)

// create and test the socket
Port = socket(AF_INET, SOCK_STREAM, 0);
if (Port == INVALID_SOCKET)
  return(FALSE);

// make the socket asynchronous and notify of read, write, connect and close events
// this is the client socket
WSAAsyncSelect(Port, hwnd, WM_WSAASYNC, FD_WRITE | FD_CONNECT |
                                    	FD_READ | FD_CLOSE);

// make the socket asynchronous and notify of read, write, accept and close events
// this is the server socket
WSAAsyncSelect(Port, hwnd, WM_WSAASYNC, FD_READ | FD_WRITE |
                                    	FD_ACCEPT | FD_CLOSE);

switch(msg)
{
case WM_WSAASYNC:
  {
	// what word?
	switch(WSAGETSELECTEVENT(lParam))
	{
	case FD_ACCEPT:
  	{
    	// check for an error
    	if (!WSAGETSELECTERROR(lParam))
      	return(FALSE);
    	// process message
    	sAccept =  accept(wParam, NULL, NULL);
      	return(0);
  	}
	}
  }
}

...
sAccept = accept(wParam, NULL, NULL);
...

sAccept = accept(wParam, NULL, NULL);

sAccept = accept(s2, NULL, NULL);

switch(WSAGETSELECTEVENT(lParam))
{
case FD_READ:
  {
  } break;
case FD_WRITE:
  {
  } break;
case FD_CONNECT:
// 	or
case FD_ACCEPT:
  {
  } break;
case FD_CLOSE:
  {
  } break;
}

• 0 = either the other side did a graceful close or did a shutdown() for send. Either way there was no real error.
• WSACONNRESET = the other side did a closesocket() with reset close behavior.
• WSACONNABORTED = the connection may have timed out. This is an abrupt abort and could even be from the user just quitting.
• WSANETDOWN = network code has completely failed, which means you’re in trouble J

connect(Port, (LPSOCKADDR)&Server, sizeof(Server));

...
case FD_ACCEPT:
  {
	// holds size of client struct
	int lenclient = sizeof(client_sock);

	// connect to the server
	Port = accept(wParam, &client_sock, &lenclient);
  } break;
...

int bytes_recv = recv(wParam, &data, sizeof(data), 0);

case FD_WRITE:  // we can send data
  {
	// enter an infinite loop
	while(TRUE)
	{
  	// read in more data from the file and store it in packet.data.
  	in.read((char*)&packet.data, MAX_PACKET_SIZE);

  	// increment the amount of data sent
  	data_sent += strlen(packet.data);

  	// send the packet off to the Server if it is filled
  	if (send(wparam, (char*)(&packet), sizeof(PACKET), 0) == SOCKET_ERROR)
  	{
    	// check if the network buffer is full and can send no more
    	// data. If so then break from the loop
    	if (WSAGetLastError() == WSAEWOULDBLOCK)
    	{
      	// break from the loop – buffer is full
      	break;
    	}
    	else // another error
    	{
      	// display an error message and clean up
      	CleanUp();
      	return(0);
    	}
  	}
	}
  } break;

• The routers. Routers have a finite capacity. They can only examine and forward one packet at a time. The rest sit in a 'queue' waiting to be dealt with. Once the queue is full, any packet that gets submitted will be ignored. Welcome to the world of dropped packets. Actually, this is pretty rare, you have to have a real heavy load on a router before it does this, but it does happen. Another problem with queuing is that it takes time. It delays your packet before it's processed and adds to the round trip time it takes for your packet to get to its destination. More often there are problems with the router itself, or it leads to a dead end. To explain, when a packet hits a router, it's destination address (its destination IP) is examined, and the router compares it against it's own route tables. These routes come in two flavors, static and dynamic, (at least they do now - older routers have only the static lists). Route Tables are basically a list of destination addresses it knows about. For instance router A gets a packet that wants to go to Router F. Router A can see routers B and C - but not router F. What does it do? It requests those routers that B and C can see (and in this case both know where router F is), and decides based on the info it receives which one to send it to. This info includes loads on the B & C routers, number of hops to get to Router F and so on. Since loads can vary second to second, the decision to send it via B or C can change second to second. Hence you can see how multiple paths can be used for packets going to the same destination. So what's the difference between static and dynamic trace routes? Static are routes that are 'programmed in' to the router. It KNOWS these routes exist, and expects them to be there at all times. Dynamic routes are those that it gets from other routers. This list is constantly changing and updating dependent on what routers are up, what routes are the fastest and what routers may be inoperable further up the chain. If a line goes down somewhere, or a router breaks down, most routers with only static lists don't know/care. They send it on, since they KNOW the route is supposed to be there, but once it gets to the next one, there is nowhere for it to go, because a line was down. Before dynamic trace routes were around, if a line went down between you and your destination, you could well be SOL. Obviously I've take some liberties with exactly how routers work and simplified it considerably, but this is more a layman's document than a programmers guide.
  
  One of the worst things about all this is that there is nothing that you, as the user, can do about this. The Internet was designed to be robust, in real time, but not instant. It's a shame, but Quake wasn't on their minds at design time.
  
  As an aside, you might be interested to know that with the new IP design that has 6 IP numbers instead of 4 (apparently we are going to run out of IP addresses by 2014), some new addressing schemes include a 'preferred route' in the header for IP packets. This way the router itself won't be doing the decision-making, but letting the packet creator chose the route itself. At least this will gain consistency, and reduce lost packets & out of order packets, but at the risk of speed of transmission.
• TCP/IP - UDP. As we learnt in the last bullet point, you can't guarantee that packets are going to be delivered at all. Another draw back to this situation is packet ordering. You may transmit you packets in order, but they may end up going via different paths, and encounter different delays in getting to their destination, with the practical upshot that they get there out of order. This is a problem, and there is not much that the hardware of the Internet can do about this. But a solution is in hand in the shape of Internet Protocols. We've all heard about TCP/IP but what does it mean? Well, it stands for Transmission Control Protocol / Internet Protocols. While we are talking about initials lets define UDP as well. That's User Datagram Protocol. So we know that they stand for. Does this make everything clear? No. Ahhh. So let's clarify. TCP/IP and UDP/IP are two layers of systems. The IP bit is the part that figures out the transmission of packets of data to and from the Internet. UDP or TCP hands it a big fat old packet of data, and the IP part splits it up into sub packets, puts an envelope around it, and figures out the IP address of its destination, and how it should get to where it's going, then sends it out to your ISP or however you are connected to the Net. It's effectively the bit where you write down what you want to send on a postcard, stamp it, write the address on it, and stuff it in a mail box.
  
  UDP and TCP are higher layers that accept the packet of data from you, the coder or you, the game and decide what to do with it. The difference between UDP and TCP is that TCP guarantees delivery of the packets, in order, and UDP doesn't. UDP is effectively an access way to talk directly to IP, whereas TCP is an interface between you and IP. Complicated, but you should get the drift. It's like having a secretary between you and your mail. With UDP you would type up your letters yourself, put them in an envelope etc. With TCP you would just dictate the letter, give it to her and let her do all the work and follow up to be sure the letter arrived.
  
  You can see TCP/IP in action right this second if you want. If you're in windows, open up an MS-DOS prompt and type PING 205.229.73.43 and press return. What you've just done is sent a message to the machine that runs this website and said "are you there?" And it's replied, "Yes, I am." The values you see there is the time taken for the packets of info to make the round trip - from you to them and back again. This is called Ping time, or Latency. Latency is one of those weird phrases that mean different things to different people. We here at Raven treat it as an average. Ping is the round trip for one packet; latency is the average round trips over the last 30 or so packets. As a rule of thumb, those hosts that you are trying to get to that have the least amount of routers to go through are the ones that will have the lowest ping. Usually these are the closest to you in physical location, but not always. If you want to see the route you have to go through to get to a particular host, type tracert 205.229.73.43 at the MS-DOS prompt. This returns all the routers your packet hit on the way to the host.
  
  However, all this wonderful work-done-for-you comes at a cost. In order to be sure that packets that are sent via the Internet get there ok, TCP expects an Acknowledgement (an ACK in net parlance) to be sent back from the destination for every packet it sends. If it doesn't get an ACK within a certain time, then it holds up sending any new packets, re-sends the one that was lost, and will continue to do so until the destination responds. We've all seen this in action when you've gone to a web page, and half way through the download it stops for bit and then restarts. Chances are (assuming its not an ISP problem) a packet has been lost somewhere, and TCP is demanding it gets resent before any more come down the pipe.
  
  The problem with all this is the delay between the sender realizing something is amiss, and the packet actually getting through. This can get into the seconds sometime, which is not that much of a worry if you are just downloading a file or a web page, but if it's a game packet, of which there are at least 10 a second, then your in real trouble, especially since it's holding up everything else. This is actually such a problem that almost no games use TCP/IP as their main Internet protocol of choice, unless it's it not a real time action games. Most games use UDP - they can't guarantee order or delivery, but it sure is fast. We'll talk about how they handle this later.
• ISPs. Often the bane of a game players life. Some ISP's get all upset about the idea of people playing games using their precious bandwidth that they actually use Packet Sniffers. These are programs that scan the packets going through the network looking for Quake game packets, and when they find them, they kill them dead. What a bunch of spoilsports. I'd be interested to know exactly how they know these packets are Quake packets, since packets can contain anything, but apparently there are programs like this out there. Of course the other big bit of bad news about ISP's is their server load. The way that modem banks work is that all the modems tie into one large pipe that goes into the main host machine that then forwards these packets to the Net itself. Now, the lower the spec machine that is used for the hosting, and the larger the bank of modems attached to it, the longer the response time is on both packets going in and out of the machine. Fairly obviously the main pipe is only so wide, with the upshot that once it's full, your modem waits. Of course this doesn't just apply to the ISP machine, this can apply to any of the routers on the way and also the destination machine too - we've all seen those download problems on machines that have something popular on them. This means that you may be connected to a 56k modem, but you're only getting 28.8 performance out of it, due to limitations beyond your control. And this sucks. Some ISP's are worse than others, with cheap crap modems that drop the connection and stuff like that. I won't mention AOL here. Again, all you can do is just shop around.
• Network coding in the game. This is pretty much all we as developers can do to accommodate the intricacies of the Internet, but there is a surprising amount that can be done. Reading all of the other points kind of makes you wonder how online real time gaming can ever be done at all, but it has to be said, the net works more than it doesn't. We'll discuss some of the cool things that can be done programming wise in a second, but first, we'll look at some of the no-no's. First up is the use of TCP/IP as your main protocol. I've already explained why this can be (and usually is) bad news. It is often used during game setup to ensure all players have the correct starting data, before we start the game data flowing.
  
  Secondly, packet bloating. You have to be careful only to transmit that data that is required; otherwise you are just sending data for the sake of it. The larger the packet you give to the UDP system, the more you are asking the network to handle. This has a big impact in client/server setups when your packet gets to the server, since YOU are only transmitting one packet, but the SERVER is receiving many such packets. This also impacts modem bandwidth. If you are running a 28.8 and getting a pretty good sustained throughput, you need to be sure that you are not allowing the packets to exceed what it's possible to push through the modem. Too big = packets getting shunted into a buffer while the modem struggles with what it's got to send, and eventually the buffer overflows and you end up at a crawl, assuming the game hasn't already puked.
  
  Third, packet frequency. Are you expecting packets to be sent faster than the communications infrastructure can really handle? You may be running at 60 frames per second, but you can bet that the Internet will have trouble sustaining that kind of packet rate.
  
  Fourth is handling out of order packets (assuming you are using UDP) and dropped packets entirely. This is more involved and requires you to be cleverer than you might think. However, if you don't handle it right, you end up with missing events, missing entities, missing effects, and sometimes, completely FUBAR'd games.
  
  Lastly, there is the aspect of online client cheating to consider. With CPL and other frag fests offering cash to winners, this is more important to consider than it used to be.

Description: sockaddr is used to specify a socket connection. Use sockaddr_in whenever possible, since it is TCP orientated. This data type is used to store information about a socket (port number, IP address, etc.) that is accepted by a server. Only a server program uses this data type!

Description: sockaddr_in is used to specify a socket connection. It contains fields to specify IP address and port. This version of sockaddr is TCP orientated; use it as much as possible. This type will be used when creating sockets.

[indent]

struct sockaddr_in
{
  short sin_family;     	// Protocol type (should be set to AF_INET)
  u_short sin_port;     	// Port number of socket
  struct in_addr sin_addr;  // IP address
  char sin_zero[8];     	// Unused
};

[/indent]

Description: WSAData is used when you load and initialize the ws2_32.dll library. This data structure is filled in for you by the WSAStartup () function. Use this to determine if the computer running your program has the right WinSock version.

Description: SOCKET is a data type used to store socket handles. These handles are used to identify the socket. SOCKET actually is nothing more than an unsigned int.

// Must be done at the beginning of every WinSock program
WSADATA w;	// used to store information about WinSock version
int error = WSAStartup (0x0202, &w);   // Fill in w

if (error)
{ // there was an error
  return;
}
if (w.wVersion != 0x0202)
{ // wrong WinSock version!
  WSACleanup (); // unload ws2_32.dll
  return;
}

SOCKET s = socket (AF_INET, SOCK_STREAM, 0); // Create socket

// Note that you should only bind server sockets, not client sockets
// SOCKET s is a valid socket
// WSAStartup has been called

sockaddr_in addr; // the address structure for a TCP socket

addr.sin_family = AF_INET;  	// Address family Internet
addr.sin_port = htons (5001);   // Assign port 5001 to this socket
addr.sin_addr.s_addr = htonl (INADDR_ANY);   // No destination
if (bind(s, (LPSOCKADDR)&addr, sizeof(addr)) == SOCKET_ERROR)
{ // error
  WSACleanup ();  // unload WinSock
  return;     	// quit
}

// WSAStartup () has been called
// SOCKET s is valid
// s has been bound to a port using sockaddr_in sock
if (listen(s,5)==SOCKET_ERROR)
{ // error!  unable to listen
  WSACleanup ();
  return;
}

// listening…

// WSAStartup () has been called
// SOCKET s is valid
// s has been bound to a port using sockaddr_in sock
sockaddr_in target;

target.sin_family = AF_INET;       	// address family Internet
target.sin_port = htons (5001);    	// set server’s port number
target.sin_addr.s_addr = inet_addr ("52.123.72.251");  // set server’s IP

if (connect(s, target, sizeof(target)) == SOCKET_ERROR)
{ // an error connecting has occurred!
  WSACleanup ();
  return;
}

// WSAStartup () has been called
// SOCKET s is valid
// s has been bound to a port using sockaddr_in sock
// s is listening

#define MAX_CLIENTS 5;         	// just used for clearness

int number_of_clients = 0;
SOCKET client[MAX_CLIENTS];    	// socket handles to clients
sockaddr client_sock[MAX_CLIENTS]; // info on client sockets

while (number_of_clients < MAX_CLIENTS) // let MAX_CLIENTS connect
{
  client[number_of_clients] =  // accept a connection
  	accept (s, client_sock[number_of_clients], &addr_size); 
  if (client[number_of_clients] == INVALID_SOCKET)
  { // error accepting connection
	WSACleanup ();
	return;
  }
  else
  { // client connected successfully
	// start a thread that will communicate with client
	startThread (client[number_of_clients]);
	number_of_clients++;
  }
}

// SOCKET s is initialized
char buffer[11];  // buffer that is 11 characters big
sprintf (buffer, "Whatever…");

send (s, buffer, sizeof(buffer), 0);

// SOCKET s is initialized
char buffer[80]; // buffer that is 80 characters big

recv (s, buffer, sizeof(buffer), 0);

// const char *Host contains either a IP address or a domain name
u_long addr = inet_addr(Host);   // try and parse it if it is an IP address
if (addr == INADDR_NONE) {
  // Host isn't an IP address, try using DNS
  hostent* HE = gethostbyname(Host);
  if (HE == 0) {
	// error: Unable to parse!
	WSACleanup ();
	return;
  }
  addr = *((u_long*)HE->h_addr_list[0]);
}

shutdown (s, SD_SEND);  // s cannot send anymore

// you should check to see if any last data has arrived here

closesocket (s);   // close

• SD_SEND means that the socket cannot send anymore
• SD_RECEIVE means that the socket cannot receive anymore
• SD_BOTH means that the socket cannot send or receive

#define WM_ONSOCKET WM_USER+1

…in message handler…

  case WM_ONSOCKET:
  {
	if (WSAGETSELECTERROR(lparam))
	{
  	// error occurred
  	WSACleanup ();
  	return 0;
	}
	switch (WSAGETSELECTEVENT(lparam))
	{
  	case FD_READ: // data has been received
    	…
  	case FD_CONNECT: // connection has been accepted
    	…
	}
  } break;

int WSAAsyncSelect (SOCKET s, HWND hWnd, usigned int wMsg, long lEvent);

FD_READ - On receiving data
FD_WRITE - The socket is ready to send data
FD_CONNECT - Server has accepted the socket and we're ready to go
FD_CLOSE - The socket has closed

#define WM_ONSOCKET WM_USER+1

…SOCKET s is initialized.  We will set it to asynchronous mode…

WSAAsyncSelect (s, hWnd, WM_ONSOCKET, (FD_READ | FD_CONNECT | FD_CLOSE));

…in the event handler…

  case WM_ONSOCKET:
  {
	if (WSAGETSELECTERROR(lparam))
	{ // error
  	WSACleanup ();
  	return 0;
	}

	switch (WSAGETSELECTEVENT(lparam))
	{
  	case FD_READ:
    	…receive data…
  	case FD_CONNECT:
    	…start sending data…
  	case FD_CLOSE:
    	…quit program…
  	default:
    	…do nothing…
	}
  } break;

if (function(…) == SOCKET_ERROR)
{
  cout << "Error!\n";
  WSACleanup ();
  return;
}

if (function(…) == SOCKET_ERROR)
{
  cout << "Error:\n";
  switch (WSAGetLastError ())
  {
	case …:
  	cout << "this type of error happened!\n";
  	break;
	case …
  }
  WSACleanup ();
  cout << "If this error happens again, sue Microsoft!\n";
  return;
}

• Small, simple, console application
• Lobby type architecture that waits for two clients to join
• Blocking sockets

• Infinite game rounds
• Graphics
• Asynchronous sockets

#define RPSS_NUMOFUSERS 0x03
#define RPSS_STARTGAME 0x04
#define RPSS_SCISSOR 0x05
#define RPSS_ROCK 0x06
#define RPSS_PAPER 0x07
#define RPSS_QUIT 0x08

• Create the protocol with which client and server will communicate.
• Start coding to the server up to where the connection is accepted.
• Start coding the client up to the part where the server accepts the connection.
• Now code your way, step-by-step, through sending and receiving data for both the client and the server.

• Don't send information every frame.
• Only send coordinates when you move or change direction.
• Don't send the entire display, only the parts which have changed.
• Don't allow more than 32 players at once.
• Players should be able to see an opponent's connection speed (33.6, 56k, ISDN, cable, ASDL, T1, etc.) before choosing to play with the opponent.

NewPosition = OldPosition

NewPosition = OldPosition + Velocity*Time

NewPosition = OldPosition + Velocity*Time + Acceleration*(time)²

• Coordinate 1 = Starting position
  
  Coordinate 2 = Position after 1 second using starting velocity
  = Coordinate1 + StartVelocity
  
  Coordinate 3 = Position after 1 second using reversed ending velocity
  = Coordinate4 – EndVelocity
  
  Coordinate 4 = Ending position
• Here are the parametric equations used to form the spline.
  
  x = At³ + Bt² + Ct + D
  y = Et³ + Ft³ + Gt + H
  
  t is the time variable. It ranges from 0 at the initial point to 1 at the end point.
• Formulating the rest of the variables.
  
  A = x₃ – 3x₂ +3x₁ – x₀
  B = 3x₂ – 6x₁ + 3x₀
  C = 3x₁ – 3x₀
  D = x₀
  
  E = y₃ – 3y₂ +3y₁ – y₀
  F = 3y₂ – 6y₁ + 3y₀
  G = 3y₁ – 3y₀
  H = y₀
• Once the equation is created, the next step is deciding how to implement it in the game. The following method is simple and effective.
  • Allow an object to move according physical laws (account for velocity and acceleration).
  • When a data packet arrives begin creating a spline to the next position.
  • Coordinates 1 and 2 of the spline can be found using the current position and velocity.
    
    Coord2 = x_old + v_old
  • Coordinates 3 and 4 are more difficult to get. Decide on the number of steps the object will take on the spline before it reaches the final position. Let this number be time T. For coordinate 4, use the new data packet to calculate the final position after t seconds. The same information can be used to calculate the velocity at the new time.
    
    Coord3 = x_packet + v_packet*t + .5*a_packet*t²
    Coord4 = Coord3 – (V_packet + a_packet*t)
    
    This method combines two forms of dead reckoning: a cubic spline, and quadratic motion. The result is more realistic.
  • Make the object travel along the spline for T frames.
  • At the end of the spline resume at step 1.

// the net_message base class
class net_message
{
public:
  net_message() { }
  ~net_message() { clear(); }
  
  void clear(void) { }

  virtual int serializeto(byte *output) { return(0); } 
  virtual void serializefrom(byte *fromdata, int datasize) { }

  DPID getfrom(void) { return(m_from); }
  DPID getto(void)   { return(m_to);   }

protected:
  
  void setfrom(DPID id) { m_from = id; }
  void setto(DPID id) { m_to = id; }

  DPID m_from;
  DPID m_to;
};

// a specific message derived from the base class – this
// example corresponds to DPSYS_CREATEPLAYERORGROUP.
class net_message_createplayerorgroup : public net_message
{
public:

  int serializeto(byte *output);
  void serializefrom(byte *fromdata, int datasize);

  uti_string getplayername(void) { return(m_playername); }
  bool isgroup(void) { return(m_isgroup); }
  net_byteblob &getdata(void) { return(m_data); }

private:
  net_byteblob m_data;
  uti_string m_playername;
  bool m_isgroup;
};

// convert a directplay message into our class
void net_message_createplayerorgroup::serializefrom(byte *fromdata, int datasize)
{
  LPDPMSG_CREATEPLAYERORGROUP lp = reinterpret_cast(fromdata);
    
  m_data.setdata(lp->lpData, lp->dwDataSize);
  m_isgroup = (lp->dwPlayerType == DPPLAYERTYPE_GROUP);
  namestructtoplayer(lp->dpnName, m_playername);
}

// another derivation.
class net_message_destroyplayerorgroup : public net_message
{
public:

  int serializeto(byte *output) { output = NULL; return(-1); } 
  void serializefrom(byte *fromdata, int datasize);

  uti_string getplayername(void) { return(m_playername); }
  bool isgroup(void) { return(m_isgroup); }

private:

  bool m_isgroup;
  uti_string m_playername;
  
};

// convert a directplay message into our class
void net_message_destroyplayerorgroup::serializefrom(byte *fromdata, int datasize)
{
  LPDPMSG_DESTROYPLAYERORGROUP lp = reinterpret_cast(fromdata);
    m_isgroup = (lp->dwPlayerType == DPPLAYERTYPE_GROUP);         	 
  namestructtoplayer(lp->dpnName, m_playername);
}

class net_message_maker
{
public:

  net_message_maker(int type) { 
	m_registry.insert(std::make_pair(type, this)); 
  }
  static net_message *constructmessage(byte *data, int datasize);
protected:
  typedef std::map net_message_maker_map;
  static net_message_maker_map m_registry;
  virtual net_message *makemessage(byte *data, int datasize) const = 0;
};

class net_message_createplayerorgroup_maker : public net_message_maker 
{ 
public: 
  net_message_createplayerorgroup_maker() : net_message_maker(DPSYS_CREATEPLAYERORGROUP) { } 
private: 
  net_message *makemessage(byte *data, int datasize) const 
  { 
	net_message_createplayerorgroup *msg = NULL; 
	try { 
  	// construct the appropriate message type
  	msg = new net_message_createplayerorgroup; 
  	// tell the message to populate itself using the byte stream
  	msg->serializefrom(data, datasize); 
	} catch(...) { 
  	// handle errors!
	} 
	return(msg); 
  } 
  static const net_message_createplayerorgroup_maker m_registerthis; 
};

net_message *net_message_maker::constructmessage(byte *data, int datasize)
{
  // cast the raw memory to a generic message to determine its type
  LPDPMSG_GENERIC lpMsg = (LPDPMSG_GENERIC)data;
  
  try {
	// find the appropriate factory in the map of factories...
	net_message_maker *maker = 
 	(*m_registry.find(lpMsg->dwType)).second;
	// use that factory to construct the net_message derivative
	return maker->makemessage(data, datasize);
  } catch(...) {
	err_printf("net_message_maker::constructmessage: logic error, I don't know
            	how to (or can't) construct message ID %d!", lpMsg->dwType);
  }
  return(NULL);
}

//A turn-based thingy

//somewhere in a header
player *cur_player;

.....

//somewhere in some source file
void switch_player(player *p) {
 	cur_player = p;
 	switch_level(p->level);
.....

//in the main loop
move((player *)&cur_player);

Opinion: Turn-based systems and one-machine single-player games in general are acceptable for "the other" gaming market, that wants to remember what the Atari felt like when they used to pull it out of the closet every other Saturday, but hard-core gamers on modern consoles should be ashamed of it. Hardcore PC gamers might even loathe it, because "MyMachineOnlyMonopoly" is averting the one big advantage of the PC as a gaming platform over everything else; networking, networking, networking. The multiplayer game market paradigm shifted towards interactivity a long, long time ago, and is presently shifting towards networking. Don't overlook it.

//pseudo-code

#define NEW_GAME    	2
#define LEAVING_GAME	4
#define SOMETHING   	8
#define RESET       	16

#define ESCAPE_SEQUENCE 0xFFFFFFFF

#define MAX_QUEUE   	16
#define MAX_BUFFER  	256

typedef struct {
int obj,x,y,z,frame;  //none of these can be 0xffffffff
input_status i;   	//no elements of this can be 0xffffffff
unsigned char flags;  //can't = 255 (0xFF)
int magic;        	//always 0xFFFFFFFF to indicate the end of the packet
} game_packet;

game_packet queue[MAX_QUEUE];
int cur_queue=0, unprocessed_packets=0;
int sync_err=0, packets_lost=0; //sync_err is a reserved flag for major
                            	//synchronozation errors

unsigned char serial_buffer[MAX_BUFFER];
int cur_buf=0, last=0;

//read this carefully (regarding an imaginary interrupt handler x):

//how it works:
//interrupt-handler x is called when a character is received from the
//serial buffer.  The interrupt handler sets serial_buffer[cur_buf] to the
//character received, increments cur_buf, and performs any necessary bounding
//work (making sure that cur_buf x also tracks
//packet-boundaries; if the last character received was 0xFF and the current
//is also 0xFF, then x will increment the global "last".  Last is tested at
//the end of the ISR;  when last reaches 3, queue[cur_queue] will be filled
//with the last sizeof(packet)-1 bytes in the serial buffer along with the
//current character, unprocessed_packets will be incremented, last will be
//set to 0, cur_buf will be set to 0, and cur_queue will be incremented.  If
//cur_queue > MAX_QUEUE, cur_queue is set to 0 and this entry is used to fill
//the packet; packets_lost is also incremented by 1, and unprocessed_packets
//is set to 1.

//what that does:
//it reads characters from the serial buffer, and when there's a complete
//packet, it fills one element of a recycling queue with the packet

...

void Send_Packet(game_packet *p) {
  ...
  Send_Out_Serial(open_port, p->obj);
  Send_Out_Serial(open_port, p->x);
  Send_Out_Serial(open_port, p->y);
  Send_Out_Serial(open_port, p->z);
  ...
}

void Process_Packets(packet *p) {
  ...
  if(!unprocessed_packets) //no new packets to process, so return
	return;

  asm cli

  for (int index=cur_queue-(unprocessed_packets-1);index <unprocessed_packets;index++) {
	Update_Game(queue[index]);
  }

  cur_queue = 0;
  unprocessed_packets = 0;

  asm sti
  ...
}

//Process_Packets would be called in the main game loop at a certain
//point.  If everything is running okay, the error-handling "features"
//built into it and interrupt-handler x shouldn't have to take over.

void Init_Game(int port) { //where port is a serial port
                     	//connected to another machine
  game_packet init;

  init.flags = NEW_GAME | RESET;
  Send_Packet(port, (game_packet*)&init);
  Init_Local_Game();
}

...

//You get the idea?

There are many books on client-server and other networking concepts...see http://www.developer.com/reference/r_servers.html for a great online collection.

#define KEYBOARD   0
#define JOYSTICK   1
#define MOUSE 	2
#define BRAIN 	3

typedef struct {
int x, y, xv, yv;
int input_device;
sprite *player_sprite;
} player;

player players[2];

draw_sprite(player[0].player_sprite);
draw_sprite(player[1].player_sprite);

move((player*)&player[0]);
move((player*)&player[1]);

typedef struct {
    char move_left, move_right, move_up, move_down, fire;
} input;

void keyboard(input *i) {
   ...
   if (key_down[KEY_LEFT])
  	i->move_left = 1;
   if (key_up[KEY_LEFT])
  	i->move_left = 0;
   if (key_down[ENTER])
  	i->fire = 1;
   ...
}

void joystick(input *i) {
   ...
   if (button_down)
  	i->fire = 1;
   if (button_up)
  	i->fire = 0;
   ...
}

void get_input(player *p) {
   input i;

   switch (p->input_device) {
      	case KEYBOARD:
   			keyboard((input *)&i);
   			break;
      	case JOYSTICK:
   			joystick((input *)&i);
   			break;
      	...
      	default:
   			if (!known_device((input *)&i, p->input_device)) {
   			game_error(NO_INPUT_DEVICE);
   			return;
   }

   if(i->move_right)
 	p->x += p->xv;
   if(i->move_left)
 	p->x -= p->xv;
   ...
}

get_input((player *)&players[0]);
get_input((player *)&players[1]);

#define MAX_PLAYERS  4

int num_players;

player players[MAX_PLAYERS];

for (int index=0; index <max_players; index++)="" move((player="" *)&player[index]);="" 

For those of you that don't know what a linked list is, it's really simple. A linked list is a chain. Each link in a linked list contains some data or a pointer to some data, and a pointer to the next link. Each link on the chain is called a node. The first link on the chain is called the head. So it's like this: typedef struct { int data; void *next; } node; node head; So (node *)head->next = the next node on the linked list. When you follow the next pointers of each node on the linked list until you reach a node who has no next pointer (node->next = NULL), and process the data on each node as you go, you are said to be walking, or transversing, the linked list.

What's a protocol and how do I use it?
How are protocols maintained by the Global Internet?
The TCP Protocol
The UDP Protocol
The IP Protocol

IP Addresses
The Domain Name System
The ICMP Protocol
The GGP Protocol
The ARP and RARP Protocols

Win32 TCP/IP Support: WinSock

Initializing the WinSock Library
Creating Sockets
Binding and Connecting
Addressing and Name Service Support
Network and Host Byte-order
Sending and Receiving Data
How to get your sockets to listen()
Blockage and Synchronicity
Errors in WinSock
Cleaning up after yourself
What I didn't cover

TCP Header

UDP Header

IP Header

IP Address Classes

• An application protocol specific to what we're trying to do (SMTP, for instance)
• TCP or UDP to oversee data transaction
• IP, to actually transmit data packets to a given destination
• Physical protocols like PPP to make data transfer happen.

WSADATA wsaData;
if (WSAStartup(MAKEWORD(1, 0), &wsaData)) {
   ErrorMessage("Error while attempting to initialize WinSock");
}

SOCKET s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

struct sockaddr {
    	u_short sa_family;
    	char sa_data[14];
};

struct sockaddr_in {
   	short sin_family;
   	u_short sin_port;
   	struct in_addr sin_addr;
   	char sin_zero[8];
};

struct in_addr {
            	union {
                    	struct { u_char s_b1,s_b2,s_b3,s_b4; } S_un_b;
                    	struct { u_short s_w1,s_w2; } S_un_w;
                    	u_long S_addr;
            	} S_un;
};

struct sockaddr_in addr;

...

SOCKET s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

//assume that we fill addr somewhere in here

...

connect(s, (struct sockaddr *)&addr, sizeof(addr));

...

struct hostent {
   	char FAR *h_name;
   	char FAR *FAR *h_aliases;
   	short h_addrtype;
   	short h_length;
   	char FAR* FAR* h_addr_list;
#define h_addr  h_addr_list[0]
};

struct hostent *host_addr;
host_addr = gethostbyname("gamedev.net");

struct hostent *host_addr;
host_addr = gethostbyaddr(inet_addr("127.0.0.0"), sizeof(unsigned long), AF_INET);

SOCKET s;
char *data = "Hello"
...

//We'd create socket s somewhere in here and connect it

...

send(s, &data, 5, 0);

SOCKET s;
char data[256];
...

//We'd create socket s somewhere in here

...

recv(s, &data, sizeof(data), 0);

SOCKET s;
struct sockaddr_in addr;
char data[256];
...

//We'd create socket s somewhere in here and fill in addr

...

sendto(s, &data, sizeof(data), 0, &addr, sizeof(addr));

SOCKET s;
struct sockaddr_in addr;
char data[256];
int x;
...

//We'd create socket s somewhere in here

...

x = sizeof(addr);
recvfrom(s, &data, sizeof(data), 0, &addr, &x);

SOCKET s;

...

//create and bind socket s

...

listen(s, SOMAXCONN);

SOCKET s;
struct sockaddr_in addr;
int x = sizeof(addr);
...

//create and bind socket s, then listen for connetions

...

accept(s, &addr, &x);

WSAAsyncSelect Event Flags

#define SOCKET_EVENT_HAS_HAPPENED   	25252

SOCKET s;
HWND mywnd;

...

//create s and mywnd

...

WSAAsyncSelect(s, mywnd, SOCKET_EVENT_HAS_HAPPENED, FD_READ | FD_WRITE | FD_ACCEPT);