Remote Collaboration System Architecture
Project#5 – Fall 2002

Riddhiman Ghosh

CSE 681 – Software Modeling and Analysis
12/14/2002

Table of Contents

Introduction
	3	
User Interface
	6	
Use Cases
	8	
Context Diagram
	14	
Client Module Diagram
	16	
Server Module Diagram
	20	
Whiteboard Activity Diagram
	25	
Chat Activity Diagram
	35	
Annotation Activity Diagram
	39	
Security
	43	
Voice Messaging
	46	
Critical Issues
	48	
Summary
	64	
Appendix
	65	

Introduction:

To develop and implement software efficiently people need to be able to exchange information, work together and deliver results – whether they are separated by cubicles or floors in the same organization, or they are separated by continents, with nothing but telephone cables connecting the two. The Collaboration System will use the same infrastructure as that of a telephone call – the dial-up infrastructure—but provide a user experience and utility infinitely greater. This is one of the major challenges and a major motivation in the design of the Collaboration Server. While the Collaboration System intends to provide rich user experience to users with a good bandwidth connection, it also tries to provide a user-experience as rich to those on the other side of the “digital bandwidth divide”! The Collaboration System proves immensely useful to users with dial-up connections to our server, even if the method of interaction of this user may vary slightly from a user “closer” (in terms of bandwidth) to our server. This architecture document intends to outline the architectural policies that enable a user in India, on a low bandwidth connection and on a different time-zone, to collaborate with his peers in the USA. On the whole the Remote Collaboration System has been designed with 3 classes of users in mind, depending on the type of their connection to the server: 
•	Users with a Intranet connection (high-speed) to the server
•	Users with a wideband Internet connection to the server  and 
•	Users with a dial-up Internet connection to the server

As is obvious the utility of such a tool is huge. 

The teams of software developers in different locations need to collaborate in different contexts, and the system has to provide different tools to allow this kind of collaboration. 

The Remote Collaboration System includes support for the following functionalities:

•	A Chat Service that allows real-time communication between the various users of the system. This service proves useful to exchange snippets of information between the collaborators. An entire chat session can be assigned to persistent storage in order to enable the retrieval of the discussion that took place in a session, at a future time. This is useful, for instance to a user who was not able to be a part of the discussion on account of being in a different time-zone or some other reason. 

•	A Voice Messaging Service is included in our system. This is an enhancement to the Collaboration System however, and not necessary for effective use of the system. This feature is disabled on users with a dial-up connection. The basic Voice Messaging functionality can be very easily replicated in low-bandwidth situations, with all the users communicating over the telephone. However for users who have the required bandwidth, the Voice Messaging service provides a enriched functionality which allows easily storing, transmitting and editing conversation recorded during a collaboration session. 

•	A Virtual Meeting Room with an electronic White Board. This white board is a canvas for different users to communicate more effectively than just exchanging text messages. The white board permits using multi-media content drawings, hand-sketches, text messages, as well as supports the display of industry-standard content such as Microsoft Visio, Word files (and thus includes full graphics and multi-media support). This structure of the whiteboard proves to be an extremely effective communication and collaboration medium. (Enhanced hardware support in the form of large wall-panel displays or large plasma screens, though not necessary, will be able to make maximum use of the whiteboard).  

•	Since a major use of the Collaboration System is to aid teams in software development, the system includes a Component Server that acts as a means to store and make available all versions of a software component to all development teams working on a project. In the distributed software development paradigm most teams will be developing software used by other teams, potentially leading to incompatibilities between components and other problems. Hence source-code control becomes imperative – a service offered by the Component Server.   

•	An Annotation Facility in the system allows us to review and make comments about components in the Component Server. The remarks and annotations become a permanent part of the component, and are at once available to all the users of the Collaboration System. 

Our system intends to use the services provided by .NET Remoting to establish connections between the client and the server. All the messages that flow between the client and the server are encoded in XML. Though this definitely adds a certain amount of overhead, XML helps us develop a standard format for messages that can be interpreted easily at the server side. The XML messages all follow a standard format that divides a message into a header, a trailer and the body, as shown below. The type of information carried in the body varies significantly depending on the type of message being transmitted. Different message types (both command and data messages) have been created to support the various functionalities of our system. The header includes information on the type of information and also tells the server how to handle the contained information. A more detailed exposition of these messages appears elsewhere in this document. 

The Collaboration System is a secure environment. Security becomes a vital concern since the system will typically be handling the intellectual property of an organization – an extremely valued resource in today’s world. An active security policy is maintained to prevent and inadvertent of willful compromise of the security of the system. 

Applications and Uses of the Remote Collaboration System:

The services offered by the Remote Collaboration System, and its structure make it suitable for a variety of applications. 

•	Remote Meetings
	It is possible to conduct meetings between people in widely separated geographical regions. The managers involved in the meeting can exchange views, idea, charts and communicate through text messages or by simply speaking to each other. The security features in place in the system make it suitable for formal business and legal meetings. The proceedings of the meeting can also be stored for future review. 

•	Distributed Design and Code Review
The component server and annotation component together with the other messaging features make it possible to have a distributed code review session – with software components coming from one location, and the reviewers coming from another. The results of the code review can be immediately put “online” with the help of the annotation component. This provides a great deal of flexibility.

•	Distance Education
The Collaboration System is an enabling technology for the concept of a remote classroom. The Whiteboard can be used as a classroom “blackboard”. Students and teachers belonging to different time zones can meet through the system. 

•	Collaborative Work Sessions:
This allows to work together in spite of being located at different locations. For instance software developers can exchange code files through the component server and also communicate through messages and advanced diagramming. 

•	Document Viewer:
The System includes a “MultiViewer” that displays standard document formats such as Visio and Word documents. This provides the system to capability to view complex diagrams stored at a remote server, facilitating effective exchange of information. 

•	Presentations from one location to the other:
The system enables a user at one location conduct a presentation at several other remote sites. The combination of the MultiViewer, the Whiteboard and the various messaging features make for effective presentations. The proceedings of the presentation could also be assigned to persistent storage for archival and future retrieval purposes. 

User Interface:	

The User Interface of the Remote Collaboration System Client is attached on the next page. It gives us a basic idea of the functionality provided to the user. 

The user interface shows a tabbed panel display with one tab containing the Component Server UI and the other containing the 

containing the interface for the chat voice, annotation and whiteboard sub systems. 

•	It enables users to join a particular collaboration session by entering their project group affiliation. It also allows us to send invitations to other users of the system to virtual meetings. The disconnect button signs him out of the system. 

•	The annotation window allows the user to select a component for annotation. The annotation windows allows for entering of the annotation information.

•	The voice messaging frame allows us to turn on or off the voice messaging feature and also control the volume of speech. 
•	The chat frame allows us to enter send messages to users and also view messages being exchanged in the chat room. 

•	The Whiteboard canvas displays all the graphical information being exchanged in the system. It contains a palette of drawing tools that enable us to draw on the canvas. There are “empty” buttons on the canvas that allows s to invoke custom / composite objects quickly for drawing on the whiteboard. These custom objects can be assigned by the user to the quick launch buttons on the palette. 

•	The MultiViewer space displays standard document formats on the screen – for e.g. Word documents or Visio files. For both the Whiteboard and the MultiViewer, the user can choose to have a full screen view of what is being displayed. 

Use Cases:

The use case diagram shown on the next page documents the interactions of a user with the Remote Collaboration System. The important uses cases are discussed below.

•	Activating and Ending the Remote Collaboration System: 
The Remote Collaboration Server is under the control of the Administrator on the server side. He has the exclusive rights to begin the operation of the collaboration system, or to end it. (For example if it were discovered that the security of the system had been somehow compromised, a central authority to immediately stop the system and take remedial action is vital) The server application provides the necessary functionality to support this use case. 

•	Maintaining User Access Control: 
The security policy of the Remote Collaboration system provides different levels of access to different users. Not all users have the authority for instance, to set up collaboration sessions or for change the time an  online meeting will be held. A database of user rights and privileges is stored on the server. The administrator on the server alone has the right to modify this database.

•	Sending Invitations to Collaboration Sessions: 
Users on the collaboration system can setup meetings on the fly by, or add users to an existing meeting by issuing invitations. By default, all the members of a particular project team are allowed to be a part of a collaboration session. However, privileged users can also invite users external to the project team. 	

•	Exchanging Public Chat Messages: 
The Users of the collaboration system can communicate with each other via the chat messages. A user can communicate with the entire project team through text messages.

