Conductor

I have just found this one in the WayBack Machine. It has some interesting information.


 * The VR·1 Conductor White Paper

Conductor is an Internet Client-Server system for building, launching, running and supporting massively multi-player real-time games. But what does this really mean? The following is a discussion and exploration of the technical problems of online games, and in particular the solutions developed by VR·1 and used in the Conductor system.

Why use the Internet?

 * The Internet is the best choice for multi-player games. The larger your market, the more choices you have in what kind of game to make, and the Internet gives you access to the largest market. If you want to make a massively multi-player role-playing game, or a game that may only appeal to a niche market, or if you just want to make a game that as many people as possible can play, then you need to look to the Internet.


 * Anyone can play an Internet game, and any Internet Service Provider (ISP) can run a game. This flexibility helps ISPs because any of them can move into the online games market with a minimal investment, and it helps game developers because they can negotiate with any ISP.


 * Despite the advantages of the Internet, it does have a downside. The Internet is a network that runs on top of other networks. The Internet can run on almost any computer system, so it is run on almost all computer systems. The same design choices that allow the Internet to be everywhere make the Internet the lowest common denominator of the network world.


 * There are usually only four things that an Internet connection provides:


 * A very powerful system for addressing and delivering messages to a huge number of unstable computers.
 * Error detection. Individual packets sent over the Internet will not be corrupted.
 * TCP (Transmission Control Protocol) will reliably deliver a stream of packets. Every packet will arrive, and they will always arrive in the order they were sent. TCP is designed for bulk data transport, so it opens a connection, send the packets as quickly as possible, and then closes the connection.
 * UDP (User Datagram Protocol) will send a packet to another computer. There is no guarantee that a packet will arrive, and no guarantee that packets will arrive in the same order that they were sent. UDP does not establish a connection to a particular computer.
 * The Internet does not have a standard way to:


 * Send one message to several different computers. (Multicasting exists, but it is not widespread.)
 * Communicate in a secure, tamper resistant manner. (Encryption is suggested for the next revision of the Internet Protocol.)
 * Reserve bandwidth, so a stream of data can be sent without having to worry about what other people are sending over the network.
 * Guarantee latency, so one computer can be sure of how long it will take for a packet to reach another computer.
 * Run and administrate a game, or monitor the quality of player's connections.
 * Because massively multi-player games must work over the Internet, Conductor provides additional functionality to make it easy to build and run massively multi-player real-time games.


 * Selectively broadcasts data.
 * Limits Server access to registered players
 * Provides feedback about bandwidth, and tools for a game to limit its bandwidth, to assure the best possible play experience.
 * Controls dataflow to minimize latency.
 * Provides remote monitoring abilities, to check on a Server or player connection.

Why use a Client-Server system?

 * An ISP is needed to run a Conductor game because Conductor uses a Client-Server architecture. There are three reasons for using a Server-based system:


 * A central Server lets a game keep persistent information, and process global data about the game universe. This can be important for role-playing games, economic models, or any game that involves long term planning.
 * A central Server can enforce rules, to prevent players from cheating.
 * A Server is useful to reduce bandwidth if even a dozen of players want to participate in the same game. For real-time games with hundreds or thousands of players, a Server is essential.

