- 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.
- 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.
- 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.
- 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.
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.
- "Foxes, Rabbits, and Carrots"
- "The Game and How to Play it"
- "A Brief Review of the MUSCLE Networking Layer"
- "muscled, The basic MUSCLE server"
- "Customizing the MUSCLE server"
- "How to Set up the Custom Server Logic"
- "The FRCPlayerSession Class"
- "The FRCGameStateSession class"
- "Overview of the FRC server"
- "The FoxRabbitCarrot Client Program"
- "How the Client Handles Database Update Messages"
- "MUSCLE gaming Performance Issues"