•	Exchanging Private Messages: 
The System also provides for private messaging – a user is granted an exclusive communication channel with certain other users. He can conduct a private messaging session simultaneously as he is participating in a public chat session

•	Storing Chat Sessions:
It is possible for a user to save the entire proceedings of a chat session to persistent storage. All of the messages exchanged between the users is stored to disk along with a time-stamp. This makes it possible for users to retrieve a past chat session to aid in recollection or verification of earlier discussions. 

•	Exchanging files through the Component Server
An integral part of collaborating remotely is to be able to exchange code and documentation files with each other. This is enabled with the help of the Component Server, which acts as a central repository to aid in distributed software development, while maintaining source code control. Clients can upload and download software components into the Component Server. It is a means to store and make available all versions of a component to all development teams. Strict versioning schemes are used to ensure that no incompatibilities exist between different pieces of code using the same component. 

•	Creating Annotations for Components
Since there are several users collaborating at once, it is only natural that different users will have different views and opinions on the components. Annotation allows one to record these comments onto a component – every component has an associated annotation file associated with it. A versioning scheme is also applied to annotation files to maintain the integrity of the annotation process, and also to help one gauge the evolution of the component (or annotation). Annotations are stored along with the information regarding the author and the time/date of annotation. 

•	Editing Existing Component Annotations
Existing annotations of components can also be edited in the Remote Collaboration System. Modifications to annotations create new versions of the annotation file, with the original annotation untouched. This is a part of the versioning policy implemented by the Component Server.  

•	Viewing Merged Annotations
This use case deals with viewing several versions of an annotation simultaneously. This type of a view is immensely helpful in determining what has changed in a component over time, what solutions were used in response to a particular  critique of the component, and it also gives a comparison between the different annotations. In a merged view color coding is used for display – parts of the annotation that are common between the different versions are displayed in a particular color, and distinct parts are displayed in an another color. 

•	Audio Collaboration and Voice Messaging
The Remote Collaboration System provides for collaboration through audio – the different collaborators speak to each other over the network. The voice data transmission and reception is handled by the Remote Collaboration System. The current speaker is identified and his username is displayed on the user interface by the system.

•	Recording and Storing Audio Discussions
The conversations taking place during an audio collaboration session can be stored to persistent storage. This allows archival and future retrieval of important discussions. All audio discussions are stored with a time stamp of when the discussion took place, and the project group that authored the discussion. This mechanism for storing audio discussions turns out to be an enabling technology for users who are connected to the system on a low-bandwidth connection or who are in a different time zone.  Even though this class of users may not be able to take part in a real-time audio discussion, they can download stored audio discussions and make up for this loss in user-experience. 

•	Accessing Text Transcripts of Audio Discussions
For users disadvantaged by a low bandwidth connection, the Remote Collaboration System provides the option of accessing text transcripts of audio discussions – this gives low bandwidth users near real-time collaboration capability with high-bandwidth users in an audio collaboration session. A standard commercial speech recognition library is used for this purpose. The added cost of licensing this piece of software is offset by the enormous enhancement to the types and number of users who can benefit from using the system. 

•	Graphical Collaboration through the Whiteboard
The Remote Collaboration System includes a whiteboard for communication via diagrams, images and text, i.e. hybrid content. The users can draw on the whiteboard using a palette of tools provided to it. The graphical data on the white board is represented in structured format using XML, and broadcast to all clients. There  a number of specific ways a user can interact with the whiteboard. These interactions are listed below. 

•	Drawing a Graphical Object 
As mentioned above, a user can draw onto the whiteboard canvas using the tools provided on the client UI. The effects of drawing on the a user’s local whiteboard is broadcasted to all the users who belong to a particular project group. 

•	Editing a Graphics Object
A graphics object on the whiteboard can be edited by a user, with the changes due to the edit being reflected on all the clients and also on the object store on the serve. The issue of contention and data inconsistency due to multiple users trying to edit the same graphics object necessitates locking of the object being edited by the user that is doing the object manipulation. This issue is discussed in the Critical Issues section of this architecture document. 

•	Deleting a Graphics Object
A user can delete a graphics object from the system. Not only is the object on his local machine deleted, but the copy of the object stored on the server, and the copy on all other client machines is also deleted. 

•	Creating a Composite Graphics Object
It is possible to save a collection of graphics objects collectively as one graphics object – a composite object made up of many smaller objects. The UI on the client provides a “rubber band” selection tool that enables a user to select multiple objects and convert it into a composite object. This custom object is then stored under a user-defined name in the central object store and is available to be used by other clients and is also available for future use. 

•	Viewing all Graphics Objects Available on the Server
The user at anytime is allowed to see a list of all the graphics objects available on the server. He can then select an object to include it in his drawing on the whiteboard, can delete it, or perform other manipulations on it. There is only a single copy of any object on the server. The system as a whole may however contain more than one copy due to the caching mechanism employed by clients. 

•	Saving a Snapshot of the Whiteboard
The entire contents of the whiteboard at any instant can be assigned to permanent storage in the Remote Collaboration Server. A large composite object is created which contains the contents of the whiteboard and a timestamp to indicate the time of saving. A snapshot of the whiteboard helps in recollection or verification of previous collaboration sessions in the Remote Collaboration System. 

•	Viewing the previous few Screens of the Whiteboard
The Remote Collaboration System clients use a caching policy, whereby the previous 5 slides are stored in the cache. It is human nature to want to go back and refer to something we have just seen. Since it is expensive in terms of latency to fetch items from across the network, the most recent 5 slides are cached in the local disk of the client – any request to view these screens is served from this disk rather than the central repository. Since this is previous content, there are no cache coherency problems here – it is not possible for some other writer to change whiteboard snapshots from the past!

•	Viewing Complex Documents (stored on the Server) in the MultiViewer
The Whiteboard of the Remote Collaboration System can also be as a viewer of complex documents. The documents need only be stored on the central server, but all the users of the system can view them, making a collaboration session infinitely more fruitful. Standard documents formats such as Word documents and Visio diagrams are supported by this MultiViewer. The functionality to display these standard documents can be obtained from the standard COM interfaces exposed by the commercial applications that support  the above document formats. 

Remote Collaboration System Context Diagram:

The context diagram below represents how our Remote Collaboration System processes (as a whole) react with the external environment.

•	The figure shows the interaction between the  client and the server. It must be kept in mind that the actual communication is between client and client via the server.
 
•	The client and server individually transact with sources and sinks of information and also ultimately interact with each other through the communication conduit established by .Net Remoting.

•	The client inputs commands and data (Annotation, Chat, Whiteboard data and commands) through the GUI. The results of any processing that the client receives (e.g. chat messages or whiteboard views) or any status information are also displayed on the client GUI.

•	In addition to starting and stopping the server the GUI on the server side provides the administrator a means of configuring various parameters in the Remote Collaboration System. It displays the status of connection with clients and a list of the clients currently connected. 

•	As shown in the context diagram, both the server and the client generate error messages as and when necessary and respond to error conditions with suitable error handlers. 

•	File operations are required by both the client and the server. It utilizes the services exposed by the file system to complete these operations. 

•	The communication between the client and the server is achieved through the channel set up by the .Net Remoting service. The server and client communicate with the proxy of our remotable class being marshaled by reference. Information is passed between the 2 ends of the communication link via parameters in remote function invocations. 

Module Diagrams

Client Module Diagram:

The module diagram for the client in the Component Server is given on the next page, and displays the modules the client can be partitioned into:

ClientUI
•	The ClientUI module is the user interface module for the remote collaboration client. It contains all the user controls through which a user can interact with the Collaboration Server. It has the responsibility of reacting to all the events generated in the system by these controls.
•	A major responsibility of the ClientUI module is area management of the user interface on the client and updating the displays contained therein. ClientUI enlists the services of the Display module to perform the above function. 
•	ClientUI serves as the executive module of the client application and oversees the working of all the helper modules in the application. Depending upon what is requested by the user it calls upon the services of other modules.

ClientMessaging
•	The architecture of Remote Collaboration System defines the entire communication between the client and the server to be via XML formatted messages. The ClientMessaging module is the module that is responsible for generating and interpreting (on client side) the messages being passed in the system. Therefore any information originating from user to the server, whether command or data, has to be first encapsulated in a valid message. The format of any message frame consists of a header, body and trailer. This structure of frames significantly simplifies decoding these messages on the receiver. 
•	This module uses the services provided by the ClientXMLCodec module in order to generate and interpret the messages in the system.