What is needed for Massively Multi-Player games?

 * Bandwidth is the primary factor that limits the number of players in a game. Each player needs to be regularly informed of how the game universe is changing. Most real-time games need 4-6 updates per second; if updates are less frequent, players may appear to jump. This means that with a 14.4 kbps modem, each update can be no larger than 450 bytes, and should be closer to 250 bytes.
 * Using a Server helps the bandwidth problem in three ways:


 * 1. Rather than sending a series of small packets, a Server can concatenate the player updates into a larger packet. This is important because each Internet packet has at least 28 bytes of header attached to it.
 * If the updates are sent separately, even if the update information for each player is only 10 bytes, there can only be 6 remote players, for a total of 7 players in the same game.
 * 250 bytes/update = 6 players * ( 28 bytes of header + 10 bytes of update )
 * But, if the Server collects and concatenates all of the player updates into one larger packet, then there can be 22 remote players.
 * 250 bytes/update = 28 bytes of header + ( 22 players * 10 bytes of update )
 * 2. The Server can limit what information each player needs to receive. Rather than sending an update about every player to every other player, the Server can decide not to send an update about a player that is too far away to be seen. This means that each player can see 22 other players at one time, and many more than that can be playing in the same game.
 * Conductor's packet priority and "Aperture" functions provide a set of tools for game developers to restrict what information gets sent to each Client. Conductor also monitors the quality of each Client connection, so it can reduce the amount of data being sent to make the best use of the bandwidth available.


 * 3. Because a central Server is run by an ISP, the Server can be a more powerful computer with a better network connection. Rather than being limited to 14.4 or even 56 kbps, the Server can have a 100 Mbps connection. With a more powerful Server, more players can participate in the same game.
 * The Conductor Server is portable, so it can be run on Windows NT, Solaris, Irix, or Linux. This gives ISPs a great deal of flexibility in choosing a Server that provides the right balance between cost and power. Game developers also benefit from this choice, because they can develop and test on almost any computer. As a game grows in popularity, the Server can be easily upgraded if necessary.

What is needed for Real-Time games?

 * Latency is the challenge for real-time games. There are many causes of latency. Some types of latency depend on distance, or the modem used, but some types of latency depend on how information is sent over the Internet.


 * One of the most important considerations is that Internet routers and modems use "first in, first out" buffers. This means that if there is already data waiting to be sent, then the older data will be sent before the newer data. If there is nothing buffered waiting to be sent, then the latency is reduced. This is used by Conductor in three ways:


 * By monitoring the data transmission rate, latency, and packet loss to each Client, the Conductor Server can calculate how quickly it can send data while still getting the minimum latency.
 * By queuing packets, and sorting them itself, the Conductor Server can make sure that the newest and most important packets get sent as quickly as possible.
 * By sending packets at regular intervals, the Conductor Server can reduce buffering in the network and increase the available bandwidth.
 * Latency problems are particularly severe with TCP. One of the benefits of TCP is that it establishes a connection and monitors that connection to avoid flooding it. To avoid network congestion problems, TCP will gradually increase its speed, and quickly reduce its speed if packets start being lost. To avoid resending too many packets, TCP also waits for a long time before deciding that a packet was lost.


 * If a packet is lost, TCP needs to wait for at least the average round trip time before it can send it again. When the resent packet finally arrives it will have taken at least three times as long to arrive, usually longer. Because TCP packets always arrive in the correct order, if one packet is lost, everything after that is delayed also.


 * A better choice for games is to use UDP. While UDP packets may never arrive, on average they will arrive sooner. In real-time games it is usually more important for most information to arrive quickly, even if there is some loss.


 * One disadvantage of UDP is that it does not keep a persistent connection, so a game developer cannot tell how much data can be sent, and the protocol does not address the problems of network congestion. Sloppy use of UDP by some Internet telephones has led to them being banned by some ISPs. Because Conductor monitors the quality of each connection, it can avoid most network congestion problems, which provides a better experience for the players as well as the ISP running the Server.


 * Conductor cannot eliminate all types of latency, for example:


 * High speed modems add 80 ms of round-trip latency to a connection. This seems counterintuitive, but it is caused by a flaw in the standard. The v.42 standard uses packets. (V.42 is the CCITT standard for modem error correction.) By using packets, there is no need for start and stop bits, so it can send almost 20% more data. Unfortunately small packets are less efficient, so the modem will wait up to 40 ms for more data to arrive before sending a packet. There is no good solution for this. Turning off error correction will drastically reduce bandwidth and increase packet loss. The best solution would be for modem manufacturers to add a software switch to turn off this delay. (ISDN does not have this problem.)
 * Sending data over a modem takes 1 ms per byte. Because data is sent over the modem in a stream, it needs to be buffered until it all arrives before the packet can be sent. This adds a 0.5 ms delay, in each direction, per byte of data sent across a 14.4 kbps modem. Again, there is nothing that can be done.
 * Modems occasionally "retrain" due to differences in phone line quality. This retraining process is used to either increase or decrease the amount of data being sent, depending on what the phone line can handle. Modems will occasionally retrain during the connection. This retraining may cause a delay of 10-15 seconds, during which no information is sent. This might not be too noticeable while browsing the Web, but it can be fatal to a real-time game. Retraining should be disabled if possible.
 * Light travels at 300,000 km/s. Coaxial cable is almost as fast as light, fiber optics drop to about 70% of the speed of light, and other cables are significantly slower. This means that it takes 30-100 ms for a signal to cross North America. Satellite communications add 250 ms.
 * Because an Internet game will have to cope with 300 ms latency, the Clients need to be able to predict where opponents are. To make this easier, Conductor provides a clock on the Client that is synchronized with the Server. By putting a synchronised time stamp on game data when a Client generates it, every other client can know how old the information is, and interpolate the current position.


 * Conductor's time synchronization is based on the Network Time Protocol (NTP) standard. In addition to being able to synchronize the Client's time, Conductor automatically tracks how the Client's clock drifts. This lets Conductor resynchronize the Client when it is necessary.

