1. Overview

Our whiteboard design is based on a mix of distributed and centralized approaches. The same code package will be executed on each client that participates in the meeting. However, once the discussion starts, a host will be chosen to act as coordinator of the meeting. This will be dynamic, so that if the host is unresponsive for any reason, a new host will be chosen from the list of participants. Each of the clients will be capable of negotiating this process. Also, the clients will keep a log of their updates in case the host goes down after the updates are processed. The host will also be responsible for keeping track of the current “gold” copy of the whiteboard canvas. This involves resolving simultaneous updates through a timestamp and queue priority order.

The user interface will use the membership and I/O blocks to display the current list of participants and provide services to the user, such as print, and open/save functionality, respectively. When the local user updates, the UI sends the updates to the Local/Remote resolution layer for delivery to the other clients. The UI will also receive updates from this layer for display to the local user. The Local/Remote Layer will decide how to process incoming outgoing updates and then send them to the formatting layer or UI depending on how they were received. Finally, the Network Interface Layer, provided by JGroups will take care of notifying the current participants as well as detecting disconnected peers.

2. Functional Requirements

· Initial Connection made using known address

o Each side should have “listen” mode to be able to receive incoming connections

o Only launch entire app once connection is accepted by listening side

· Drawing

o Lines

o Shapes

o Arrows

o Colors

§ Color mapping from one color on one client to different color on another

o Eraser

· Drawing Space

o All clients can draw over same space

o “Never-ending” Space

· Text Labels

· Pointer for each client

o Tag on each w/client’s name

· Save/Restore space

· Print Capability

· Offline Editing

· Low latency

· Simultaneous editing to different sections of the whiteboard

3. Component Details

3.1 Network Interface Layer

JGroups was chosen as our network interface toolkit because, out of the packages we evaluated, it best fit our needs and requirements. From JGroups website, it provides:

· Group creation and deletion. Group members can be spread across LANs or WANs

· Joining and leaving of groups

· Membership detection and notification about joined/left/crashed members

· Detection and removal of crashed members

· Sending and receiving of member-to-group messages (point-to-multipoint)

· Sending and receiving of member-to-member messages (point-to-point)

3.2 Local/Remote Message Formatting

This module is responsible for marshaling/demarshaling the datapackets. This module communicates with Local/Remote Resolution module and JGroup module. It receives data from Local/Remote Resolution module and formats(marshals) it into a suitable format that JGroup expects. On the other direction, it receives data from JGroup and demarshals it. The data then are delivered to the

Local/Remote Resolution module.

3.3 Local/Remote Resolution Module

Responsible for resolving picture information. Receives local updates from the UI module and remote updates from the network (through the formatting module). Ensures that all clients maintain identical copies of the whiteboard. A conflict occurs anytime two updates with same timestamp value attempt to update the same area of the whiteboard. Conflicts are resolved using priority information. Local updates are compared with any received remote updates for conflicts, timestamped and sent to the formatting module. Remote updates are checked for conflicts and sent to the UI module.

3.4 User Interface

The UI component will consist of a drawing area and a set of buttons and/or other widgets that allow for selection of shapes, colors, a pen, and an eraser. The UI component will display a list of other users that are participating in a drawing session. This user list will also display and highlight the drawing session owner. One of the features of the UI component will be the ability to partition the drawing area into separate and distinct drawing areas. Two or more users can then draw in their own areas. There will be a button that will allow a user to invite another user into a session. This button will cause the creation of a dialog box that will have fields for entering in either an IP address or a machine name that is resolvable on a DNS server.

3.5 Membership

The main responsibility of the membership block is to contact the groups members and add them to the current membership list. The membership block receive a list of IPs/machine names to be contacted from the UI block, The membership block send a QUERY message to these machines and if any of them is up, it returns the list of group memberships (their current membership list), then the membership block will send a JOIN multicast message to all the group memberships telling them that it is going to join the group. All the group memberships who received the JOIN message from the new member will reply by ACK message, and the new member will add them to its current group membership list.

Any member did not reply by ACK message will be contacted for while, if it did not reply, it will be consider as a down member and will not be added to the list. Every random time, the membership block will send HEARTBEAT message to its membership list to see if they still alive and exchange the view with each other to keep the membership list synchronous. When a group member exits, it sends a multicast LEAVE message to its membership list, so they remove it from the their list.