ClientXMLCodec
•	This module is responsible for encapsulating commands from the client side into well-formed XML messages that can be passed over the communication conduit to the server. The header, body

and trailer requirements for a message frame correspond to XML tags, which are inserted by this module.

•	This module also creates an XML representation of the graphics objects that are exchanged between the client and the server in the whiteboard subsystem. The attributes of the graphics objects are all encapsulated in a structured XML descriptor. This description contains all the information required for a remote machine  to draw the object on its local display. 
•	ClientXMLCodec provides XML decoding services to the ClientMessaging module to interpret XML responses it receives from the server. It is capable of extracting data such as files or commands or notifications that are received by the client. 

ClientComm
•	The ClientComm module handles the communication between the client and the server. It is responsible for the channel initializations and registrations and remote object activations that are required to be done by the client. It is also responsible for making the appropriate function calls in order to send data to the server. Thus this module provides communication services that can be used by the other modules in the application, and they need not be aware of the low-level details of establishing or managing connections. 

File Handler
•	The File Handler module is used for file operations. It is responsible for opening files and reading from them, and storing newly created files onto disk. The WhiteBoard, Annotation, Voice Messaging, Component Server, Client Messaging and Client XMLCodec modules all use the services provided by this module. 

Annotation
•	Annotation is required in the Remote Collaboration System in two forms. First, collaborators need to be able to write comments about the graphics objects being displayed on the whiteboard. This functionality is provided by a text tool on the whiteboard palette. Second, users need to be able to enter comments about components and code files. The Annotation module assumes the responsibility for this functionality.
•	The comments are not directly added to the component file itself, but to a separate file. The Annotation interacts with the Component Server module as this provides it services such as versioning. The module uses the services of the File Handler. 

Security
•	Security is one of the central concerns in a remote collaboration system. Data has to be protected from eavesdroppers external to the system. Similarly one team may want their discussions and data inaccessible to other team. The Security Module provides data confidentiality and integrity as well as user authentication and authorization. A detailed discussion of the security concerns of this system, its security policy and implementation appears in the Critical Issues section of this document.

Chat
•	The chat module is the module that enables users to collaborate by sending text messages. It uses the services of the Client Messaging module to generate XML encapsulations and decode these encapsulations of messages exchanged between the collaborators. It uses the services of the Display module in order to display these messages on the screen. 
 
WhiteBoard and Graphics Object Management
•	This module contains the functionality to implement WhiteBoard activities. It interacts with the Graphics Object Management module to transact with the object store on the server. This module also enables saving and retrieving of local objects. The WhiteBoard module uses the services of Client Messaging, Graphics Object Management and the Display modules to interpret object XML descriptors and display them on the UI. 

Display
•	This module contains the display functionality of the client side collaboration system. It has the responsibility of displaying the various chat messages received (and generated) by the system. The Display also module handles the job of rendering the various graphics object onto the whiteboard area on the screen. 

Voice Messaging
•	Voice messaging is responsible for transmitting voice signals from one client to the other. To minimize bandwidth requirements, this transfer of information is done by splitting the voice information into optimal size packets. This has to be done by taking playback time of audio into account so that subsequent packets arrive before the playback of the earlier packet is over. Playback of received audio packets is also the responsibility of this module. 

Component Server (Client)
•	This module is the client-side part of the Component Server. 
•	The Component Server contains the functionality to store components at central locations and serve them to the collaborators of this system. It also supports uploading and viewing of components, while all the time maintaining a versioning policy. 
•	It interacts with the Annotation module in order to facilitate annotating of components. 

Server Module Diagram:

The server in the Remote Collaboration System is composed of the following modules. The diagram is as attached on the next page.

Server
•	The Server module is the executive module on the server side. It oversees the working of all the modules on the server. Though the server is not designed to have a lot of user interaction the architecture defines a minimalist GUI for administration management procedures. The display is intended to provide the list of all the clients connected, the status of the client, etc. The Server module takes care of updating the display components of this interface. 

Message Handler 
•	This module can be looked upon as a generic message handler — it handles the various messages coming from the client-side. 
•	A chat message coming from a client is broadcast to all clients (or rather multicast to only those clients who belong to a particular project team).
•	A voice message is again simply multicast (with the exception of dial-up users).
•	An annotation message results in the message handler forwarding it to the component server for versioning and other related activities. 
•	The Message Handler uses the services provided by the SrvXMLCodec and SrvFileHandler modules. 

Server Graphics Object Management
•	This module is responsible for maintaining the object store on the server. Any whiteboard transaction taking place between collaborators takes place through this module. 
•	It saves all objects generated on the system, so that they can be multicast to the interested clients. It also assigns to persistent storage whiteboard snapshots and composite objects, as desired by the collaborators. 
•	This module also searches persistent storage for and serves up objects requested by the clients. 

Session Management
•	This is the module that establishes and maintains client sessions and also handles dismantling sessions. 
•	This module maintains the data structures necessary to manage the client sessions. For every project on the system the Session Management module maintains a separate receive Queue. It also maintains multicast groups – every project has a data structure with a list of all the client IP addresses and their corresponding remote objects. This is to facilitate easy multicast of messages to all interested clients. 
•	In case a client disconnects from the Remote Collaboration System, it is the responsibility of the Session Management module to delete the entry in the session management data structures corresponding to that particular client. 
•	This module also maintains a list of all the invitations to collaboration sessions a particular user has received since his last login. 

SrvComm
•	The SrvComm is the module on the server side that handles the communication between the client and the server. It is responsible for the channel initializations and registrations required to be done by the server. It is also responsible for making the appropriate function calls in order to multicast data to interested clients. Thus this module provides communication services that can be used by other server modules, and they need not be aware of the low-level details of establishing or managing connections. 

Component Server (Server)
•	This is the server-side part of the Component Server.
•	This module stores all the components in the server and implements its versioning policy. A detailed architectural discussion appears in Project #3. 

SrvXMLCodec
•	The SrvXMLCodec module performs an analogous role to the ClientXMLCodec  module on the client side. 
•	It is responsible for encapsulating commands from the server side into well-formed XML messages that can be passed over the communication conduit to the client. It inserts the appropriate XML tags in the message, which correspond to the headers, body and trailer identifiers.
•	SrvXMLCodec provides XML decoding services to interpret the XML requests/messages it receives from the client. It is capable of extracting command or status messages and also object attributes from XML messages it receives from the client. 

SrvFileHandler
•	The SrvFileHandler module is used for file operations by the server. It is responsible for opening files and reading from them, and storing newly created files onto disk. The SrvXMLCodec module uses the services of this module.

Security
•	This module provides server-side services for maintaining security in the Remote Collaboration System. The system will provide access to its resources to only those clients who have the necessary privilege level. All other clients are refused a session on the Remote Collaboration System. The infrastructure for providing server-side support for authorization, integrity and also client non-repudiation (so that a user cannot deny that he was the author of a particular content/message) is provided by this module. 

Client – Server Communication

The communication architecture between the client and the server has a direct bearing on the overall efficacy of collaboration the system. 

The client and the server communicate with each other through a communication channel set-up by .NET Remoting. In the Collaboration System, the server relays information sent by one client to all the clients in the system (i.e. all clients belonging to a particular project team, since our system can support separate collaboration session simultaneously). This broadcasting of information, often from a central object store, necessitates that the server repository must be able to save state between its connections with all clients. As a result the activation mode for the server object store is chosen as Singleton, which creates one object instance to service all requests. However it is useful to have multiple threads handle the connection with each client, so a single call object is used to handle client requests.

The system proposes to buffer any exchange of information over the remote channel with the help of queues. The queues buffer out irregular or bursty generation of messages and hence ensure that no information is lost when the other side is busy doing something else. This decoupling of client and server makes for very reliable communication. Each of the queues is managed by separate dedicated threads. Separate queues are proposed -- one for whiteboard data, and another for chat messages and system notifications, so that very large whiteboard data objects do not hamper timely delivery of urgent notifications from client to server (e.g. a disconnect notification). 
	
As stated earlier, the Collaboration System will in all likeliness be used by different teams of professionals belonging to different projects. To support such concurrent operation, the Server will have a separate ‘receive queue’ for each project group, which will be created on the fly as when new project sessions are created. Also every client will have a send and a receive queue. All messages that originating from the client side will include a “project id” to simplify session management. 

