Architecture Documentation

There are two "levels" of architecture that are important to distinguish when dealing with distributed systems: First, there is the system level, which comprises the entirety of all involved sub-systems. The second level, in contrast, focuses on the individual sub-systems or nodes.

Applied to Saros, the system level is rather easy to understand:

  • During a running session the system is composed of multiple Saros-instances that work together in a Shared Session. In order to communicate with the other participants and to keep the local copies of shared files consistent Saros uses XMPP-messages. Saros distributes these messages among the participants using a Client-Server-Architecture. The Server is located at the Host's machine, which means that every participant first sends her messages to the Server, and the Server distributes them to all other participants (including the client-component of the Host).

The node level is more concerned with the infrastructure of a single Saros instance and this slightly more complicated. To understand the architecture of Saros, it is helpful to keep in mind that Saros has two basic operation modes:

  • Changing Session is rather transitional, because it will only be entered to change the configuration of a Session which includes setting it up, tearing it down, adding and removing participants as well as resources.
  • Running Session is the mode Saros will normally run in; it is the normal work mode that has no inherent end.

The distinction between the two working modes is also reflected on the system level, because Saros uses different kinds of XMPP-message for each:

    For changing a Session, Saros uses MESSAGES. The most important group of such changes is the Invitation Process. Different MESSAGES will be distinguished by their type (the PackageExtension).
  • Activities:
    During a running Session, Saros needs to capture local actions of each user and distribute them to the other participants as events so they can react upon them (e.g. performing the same text edit or painting an updated viewport annotation because a user scrolled down). Saros packages such events as Activities. Basically everything that doesn't change the Session itself is transmitted using Activities.

The two working modes are realized by different components (not entirely, but partially) which will be described in on the next pages.