collab/servers/chatsrv
collab/servers/mpx
collab/servers/wbsrv
The services directory contains a single ctl file and a set of subdirectories, numbered 0, 1 and so on. The ctl is used to activate and access services. Each service instance is identified by a name; clients connect to a given instance by presenting its name. Each directory represents one instance of a service. Each service instance corresponds to a name space; the clients all share that name space. The name space is determined by the service.
A client wishing to make use of the services must first dial(2) to connect to collabsrv, and authenticate and mount the resulting 9P connection. It can do so using the mount command (see bind(1)), or by using security-auth(2) and Sys->mount (see sys-bind(2)). Normally, this is done by collab(1).
A new connection to a particular service is requested by opening the ctl file for reading and writing, writing a service request to it, and reading back the number of the directory corresponding to the requested service. A service request written to ctl is text of the following form:
where service is a string specifying the type of service (eg, chat) and id is a string identifying the instance. The server does not interpret id; it is up to the clients to agree a naming convention (often using the name of a shared file as an id). Collabsrv will connect to instance id of the requested service type if one is already running, or start one if necessary; the write request returns an error if the service cannot be started. Following a successful write to ctl, a read will return the number of the service directory containing the client's private connection to that service instance. Closing the ctl file disconnects from the service.
Available services are defined by a configuration file /services/collab/services.cfg, which contains a sequence of configuration entries of the following form:
service path=disfile
where service is the name presented in a service request, and disfile names a Dis file implementing that service; path names are interpreted relative to /services/collab, but usually refer to files in /dis/collab/servers.
Each collabsrv service is represented by a name space peculiar to that service. The interface to the service is therefore implemented by a service-specific 9P server (disfile in the configuration file). Current services are described below.
+++ name has arrived --- name has left
as clients come and go.
A message written to root is replicated on all instances of leaf that are currently open. A message written to any instance of leaf will be read by the process reading root. Data written to both root and leaf has a prefix added to identify the sender, causing messages to have the following format:
seq clientid op name data
where seq is a unique message sequence number; clientid is a unique number identifying the process amongst currently connected clients, with 0 identifying the root process; op is a single character giving the message type (see below); name is the sending process's user name; and data is the data written by the process, which can be text or binary (the message header is always text). Mpx also generates messages as root and leaf processes arrive and leave. These are identified by op. The various op values and the direction in which they can occur are listed below:
Messages are only ever sent from the root to all leaves, or from a leaf to the root, never from leaf to leaf; the root process could of course rebroadcast a message from a leaf. The multiplexor service is used to implement a real-time poll (see poll and poller in collab-clients(1)), but could be used for several other services, such as auctions.
where all values are space-separated decimal numbers: colour is an index into the rgbv(6) colour map; width is the width of the line in pixels, and the sequence of coordinate pairs defines the connected line segments to draw. A stroke is transmitted from one client to all others by writing a stroke description to the file in a single write. Each read returns a description of a stroke made by another client.
A whiteboard client should read the wb.bit file to obtain its image, then read the strokes file for instructions to keep it up to date.
| COLLABSRV(8 ) | Rev: Tue Mar 31 02:42:38 GMT 2015 |