While most of the users of the System will be connected through an Intranet LAN or a WAN, the system also supports dial-up connections. Most firewalls by default block traffic through all ports except the standard HTTP port 80 and the ports associated with FTP (20 – data and 21 control). Since Remoting would be operating over other ports the setup of the communication channel requires that the Firewalls on both sides is specifically configured to allow communication over the port of operation. The security issues raised by this are discussed in the Critical Issues section of this architecture document. 

Data Structures for Communication:

The server maintains a hashtable of all the projects active in the system and the corresponding receive queues used to store messages originating from members of that project group. This design prevents complications due to different projects’ messages from interfering with each other. 

ProjectID	ReceiveQueue	

The server also maintains a list of all the clients subscribed to a project so that it knows which clients to broadcast information. A client is identified by his IP address, and each IP address has the corresponding remote object, through which the server can send information to the client. This hashtable of IP address and Remote Object is another data structure in the system. 

Client IP	Remote Object (PBRO)	

Message Format:

In the whiteboard Messages are sent in XML. Each message includes the Project ID of the project on which the client is collaborating and the IP address of the client. E.g. A line can is represented by the following XML message:

E.g. Here is a simple XML message passed from the client to the server to describe a line that is drawn on the whiteboard. Only one set of co-ordinates are given – the co-ordinates of the point we will move to, from the current point.

<whiteboard>
<projID>0024COLL74</projID>
<clientIP>128.230.208.84</clientIP>
<line>
	<x>350</x>
<y>225</y>
</line>
</whiteboard>

Activity Diagrams

The following sections list the major activities taking place in the major subsystems of the client and the server. 

Client Whiteboard Activities

The client activity diagram represents the high-level activities in the client and documents the related program flow. It is shown on the next page and describes the initializing activities on the whiteboard client.

•	On startup the Whiteboard Client initializes the logical conduit for communication between itself and the server. 
•	It displays the User Interface and waits for user input. 

The main client-side activities are explained below, and appear in the diagram on the next page. 

•	LOGIN
o	The user is prompted to enter his username and the name of the Project/Group he is affiliated to. 
o	Authentication procedures verify his identity. If authentication is successful, the client is granted access to the system.
o	On logging in the client asks the server for a list of “meeting invitations” he has received.
o	For every authorized user the server maintains a list of invitations to meetings he has received when he was not logged onto the system. This is the list that the server responds with on request. 
o	The client decodes the server response and displays the list of invitations. It also indicates which session is active, so that the user can join a collaboration session if he so wishes. 

•	DRAW
o	This constitutes the activity of drawing on the whiteboard. 
o	The client determines the type of object from the selection made on the drawing palette.
o	It calculates the location of the object, by calculating the co-ordinates of the object from the origin of the whiteboard. The location with the origin is calculated relative to a reference point on the drawing object that varies with the type of object. E.g. for a circle it is the radius, while for a square it is the upper left corner.
o	The size of the object is determined by calculating a scaling factor with reference to the default unit size of the object. This enables redrawing the object on other client machines. 
o	A unique ID is then assigned to this object. (At regular intervals the server gives the client a block of Object IDs it can use. This ensures that no 2 clients assign the same object ID to different objects.) 

o	An XML representation of the object is then created which the stores all of the above information.
o	This object representation is then encapsulated in a standard message format and sent across the communication channel to the server.

•	MOVE
o	This constitutes the activity of moving an object on the whiteboard. 
o	The client first determines the current active object and its ID.
o	The client then determines the new location  of the object and modifies the XML descriptor of the object to reflect this change, i.e. it updates the “location” tag in the descriptor. 
o	The new XML descriptor of the object is encapsulated in a message and sent across to the server. 

•	DELETE
o	This constitutes the deletion of an object from the whiteboard. 
o	The object is removed from the local whiteboard display.
o	The client determines the object ID of the current active object. 
o	An XML “delete notification” message including the object ID is constructed, to inform the server to delete the object from the object store. 

•	EDIT
o	This constitutes editing of an object on the whiteboard. 
o	The client first determines the current active object and its ID.
o	All the attributes of the object are then recalculated after the editing operation. 
o	The XML descriptor of the object is rewritten.
o	The object descriptor is then encapsulated in a message and is sent to the server. 

•	COMPOSITE CREATION
o	This constitutes the creation of a composite object.
o	The objects included in the composite object are those selected by the user by means of a “rubber band” selection tool. 
o	An array-like data structure is created that stores all the objects IDs included in the selection tool and their respective attributes. 
o	A unique object ID is assigned to this composite object.
o	The user is asked for a name to save the object under. 
o	An XML descriptor is then created for this composite object.
o	The new object descriptor is sent across to the server to be stored in the object store.

•	SERVER INITIATED UPDATE
o	This constitutes updating the display on the local whiteboard, after the client has received a notification from the server.
o	The client has a separate thread that waits (in an efficient wait state) for notifications from the server.
o	On receiving a notification message (in XML), the client decodes the message and updates its local display with the graphics objects encapsulated in the server notification. The object descriptor contains all the information required for drawing on the display. 

•	SAVE SNAPSHOT
o	The whiteboard provides the capability to save the contents of the entire whiteboard to persistent storage. 
o	This activity is similar to composite object creation. An array-like data structure is created that stores all the objects IDs and their respective attributes. 
o	A unique object ID is assigned to this composite object.
o	An XML descriptor is then created for this composite object, which includes a timestamp that indicates when the snapshot was taken, and a project ID tag that denotes the author of the contents of the whiteboard. 
o	The user is then asked for a file name under which the snapshot is saved. 
o	The above step is followed if only a local save is required. If a global save of the snapshot is required, the client sends a Send Snapshot request to the server.

•	REQUEST IDs
o	This is not a user-initiated activity. (The client assigns a unique ID to every object that it creates on the whiteboard. To ensure uniqueness of IDs between different clients the server generates a certain number of unique IDs and sends them to different clients via regular updates).
o	The client sends the server a RequestIDs message when it is about to exhaust its store of unique IDs. 
o	On receiving the server response, it decodes the XML and replenishes its stock of IDs. 

Server Whiteboard Activities

The main server whiteboard activities are explained below, and are shown on the next page. 

•	LOGIN REQUEST
o	This activity constitutes servicing a Login request from the client. The client login information is verified and the client is authenticated. 
o	If the authentication fails, an error message is generated and the client is informed of the status of the login, and is advised to try logging in again.
o	If the authentication is successful, the server forwards client information to the session management in order to add him in the various session management data structures.
o	The server looks at its list of meeting invitations for this particular client and sends the list back to the client. 
o	The server is now ready to accept further requests corresponding to client side activities. 

•	DRAW REQUEST
o	This is activity constitutes servicing of a Draw Request originating from the Whiteboard client. 
o	On receiving this request the server extracts the XML object descriptor from the request.

o	The server extracts the object descriptor from the message and updates its object store. 
o	The server determines the originating project team and looks up the session management data structures to determine which other clients belong to the same team.
o	The XML descriptor is encapsulated in a “Server Initiated Update” message and broadcast to all the clients in the same project team. 

•	MOVE REQUEST
o	This is activity constitutes servicing of a Move Request originating from the Whiteboard client. 
o	On receiving this request the server extracts the XML object descriptor from the request.
o	The server extracts the object descriptor from the message and updates its object store. 
o	The server determines the originating project team and looks up the session management data structures to determine which other clients belong to the same team.
o	The XML descriptor is encapsulated in a “Server Initiated Update” message to reflect the new location of the object.
o	This message is broadcast to all the clients in the same project team.

•	DELETE REQUEST
o	This is activity constitutes servicing of a Delete Request originating from the Whiteboard client. 
o	On receiving this request the server extracts the XML object descriptor from the request.
o	The server then extracts the name of the component to be deleted from the delete message.
o	The server deletes the named object from the object store.
o	It generates  a “Server Initiated Update” message to instruct all clients of the deletion of the object. 
o	The server determines the originating project team and looks up the session management data structures to determine which other clients belong to the same team.
o	This message is broadcast to all the clients in the same project team.

•	EDIT REQUEST
o	This is activity constitutes servicing of an Edit Request originating from the Whiteboard client. 
o	On receiving this request the server extracts the XML object descriptor from the request and the name of the object.
o	The server then saves the edited object under its original name, effecting a change of the object in the object store. 
o	The server determines the originating project team and looks up the session management data structures to determine which other clients belong to the same team.
o	The XML descriptor of the newly edited object is encapsulated in a “Server Initiated Update” message to inform all clients to update their displays with the new object.
o	This message is broadcast to all the clients in the same project team.