Tools for Building Games

 * The Conductor Software Development Kit (SDK) provides a clear programming interface to the many Conductor functions. A sample game, with complete source code, is included to clearly show how the Conductor functions are used in a game.


 * The Conductor SDK makes developing an Internet game as simple as possible without forcing a particular business model on an ISP. Conductor does not require games to be built in a specific way. The Conductor SDK leaves game development up to game developers.


 * Conductor is a powerful set of tools for game developers to get the best performance out of the Internet, and a set of tools for ISPs to easily run online games.

Tools for Launching Games

 * It is easy to provide an interface for joining a game, if the Server and the game never change. If an ISP wants to change to a Server with a different Internet address, or run different games at different times of day, or if a player wants to see who is playing in a game before joining, then a more complex system is required.


 * Conductor uses the industry standard World Wide Web to provide a simple, familiar interface for players to join a game. A CGI (Common Gateway Interface) program running on the ISP's Web server produces a digital "Ticket" which is passed to the Client-side game "Launcher". The Launcher is a small program that can check that the appropriate game is installed, check the version of the game, and help the player download and install a new game, or an update to an existing game, if necessary. The Launcher will then start the game, and tell it which server to connect to. The Launcher makes it simple and straightforward for a player to switch from browsing a Web page, getting information about a game, to actually playing the game.


 * The digital Ticket is cryptographically authenticated, so the Server can check that it was generated by the ISP's Launch page. This lets an ISP easily restrict access to the Conductor Server by restricting access to the Launch page using standard Web security tools. For private networks, and free access Servers, this feature can be disabled.

Tools for Running and Supporting Games

 * The developer may leave when the game is released, but there is still some work for the ISP. At the very least an ISP needs to worry about billing for the game. Other ISPs may want to have human "Guides" to make sure that everyone is behaving appropriately, and that everyone is enjoying themselves.


 * The Conductor Server itself controls communication, player authentication, creating and joining games, lists of players allowed into private games, and billing information. The Server produces a simple log file of player connection information. Depending on how the ISP is billing for the game, this can be used to charge by the day, hour, or minute. This file can also hold game specific information, if it is relevant.


 * The Conductor Server runs dynamically-linked "Game Drivers", which provide game specific logic and functionality. For a simple game, the Driver may do little more than call the appropriate Conductor functions. A more complex Game Driver may keep a persistent database of player information or run AI (artificial intelligence) opponents.


 * Each Conductor Server can have several game drivers, one for every type of game that it can host. Each Game Driver can run multiple games, so there might need to be several Guides working on the same Server.


 * The Conductor suite includes a Manager Client, which allows several Guides to connect to a Conductor Server and monitor system, server, game, and player information. This lets Guides check a player's connection status, and warn or suspend a player for inappropriate behavior. A Game Driver can also display game specific information to the Manager through a standard interface. The Manager can be configured to automatically monitor certain information and page, fax or e-mail a system administrator if the Server starts to run out of disk space, CPU usage is too high, or any other requested event occurs.