posted by Jeremy Friesner on Mon 12th Aug 2002 20:52 UTC

"muscled, The basic MUSCLE server"
The MUSCLE server program ("muscled") is somewhat complex internally, but its basic function is quite simple: it accepts TCP connections from multiple clients and forwards Messages from one client to another. This may not seem useful at first glance -- wouldn't it be faster and simpler for the clients to send the Messages to each other directly? As it turns out, not always. Forwarding the Messages through a central server has the following advantages:
  1. Discovery. Clients can use the server to find out what other clients are currently available, and send the other clients Messages, without having to know the other clients' IP addresses in advance.
  2. Broadcasting. If a client wishes to send the same Message to two or more other clients, he need only send one copy of the Message to the server, together with instructions telling the server who to forward it to. The server can then forward a copy of the Message out to each specified destination client. Given that many clients may be on slow modem connections, while the server is likely to be on a fast dedicated connection, this can be very efficient.
  3. Firewalls. Often, clients are hiding behind firewalls that do not allow incoming TCP connections. This means that there is no way for another client to connect to the firewalled client directly. However, the firewalled client is still able to connect out to the server machine, and thus the two clients may communicate indirectly (through the server) without any problems.
  4. Centralized data storage. For many apps, there is certain data (e.g. the user's name, or the position of his pieces on the game board) that is useful to many other clients. The MUSCLE server allows each client to upload data of interest into a database held by the server, where other clients may access it without using up any of the original client's bandwidth. In addition, the MUSCLE server has a subscription mechanism by which clients may be automatically notified when the server-hosted data they are interested gets updated.
Built upon and (integrated with) the MUSCLE server's Message-forwarding functionality is the server-side database. As mentioned above, the server-side database lets any MUSCLE client upload data to the server, where other clients can access it more quickly. The uploaded data is not persistent, and will disappear when the connection to the client is broken. The server-side database's organization is very simple -- it is a single-rooted tree of nodes, and each node in the tree holds a single "data payload" Message object. An example of what this node tree might look like is shown below:

Whenever a client connects to the server, nodes representing his IP address and unique session ID are added to the first and second levels of the tree (i.e at Depths 1 and 2 in the diagram). Any data that client uploads to the server appears as nodes underneath his second-level ("session") node. A MUSCLE client may upload a hierarchy of nodes as deep as it wishes, although in practice 1 to 5 levels of hierarchy are common.

Because each node in the tree has an ASCII label, many of the wildcarding and set-specification tricks commonly applied when working with filesystems are also available to MUSCLE clients. For example, if a MUSCLE client wanted to be notified whenever another client connected to (or disconnected from) the server, he could post a subscription to the path "/*/*", and thus would get notifications whenever a "session ID node" was added to or removed from the node tree. For more information on how the MUSCLE database works, please see the MUSCLE Beginner's Guide.

Table of contents
  1. "Foxes, Rabbits, and Carrots"
  2. "The Game and How to Play it"
  3. "A Brief Review of the MUSCLE Networking Layer"
  4. "muscled, The basic MUSCLE server"
  5. "Customizing the MUSCLE server"
  6. "How to Set up the Custom Server Logic"
  7. "The FRCPlayerSession Class"
  8. "The FRCGameStateSession class"
  9. "Overview of the FRC server"
  10. "The FoxRabbitCarrot Client Program"
  11. "How the Client Handles Database Update Messages"
  12. "MUSCLE gaming Performance Issues"
e p (0)    8 Comment(s)

Technology White Papers

See More