•	SERVER INITIATED UPDATE
o	This activity constitutes the generation of a Server Initiated Update message. This message is created to inform the client of the Whiteboard of any changes that need to be effected in their Whiteboard displays.
o	The server generates the a new XML object descriptor or includes other information to instruct the client on what steps it needs to take to perform the updating.
o	This information is encapsulated in an XML message. 
o	The message is broadcast to all the clients belonging to a particular project group. 

•	SAVE SNAPSHOT
o	This server activity is analogous to the Save Snapshot activity on the Whiteboard Client. 
o	The whiteboard provides the capability to save the contents of the entire whiteboard to persistent storage. 
o	An XML descriptor is created for the entire whiteboard, with the contents being treated as one large composite object.
o	A time stamp, the project ID are stored along with the object information. 
o	The snapshot is then saved on the server and is available for future retrieval. 

•	SERVICING REQUEST IDs
o	On receiving this request the server generates another batch of unique IDs that can be assigned to objects.
o	It formats an XML response embedded with the batch of IDs just generated. 
o	This message is then sent to the originator of the Request ID message. 

Chat Subsystem Activities

The diagrams that follow represents the high level activities in the chat subsystem.

Client Side Activities

•	LOAD USER LIST
o	This is an initialization activity performed by the chat client on startup. 
o	It sends an XML formatted “Load Request” message to the server, asking it for a list of users that are currently active in the project chat room.
o	It waits for a response from the server.
o	On obtaining the server response it displays the list of active users on the user interface. 

•	SEND MESSAGE
o	Send Message constitutes a user sending a public message to the chat room, that is meant to be viewed by all the members of the room.
o	The message entered by the user on the appropriate input window is formatted into an XML message, which includes the “chat” tag to inform the server that it is a chat message. 

o	This XML message is then sent to the server by the client.

•	SEND PRIVATE MESSAGE
o	This activity constitutes one collaborator sending another collaborator a private message – one that is not visible to the other users of the system. 
o	The user name of the collaborator to whom the private message is intended for is obtained from the user. 
o	The message entered by the user and the destination user name are together encapsulated in an XML formatted chat message.
o	This message is then sent across the communication conduit to the server. 

Server Side Activities (Diagram on next page)

•	SEND USER LIST
o	This is an initializing activity done by the server, every time a new user logs onto the system.
o	On receiving the “Load Request” message from the client, the server looks up the session management data structures maintained on the server.
o	It obtains a list of all the users present in the chat room, and formats this information in an XML message.
o	This message is then sent to the client that requested the response.

•	RECEIVE MESSAGE
o	The server extracts the chat message from the XML encapsulation. 
o	The server next broadcasts (multicasts) this message to all the clients subscribed to that particular project team chat room. It obtains the list of users to broadcast the message from the data structure maintained by the session management module in the server. 

•	RECEIVE PRIVATE MESSAGE
o	The server extracts the chat message from the XML encapsulation. 
o	It also extracts the user name for whom the message is intended.
o	The server next sends (unicasts) this message to the intended recipient. 

Annotation Subsystem Activities

The activities in the annotation subsystem include the following:

Client Annotation Activities (Diagram on next page)

The client side annotation activities are shown below:

•	CREATE ANNOTATION
o	As a first step in annotation creation process, the client gets a list of all the available components on the server and displays it to the user. 
o	The user then selects a component to annotate. This selection results in the component being opened in a View window, where the user can go through the code/component details. 
o	After the client has entered his comments in the window provided, the client extracts this comment from the window.
o	It creates an XML formatted message containing the annotation.
o	The XML message also includes the author of the comment.
o	This XML message is then sent to the server for annotation file creation/versioning.

•	EDIT ANNOTATION
o	The client displays a list of all the components available after getting the latest information from the server. 
o	The user then selects a component of interest.
o	The latest version of the associated annotation file is then downloaded from the server and displayed to the user. The user can then edit/modify the contents of this annotation file.

o	The new annotation is then formatted into an XML message which includes the name of the author of the modified annotation.
o	This XML message is then sent to the server for persistent storage and versioning.

•	MERGE VIEW
o	This activity constitutes the viewing of multiple annotation files in a merged fashion, i.e. multiple versions of the annotation for the same component is displayed together – this helps us determine how the component and the annotations have changed/evolved over time.
o	The client displays a list of components available after downloading the latest list from the server.
o	The user then selects a component of interest.
o	The client displays all the versions of annotation associated with the component of interest. 
o	The user is then prompted to choose which versions he would like to merge in a single view
o	The annotations from the different versions are loaded and a text comparison is performed between them.
o	The results of the merge are displayed in a window, with color coding used for the text to distinguish between what is common between the different versions and what is different. 

The Server Side annotation activities are as mentioned below (Diagram on next page):

•	CREATE ANNOTATION REQUEST
o	This activity constitutes the servicing of a Create Annotation message from a client.
o	On receiving a request, the server decodes the request and extracts the component name, the author and the annotation itself. 
o	It creates a new annotation file (version 1) associated with the component and stores the information extracted from the request message into the file. 
o	It also inserts a time stamp into the annotation file to indicate when the annotation was updated. 

•	EDIT ANNOTATION REQUEST
o	This constitutes the servicing of an Edit Annotation Request
o	On receiving the above request the server decodes the request to extract the component name and the version of the annotation being edited. 
o	It creates a new version of the annotation file for the component of interest and stores into the object store. 
o	It includes the author of the edited annotation and a timestamp into the edited annotation file.

•	MERGE VIEW REQUEST
o	Merge View request originating from the client are serviced through this activity. 
o	The server extracts the names of the annotation files to be merged from the request sent by the client. 
o	The server then serves up the required annotation files and transmits them over the communication link to the client. 

Security in the Remote Collaboration System

The Remote Collaboration System operates over a network. As a result a large number of users have access to the system. This makes security of paramount concern in our system.  The system deals with software components, code reviews, discussions of algorithms and business strategies on the whiteboard, etc – all intellectual property or classified information whose privacy is vital for the survival of any organization.

This architecture proposes to adopt a security policy that implements authentication, authorization, confidentiality, integrity and non-repudiation. These are considered the pillars of security and their inclusion into the system is discussed below:

•	Authentication:
This is equivalent to asking the user: Who are you? Authentication is the first line of defense the Remote Collaboration System has against malicious activity on the system. Authorization ensures that only users trusted by the systems can gain access to it and use its resources. 

A simple username password authentication scheme is not sufficient to maintain security. This architecture proposes the use of digital certificates (the OSI standard X.509) as a means of implementing authorization. All users of have their digital certificates registered with the Server. Their certificates are signed by a trusted Certificate Authority such as VeriSign. This assures the Server that the user is actually who he claims to be. 

His identity is verified with a list of registered users maintained by the server. If his name is present in the list of users, his connection request is accepted and he is granted access to the system. Else a message informing the client that his authentication failed is issued and his connection is refused. 

Even though digital certificates assert that the individual just authenticated is who he claims to be, it does not assert whether or not he is supposed to access the system. This is the responsibility of the server and its authorization implementation.

•	Authorization:

After we have determined who the user is, we resolve the question, what is he supposed to see. The server maintains a database of user roles and privileges. Every authenticated user has to work with the confines of this “authorization periphery”

For e.g. a project manager or team leader may have almost full access to the system, except that they cannot alter this authorization database itself. The administrator enjoys this privilege exclusively. Similarly customers and business clients of our system can only “view” but cannot edit/modify.

This role management is an important part of the security subsystem and enforces our authorization policy. 

•	Confidentiality:

The remote server has little control over the exact network infrastructure at different client location, especially if the client is located in the other part of the world. This raises the question of data confidentiality/secrecy. What if the network cables are not secure? What if the network is a broadcast network, vulnerable to IP spoofing or man-in-the middle attacks. These concerns necessitate the presence of robust encryption schemes to guarantee the secrecy of the information being exchanged in the system.

PGP (Pretty Good Privacy) is a widely popular open source solution to confidentiality. It exploits the advantages of both symmetric and asymmetric (RSA) algorithms. This  architecture proposes to use PGP to encrypt any data that is going from the client to the server. The server is relieved of the burden on encryption – in our system all the server does is relay the information to other clients, and is not concerned with the contents of the information. For other messages server is provided decryption capability. 

Confidentiality ensures that even if an unauthorized individual gets access to information from our system, they will not be able to make sense of it in the absence of suitable decryption keys. 
•	Integrity

