MAST: Technical details

Threads

MAST is a multi-threaded application, which is used to share the visual representation of applications in a scalable manner using Multicast. Version 0.8 uses qt3 for the Linux version and MFC for the GUI of the Windows version. In version 0.9 (soon to be released) qt4 is used for both the windows and UNIX versions.

Each shared application is handled by an individual thread (in Linux and version 0.9) and the data transported to the other participants using either multicast or unicast (to work with a bridge). This allows multiple applications to be shared by a participant at the same time. Windows has a single thread which is created to share one application at a time. In version 0.8 one port is used to transport the session information and the data, this means that each packet has a header containing the participant details, application details, segment details, window sizes etc. This has been changed in version 0.9 to have two ports one for the session information and another for the raw data. The header for the data now only contains the application id and the size of the data. The data is compressed to reduce the size of the data, to achieve this we are using zlibs.

A thread is created when MAST connects, which is used to receive the data sent by other participants. A single thread is used to view the application data being sent. This restricts the user to viewing only one application at a time, but simplifies the implementation. In version 0.9 there is a thread for each viewed application which means that multiple applications can be viewed at the same time. Because multiple applications can be shared within the group the applications have a unique identification. This allows users to check the receiving socket to see if the data is associated with the application of interest before coping the data into the appropriate buffers.

Sending Visual Data

The raw data is obtained from the screen using Bitmaps in Windows and XShm library in Linux. The raw data is then split into segments which represent a block in the screen. The data for the segment is then compressed to reduce the amount of data being transported. The data is often still too large to be transported in a single packet, so the segments are sent as slices. These slices are received at the other side and placed in segment buffers. Using UDP means that the packets can be received out of order or not at all. The slices are placed in the appropriate position in the segment buffer and once the buffer is full it is displayed by the receiving participant.

Displaying the Data

MAST uses Simple Direct Media Layer (SDL) to display the data. An SDL window is created and the segment copied into the buffer. The updated part of the SDL window is refreshed and the changes should be seen by the end user.

Sending Updates (Linux only)

There are two mechanisms used in the Linux version to reduce the amount of data sent and increase the responsiveness. A refresh of the entire application at set intervals (this is used in the Windows version) and an update of changes when an event occurs in the application that is being shared. For the update MAST checks the shared application window for updates by checking for events on the connection to the xserver. If an event occurs the segments are checked for changes (by comparing some pixels within the segments). If a change occurs then the current pointer (pointing to the current segment) is switched with the previous pointer (pointing to the previous segment). Changing the values of the two pointers is much faster than copying the current segment buffer to the previous segment buffer.

MAST as Service

MAST has a file which is used to store the connection settings, if MAST is executed with command line arguments (e.g. mast 224.5.6.7/50012 ) then it will be set that MAST is running as a service and the connection details will be disabled and a connection will be attempted with the supplied details. MAST can also resolve the address if a machine name is used or a unicast address.

To use with AG there are two files that have to be supplied in the zip file when packaged with the executable. MASTService.svc and MASTService.py these contain the application details and the implementation to execute from details received through the Node service infrastructure respectively.

General references

Papers that describe the MAST application and more general collaboratie issues are:

---