Data Integrity is needed to assure us that the client who sent us the chat message or whiteboard object or annotation, in fact generated the message himself, and the contents of the message were not modified during transit – a man-in-the-middle attack. 

Message Digests are use to provide data integrity. They are analogous to a robust checksum, and any modifications to the data in transit will be detected by the server which verifies the checksum to determine data integrity. 

PGP includes an implementation of SHA (Secure Hash Algorithm) to provide data integrity.

•	Non-repudiation:

In a collaboration system of this scale, it is important to be able to retain proof pertaining to what a client did or said in the collaboration session. This could be vital during a client business meeting, for instance, where an exposition of system requirements is being given by the client. We should be able to verify what the client said in the future and also retain evidence of the same, to be presented in a court of law, if need be.

Non-repudiation ensures that a client cannot deny what he said. Non-repudiation can be implemented by storing the digital signature of the client that generated the message along with the encrypted / signed copy of the message.  This is not only beneficial for the server (as it can be sure that the a particular client was the author of a certain chat message, say) but it is also beneficial to the client, as non-repudiation also provides proof that says the client generated chat message A only, and not message B. 

Voice Messaging 

The Voice Messaging Subsystem enables users to communicate through audio messages in the Remote Collaboration System.  

Voice messaging is included as an enhanced feature of the Collaboration System, and is not essential for satisfactory user experience on the system. This is because users of varying bandwidth connections are expected to connect for collaborations. It is not possible to carry real-time voice communication over dial-up lines, in  addition to support for the whiteboard, chat annotation and component server.

The Voice Messaging feature works in the following manner:

•	A user who wants to send a voice message speaks into the microphone and audio signal generated is converted into digital sound information, with coarse sampling used. 

•	Coarse sampling can be safely used to obtain a smaller file size, since the range of frequencies in the human voice is much smaller than the entire audio range. This makes communication simpler and faster. 

•	The WAV file format is used for representing voice information. We chose an uncompressed format over an uncompressed format like MP3 because the audio messaging is to be done in real-time. Even though the bandwidth requirements of compressed audio is much lesser than WAV, the overhead of MP3 compression and decompression is too large for real-time audio communication. 

•	The audio stream is then split into packets and sent to the server. The size of the packets needs to be optimal to insure uninterrupted playback at the receiver and minimum bandwidth requirement at the sender.

•	The server, on receiving packets, simply broadcasts those packets to all interested users. The users playback the audio information received.

•	At any given time the current speaker in a voice conversation is displayed by the server on the client’s UI. 

•	The Voice Messaging subsystem allows us to save an ongoing conversation for future retrieval. These saved audio sessions can be sent top low-bandwidth users on a delayed transmission scheme, so that they can benefit from a voice discussion in spite of not having the bandwidth to support real-time audio.

•	Alternatives to Voice Messaging, such as using telephone calls to establish audio communication and text transcripts of audio have been discussed in the Critical Issues section of this architecture document. 

Critical Issues
	
	Critical Issue I

•	Loading Analysis

The loading analysis of the server in the Remote Collaboration System is a crucial part in the design of the architecture of this system. The analysis of queues in the system (whether created explicitly by the programmer, or the queues inherent to the system, such as those situated in the lower layers of the network infrastructure) helps us decide whether our system can handle the load incident on it. The load denoted by ‘’ is the ratio of the arrival rate of messages () in a system to the service rate of those messages (). 

If one plots the average length of a queue versus the load, we obtain the following graph [from class notes]:

From this plot it is evident, as our load factor crosses the value of 0.5, we approach a threshold after which there is a steep rise in the number of items queued. Long queues affect system performance adversely by seriously degrading user experience on the system (due to very large latency). Moreover, as the length of the queue is allowed to grow exponentially, a possibility arises that a number of messages will exceed the maximum capacity of the queue and will be discarded. To prevent these two occurrences, one must always ensure that the queue length of the system is not allowed to grow to a large value (in the steady state condition).

We decide 0.25 as the maximum permissible loading factor, keeping some safety margin to threshold of 0.5. 

The graph on the next page depicts the expected loading patterns of the server. Employees are expected to be at the peak of collaborations at 9:00 after their morning cup of coffee. Collaborations again increase after lunch and a little before closing of office hours. Low-bandwidth users are expected to download sessions during non-peak hours e.g. during the night, hence the peak at 2:00 am. This also assumes collaborators in a different time zone are transacting with the server at 2:00 am. (This model does not take into account the nocturnal instincts of software developers!)

To calculate loading rho, we need to calculate the service rate (mu) and the arrival rate (lamda). The following sections deal with the measuring of these 2 parameters.

Approximating Arrival Rate:

A fairly accurate approximation of the arrival rate can be made by studying the typical behavior of the users of the Remote Collaboration System. This gives us the “usage model”, which should be extended to a “load model” in order to determine the maximum load servicing that our system is capable of. 

The source of load on the server could be from the chat subsystem, the whiteboard, the annotation, the voice messaging or the component server subsystem. 

Chat:
The chat subsystem is typically used to send short messages between the different collaborators in the system. Messages are not expected to be more than a paragraph long at the most (around 55 words i.e. around 300 bytes). Even after considering a large number of users, one does not expect to have more load than a 55 word message per second in the chat system. The arrival rate is therefore 300 bytes per second. 

Thus, Arrivalchat = 1 message (300 bytes) per second

Annotation:
The annotation facility allows us to embed comments in a component file. Each annotation would typically not be more than a page of text, i.e. about 350 words (2000 bytes). Annotation is not expected to be a very frequent event. The frequency could be approximated to one  every 30 minutes. 

Thus, Arrivalannotation = 1 message (2000 bytes) per second.

Whiteboard:
The Whiteboard promises to be one of the most active generators of requests in the system. Here the amount of information exchanged is generally larger than other request messages. The whiteboard is considered to be composed of several graphics objects, with each graphic object encapsulated in a XML structure that makes decoding them easier. A few examples of the object description scheme that this architecture uses is given below. E.g. a message containing a line descriptor is as follows:

<whiteboard>
<projID>0024COLL74</projID>
<clientIP>128.230.208.84</clientIP>
...

<line>
	<x>350</x>
<y>225</y>
</line>
...

</whiteboard>

and a circle would be represented by the following (excluding the message header and trailer tag overhead). 

<circle>
	<x>300</x>
<y>205</y>
<radius>5<radius>
</circle>

Thus from the above graphic element structures it can be seen that a graphic object takes approximately 35 to 55 bytes for representation.  An entire whiteboard diagram could be composed of several of these small units. For e.g. if we take the module diagram of this architecture report, it would need a total of 32 line objects to be represented on the whiteboard -– 32*35 = 1120 bytes.

The entire whiteboard is transmitted only once about an hour, with smaller updates/additions/deletions to the whiteboard occurring much more frequently. 

Thus, 
Arrivalwhiteboard = 1 message (1120 bytes) per hour and for smaller updates the arrival rate is much higher – 
Arrivalwhiteboard = 1 message (480 bytes) per second. 

A person drawing on a whiteboard can draw at irregular speeds, sometime generating as many as 10 strokes (each say 75 bytes with overhead) per second. Our server should be able to handle all these variable Arrival rates.  

Voice Message:
Voice message would be generated approximately every minute, with each message lasting for about 25 seconds. A quantitative analysis of voice messaging load could not be carried out due to time constraints, but the detailed steps to be carried out for this analysis are given at the end of this section. 

Measuring Service Rate:

The service rate is indicative of how fast the server can process messages. We intend to measure service rate using a prototype that performs similar processing of a message. The concept of the Component Server we developed in Project #4 can be extended to a generic object store. This object store can store modules and files, or can be used to store graphics objects – as required by our Whiteboard.  

There are several areas of processing for which we will measure the service time:

1.	Decoding XML requests received from the client and then transmitting data (e.g. the time required to decode a file request and then transfer the data)

2.	Inserting an object in the object store – that is saving the XML descriptor in the centralized store in the server. (This is uploading , which was found to be of almost the same service time as item no. 1 above)

3.	Scanning through the XML descriptor of a graphics object to extract information from it, so that it can be redrawn on another collaborator’s machine. This processing can be thought of as being similar to the scanning of a manifest file to determine all the components associated with a particular manifest in Project # 4.

4.	Saving of an object or a stroke would need XML to be written in the proper format for object representation. This is similar to the server creating a manifest or descriptor for an object or generating XML encoded responses with component information encoded in the XML message. 

The summary of these tests is presented here. Details of the XML files scanned along with their sizes and timing information appears in the Appendix at the end of the document. 

Timing Results of the Prototype for:
Decoding XML requests and transfer of a given bytes of data and Inserting Objects in the Object Store (3 readings)

Amount of Data	Microseconds	Microseconds	Microseconds	
512 bytes	5159	5132	5247	
1K (1024)	5683	5723	5680	
2K (2048)	5389	5431	5392	
4K (4096)	5641	5602	5784	
8K (8192)	5100	5108	5210	
16k (16384)	6218	6378	6234	
32k (32768)	6000	6212	6213	
128k (65536)	6482	6544	6345	
256k (131072)	7392	7564	7293	
512k (262144)	8200	8213	8301	
1MB (524288)	9390	9491	9358	
2MB (1048576)	14500	14567	14543	
4MB (2097152)	18336	18311	18673	
8MB (4194304)	32463	33126	32645	

Timing Results of the Prototype for:
Scanning through XML object representation 

XML File	Microseconds	
Sample 1 ComponentServer.1.sys	32146	
Sample 2 ClientProgram1.prg	17980	
Sample 3 ServerProgram.1.prg	6853	
Sample 4 Client.1.mod	5166	

The details of the sample files can be found in the Appendix. 

Timing Results of the Prototype for:
Creating XML object representation of an object 

XML File	Microseconds	
Reading 1	4757	
Reading 2	4521	
Reading 3	3875	
Reading 4	5102	

Calculating Load:

Whiteboard:
For 1120 bytes of data, measured as in step (1) the service time is 5641 microseconds. Hence, = / = 0.005641. Since this ratio is less than 0.25, the load can be easily handled by the system. 

For 480 bytes of data, measured as in step (1) the service time is 5159 microseconds. Hence, = / = 0.005159. Since this ratio is less than 0.25, the load can be easily handled by the system. 

For fast drawing with arrival rate of 1400 bytes per second, the service time is 0.005683. This is, again, less than 0.25.

Chat:
Thus, Arrivalchat = 1 message (300 bytes) per second. Service rate is the inverse of the Service time, 1/5159 microseconds. Thus the load factor is 0.00519. This is below the permissible load factor. 

Annotation:
Thus, Arrivalannotation = 1 message (2000 bytes) per second. The service rate is 5389 microseconds and load factor is 0.005389. This too is less than the 0.25 value for load. 

From these figures, with a known service rate, and maximum allowable load as 0.25 we can calculate the maximum allowable client request coming into the system.

Calculating with the above figures, we arrive at a allowable arrival rate of 45 request per second. This would provide the sufficient level of user experience. 

This is rate of request arrivals is assuming a single client at a time is being served by the system. With multiple concurrent clients, we have to derate the service time. Considering N is the number of concurrent clients, . 
Taking value of  as .25 to consider maximum loading, we arrive at the value of N between 6 – 7. This however represents the extreme pessimistic case.
We do not ordinarily expect to have this value of concurrent clients. In fact concurrency of client requests is a rare case in the Remote Collaboration System. 

A project would involve 3 to 4 users collaborating in the system. Therefore the range of allowable projects would be around 12 to 15 for the normal case and as 2 for the extreme pessimistic case. 

Load Analysis for a Dial-Up Line:

A 56K dialup line never attains bandwidths greater than 40 Kbps, so let’s take this as the bandwidth of the dialup channel, i.e. 5Kbytes/sec. 

We just calculated that a typical whiteboard diagram would be approximately 1120 bytes. We do not want a loading of more than 0.25. Hence want to ensure that we are not “stuffing” more than 1/4th the average queue length, so that the waiting times are not very long. Therefore, with the safety factor, the maximum rate at which we want to pump data into the dialup line is 5KBps/4 = 1.25KBps. 
So even with the extreme case of transfer of the entire whiteboard contents every second, or for the fast sketching case described earlier (10 strokes per second), we are not exceeding 1.25KBps. Moreover, even if we did exceed this limit, it would not really be cause for concern, since sending the entire whiteboard, or super fast sketching are “rare” events in our Collaboration System, that do not occur every second. So the queue length would have a chance to subside after increasing momentarily – always within the safety factor considered. 

Load Analysis for Voice Messaging 

The steps to be taken to analyze the load due to voice messaging are:
•	Approximate a value of arrival rates of messages
•	Calculate how long in terms of time (minutes) an average message would be.
•	Start “Sound Recorder” or other program and calculate the number of bytes generated for a voice message of the said duration.
•	Build a prototype where a client sends a message to the server. The server extracts the voice data from the message and broadcasts it to all clients.
•	Calculate the service time. 
•	Calculate the load on the server.
•	Calculate load for different cases by trying and optimizing the packet size for transmission, keeping in mind the playback time of a message.

Memory Requirements on Server

CPU clock cycles is not the only resource that a client uses. IT also uses memory on the server/ We must analyze the load on the server to determine whether or not the memory requirements of the client are reasonable. If not a redesign of the system in necessary. The following steps will be taken to analyze load.

•	Build a prototype client and server passing sample hard coded whiteboard object messages, voice and chat messages etc.
•	Before starting any client calculated the memory utilization of the server machine from the Task Manager tool on the taskbar. Then start a client and note the difference in the memory usage of the client.
•	Start the typical number of multiple clients expected and check to see if memory requirements are reasonable.
•	Keep increasing the number of clients to find out the maximum capacity possible or till the point we are sure that memory scarcity will not be the bottleneck. 

Critical Issue II

•	Writer Locks, Serialization  and the “Fairness Policy”

The collaboration system has several users, all using the system at once. It is highly likely that 2 users will try to edit a whiteboard object at the same time. This creates a unpredictable situation – which user’s changes would take effect on the object? And would this simultaneous access by 2 threads (users) corrupt the data stored in the object. 

This architecture proposes a solution wherein a writer “locks” the object it is manipulating. Thus no other writer is given access to that particular object. As a result, several users could be writing simultaneously on the whiteboard—only not to the same object. 

A color coding scheme for objects is an effective way to indicate a writer lock. The object being written to is painted “green” in the writers whiteboard, and painted “red” in the whiteboards of other users – this informs other user that they need not try writing to the object since they do not hold the access to the object.

The object store holds all the information about the objects in the Remote Collaboration System. Since it is a centralized store there will be many clients attempting to read and write to it simultaneously. This architecture proposes queues to serialize accesses to the object store. All clients are allowed to read the object store simultaneously without any queues, but for writing to the object store queues are used for serialization. 

After a writer has finished writing, he in a way “relinquishes control” over the object just written to, opening  the way for other users to manipulate the object. This raises a question – which user should be allowed to manipulate the object next? 

We debated as to whether our system should incorporate a “fairness policy” – should the writer that first tried to write to an object while it was locked be given access once the object becomes unlocked, or should the accesses to objects be on a first-come-first-serve basis. If fairness were to be adopted, our system would have to build an elaborate token-passing scheme between the different clients to determine who should be writing next. A central arbiter (most likely the server) would have to take care of token management.

 While this is definitely achievable technically, this would increase the complexity of the system many times over, would increase the traffic between the client and the server and between the clients due to passing of tokens, and also increase the load of processing on the server—all undesirable side-effects of a seemingly legitimate design goal.

It was finally decided not to adopt a “fairness policy”. While the above reasons factored in the decision, the main reason for not adopting a “fairness policy” was that it was awkward in the collaboration context. In real-life collaborations and social situations where people are talking together there is no real fairness policy – the individual to seize the opportunity at the right time is the one who gets to speak. Since the main objective of the Remote Collaboration System is to mimic real-life sessions in spite of being separated by a distance, the idea of having a fairness policy was rejected. 

Critical Issue III

•	Why an XML Object Store? Why not a Database?

The Remote Collaboration System stores all of its graphics objects with the XML descriptors in a centralized location. The graphics objects could have also been stored in a Database.

Two reasons prompted choosing an XML Object Store rather than a Database:

1.	The data being stored in the Remote Collaboration System is too heterogeneous for building a relational database model. Mapping heterogeneous data to the relational model is not beneficial. Hence an Object Store, such  as the one described in this architecture documents was a natural choice.

2.	XML formatted data adds the possibility to exchange information with other systems, even between non-standard systems that do not use the same data exchange standards. XML has evolved as open standard that has been widely accepted. Databases are on the other side of this spectrum – they are proprietary and in most cases cannot exchange data easily between themselves. 

Critical Issue IV

•	User Limit Implementation Mechanism

The load on the server is an extremely important issue – it must not be allowed to it maximum otherwise existing users of the system would have to face a serious degradation in their collaboration experience. 

This architecture has done a loading analysis of the system and arrived at a figure pertaining to the maximum number of clients that can be supported by the system. Our server should ensure that connections greater than the maximum limit are refused to ensure satisfactory user experience to the other clients in the system. 

However, consider the case when say a 100 number of user is calculated as the maximum limit. A 100 client connections have already been accepted. At this juncture a client with very high priority (and whose presence is critical to the collaboration meeting) wants to connect. This is poses to be a problem – not allowing a high priority client to connect is decreases the effectiveness of our system as a collaboration tool. Again dropping existing clients to accept high priority clients is not acceptable.

To avoid this situation this architecture proposes two limits that the server checks before accepting client connections:
Soft Limit and Hard Limit. 
The hard limit is the actual limit a client cannot exceed to ensure satisfactory user experience. In the above case it is 100. The Soft Limit is a limit numerically a little less than the Hard Limit, i.e. with a safety margin, e.g. 95. The architecture proposes the server behave in the following fashion: When the number of clients using the system reaches the soft limit (95) it accepts no more connections from clients. However if a high priority client wants to connect, it is allowed, since the server can assign connection with its surplus quota of connections due to the safety margin. This will ensure the precedence of an important activity over the rest. 

Critical Issue V

•	Do we need Priority Queues?

Priority queues are queues with greater priority than other queues. Consider we have 2 queues one with higher priority than the other – the queue with the lower priority will never be processed until the queue with the higher priority is empty. 

Notification messages are generally over a higher priority than chat messages and drawings on the whiteboard. Thus the system could be improved by having a priority queue for notification messages, e.g. a disconnect message from a client. Else the disconnect message may have to wait for a long time, while a large whiteboard object is being transmitted. 

However as has been mentioned earlier in this document, clients in our system already have separate queues for different data. One queue is used to transfer graphics objects and another queue is used for transmitting chat and notification messages. Thus a notification message may have to wait for a chat message to be processed. Intuitively one can estimate that chat messages are not very big. (The loading analysis section of this documents also discusses the expected length of the chat message.) Hence the worst – case scenario is that a notification message will have to wait when for a client message to be processed. Since client message are short, the time it takes wait for a notification message is not very large. As a result, we decided not to implement priority queues. 

Critical Issue VI

•	Annotation Versions – How much of a change is really a change?

A crucial aspect to be considered is the versioning scheme that is implemented. In the Remote Collaboration System several teams may be annotating the available component. None of these annotations are overwritten by one another. The versioning scheme must ensure that all versions of a component are present in the server. In exceptional circumstances a particular annotation could be deleted but only by the administrator. 
A problem with versioning is the creation of several unnecessary versions. Consider the case when a trivial change is made to a component – a spelling of one of the words is changed. Our strict versioning policy would create new versions for these files also, wasting space. If the number of annotations are large and the number of users are many, the amount of space wasted could be significant (though not large). Thus an efficient versioning policy needs to consider “how much of a change is really a change?”

Our architecture offers the following solution:
A text based comparison of the new annotation is done with the previous version of the annotation file. If the change is less than 5% and the author of the 2 versions are not the same a temporary new version is created. The permanent existence of this annotation is contingent on what the 2 authors decide to do. Immediately after text comparison the new author is informed that since the change is only 5% or less, does he really want a new version, or does the earlier annotation suffice. If the author insists he wants a new version, the author of the older version is notified  -- since the change between his version and the new version is less than 5% , does he want his version to continue to exist, or should it be replaced by the new version. In most cases one of the 2 authors will decide against creating a new version, significantly reducing the number of versions the system generates. (Until either of the authors has not “replied” to the notification, the temporary version of the new annotation acts as a new annotation file for all practical purposes).
Thus the implementation of this “change policy” is able to eliminate the problem due to minor changes in annotations creating a large number of versions. 
If the change in annotation is more than 5%, probably a new version is needed. Remote Collaboration System does not intend to analyze the “content” or subject of annotations – a job left for the human administrator, who anyway enjoys the right to delete versions of annotations. 

Critical Issue VII

•	Multicast – how is it implemented and does it affect performance?

The type of communication in the Remote Collaboration System is not client to server, but rather than client-to-server-to-client. Most client messages to server are broadcast to all other clients. Since several project teams could be having their independent sessions, the server has to multicast to only those clients subscribed to a particular project. 
A hashtable which stores all the clients subscribed to a particular project and their remote objects are stored in a hashtable. The server simply has to walk down this hashtable and call a method of the remote object that does the data transfer and then move onto the next object. 
Since the time of flight over a network is not included in the service time – only the time to enqueue the data in the send buffers is – the server load does not significantly increase due to multicast. 

Critical Issue VIII

•	“Disadvantaged” Users: Dial-up and different Time Zone users

The section on Load Analysis predicted that sending data – whiteboard, chat or annotation – would not be a problem for users on a 56k dial-up connection. However, as has been mentioned during load analysis, voice transmission over dial-up is definitely a problem. The bandwidth is not enough for real-time voice transfer. 

There are several ways to get around this problem:

1.	Text transcripts of the audio discussion going on between the high bandwidth users are available for dial-up users. 

2.	Users can also use the telephone for audio communication. This results in a slight loss of functionality as far as saving and retrieving audio discussions. 

3.	If dial-up users require records of audio discussions, a delayed transmission approach is employed. E.g. the audio files are sent at night or other non-peak hours, so that it does not hamper the collaboration session. Compressing WAV files (the audio format adopted in the Remote Collaboration System) can achieve very good results. This approach is particularly desirable as it has a good Computation/Communication ratio for voice transfer and it is the network communication that is the bottleneck. However the time taken for compression e.g. MPEG Layer 3 (MP3) compression precludes any possibility of using this approach for real-time voice communication. However audio compression will be useful for delayed voice transmission. 

Users in a different time zone than the majority of collaborators also have similar collaboration problems. They cannot use any sort of real-time communication. 

This class of users can download the transcripts of chat sessions, a record of the major whiteboard snapshots and files of audio discussions that have taken place. They can  also make use of the facilities provided to low-bandwidth users. 

Summary

The Remote Collaboration System is a tool of immense utility for distributed software development. It allows virtual meetings and collaborative developments and code review sessions through its various features – voice and text messaging, a graphical whiteboard, an annotation service and a component server. 
This architecture documents analyzed the partitions and activities of this system in detail. The system was also analyzed for load and prediction as to how many client it could support were also made.
Several Critical Issues were such as support for users with low bandwidth, queueing issues, multicast issues, writing contention issues among others were raised and solutions were offered in response to these issues. 
The development of this project is achievable, but serious consideration has to be given to the areas mentioned. By highlighting the important issues right at the outset, the architecture will help in the development of this project. 

Appendix

Timing Results of the Prototype for:
Decoding XML requests and transfer of a given bytes of data and Inserting Objects in the Object Store (3 readings)

Amount of Data	Microseconds	Microseconds	Microseconds	
512 bytes	5159	5132	5247	
1K (1024)	5683	5723	5680	
2K (2048)	5389	5431	5392	
4K (4096)	5641	5602	5784	
8K (8192)	5100	5108	5210	
16k (16384)	6218	6378	6234	
32k (32768)	6000	6212	6213	
128k (65536)	6482	6544	6345	
256k (131072)	7392	7564	7293	
512k (262144)	8200	8213	8301	
1MB (524288)	9390	9491	9358	
2MB (1048576)	14500	14567	14543	
4MB (2097152)	18336	18311	18673	
8MB (4194304)	32463	33126	32645	

Timing Results of the Prototype for:
Scanning through XML object representation 

XML File	Microseconds	
Sample 1 ComponentServer.1.sys	32146	
Sample 2 ClientProgram1.prg	17980	
Sample 3 ServerProgram.1.prg	6853	
Sample 4 Client.1.mod	5166	

The details of the sample files:
ComponentServer.1.sys
ClientProgram.1.prg
ServerProgram.1.prg

These file can be found in Projects #3 and #4 Component Server.

Timing Results of the Prototype for:
Creating XML object representation of an object 

XML File	Microseconds	
Reading 1	4757	
Reading 2	4521	
Reading 3	3875	
Reading 4	5102	

File for reading: Client.1.mod