Shared Whiteboard for collaborative
computing using Java Multicast and RTP

Evelyn Lai-Tee Cheok
Center for Telecommunications Research
801 Schapiro Research Building
Department of Electrical Engineering
Columbia University
New York, NY 10027

Chi-Hao Li
Department of Computer Science
Columbia University
New York, NY 10027

Abstract

Future computing environments will be designed to support interaction with people at least as much as with computers. With the increase in the use of computers for human interaction, the drive is towards developing collaborative and distributed computing environments. This project focuses on building a chat tool and a white board for collaborative computing. Our approach is to develop the application using Java multicast and Real-Time Transport Protocol (RTP) as the underlying transport protocol. This project report focuses on the suitability of using such an approach in implementing groupware application. Java programming language is used since it represents state-of-the-art in platform-independent application development.

1. Introduction

Recent trends in computing research and availability of inexpensive computing technology have encouraged the development of collaborative and distributed computing environments. Among the many collaborative tools used, whiteboard and chat tool serve as effective ways of facilitating communication and work collaboration. The advantages of collaborative work are tantamount over wider geographical areas, which calls for the need for multicast technology which is essential for conserving network bandwidth. Our project aims to develop and integrate both the chat tool and whiteboard into a collaborative tool in a Java multicast environment, using RTP as the underlying transport protocol.

This report details the design and implementation process of the project. The report begins by looking at related work accomplished by others before going on to define the project goals, scopes and assumptions. This is followed by design choices and justification, as well as a general overview of the software architecture and system capabilities. The detailed implementation, design issues and choices of the individual modules are covered in the section on Program Documentation. The documentation is concluded with a discussion on future work.

2. Related Work

EWGIE - The Easy Web Group Interaction Enabler is a free collaborative service that behaves much like an Internet Relay Chat. It's developed using Java language and is based on a server for relaying information to all it's clients. The chat tool provides the usual text-based communication. In addition, it implements features that allows users to ring or invite other people whom the users wish to communicate and to enter command line arguments in the text display area to indicate to other users of his/her non-availability. The Ewgie whiteboard presents users with graphics drawing capability.

Networked Whiteboard - This whiteboard application uses Java TCP sockets for connection to a server. However, connection will only be successful if there are at least two users.

The various applications above provides comprehensive range of features for both the chat tool and the whiteboard. These are implemented as applets and use relay servers for communicating information among the users. However, it is of the author's opinion that the multicast technology is highly beneficial for attaining scalability in a distributed collaborative environment.

Along with the benefits of scalability and network bandwidth conservation, are important issues concerning reliable mutlicast. An IETF Internet Draft [1] on Scalable Reliable Multicast (SRM) has been proposed by Peter Parnes to address such issues. This draft documents how the RTP can be extended to include support for parts of SRM. Since the RTP is based on UDP which is a best-effort transport protocol (meaning that data packets can be lost), a reliable multicast protocol is necessary for transporting data flow reliably as necessary/essential in applications such as whiteboards, semi-reliable audio/video and messaging/data-transfers within group-ware applications. In SRM, buffers are implemented for the need of re-transmission in the event of packet lost. A receiver notices that a packet is lost by comparing the sequence number of the incoming packet with the last heard packet before that. Before the receiver begins to send any NACK using multicast, she/he waits for a random period of time. If some other group members have sent a NACK for the same packet, then she suppresses her NACK-transmission. The same technique is used for any members who wishes to respond to a NACK. The NACK timer is determined based on the distance between the source and the receiver. The document also explains why the SRM fits into the RTP (since RTP also provides SSRC, sequence number, etc) and suggests further addition to the RTP, such as introducing new packet RTCP format for supporting SRM commands like heartbeat, time-stamp queries, single NACKs, sequential NACKs, etc.

3. Project Goal, Scope and Assumptions

The main impetus of this project lies in developing a subset of a multimedia tool using state-of-the-art networking technology and protocols in a platform-independent multicast environment for supporting collaborative computing. This is realized by integrating both chat tool and whiteboard into one of the component for providing future multimedia services (such as teleconferencing) and using Java as a platform-independent language both for building the graphical user interface and more importantly, for providing mutlicasting capability. This project also serves as an early stage of experimenting the feasibility of using RTP and RTCP for non-real-time application.

Due to time constraints, the scope of this project is limited to demonstrating the few important capabilities of both the whiteboard and chat tool, as well as the use of RTP as a transport mechanism for data packets and RTCP as an indispensable communication mechanism for conveying user information in a multicast environment.

This application is built for multicast users who desire to interact within a small geographical area with the assumption that the propagation delay for all packets is small relative to their transmission delay, and hence issues pertaining to implementing reliable multicast (such as packet loss, out-of-sequence delivery, synchronization problem, etc) are not a part of this project. However, the authors' view of future enhancements and possible solutions for solving the above-mentioned issues are presented in Section 5 of the Program documentation.

4. Design Justification

4.1 Programming Language:
Application has been developed using Java programming language to take advantage of its platform-independent capability.

4.2 Network Technology:
Developing this application using multicast technology disassociates it from the need of a central server, thus preventing the situation of paralysing the whole system when the server breaks down. Multicast technology saves bandwidth as compared to unicast applications.

4.3 Java application vs Java applets:
The system is built as a Java application, instead of a Java applet, due to the security restriction of using an applet for performing multicast operations.

4.4 Transport Protocol used:
RTP and RTCP provides a good choice for multicast environment. RTCP is used for conveying information in a multicast environment. It ensures scalability in multicast sessisons ranging from a few to thousand users. Using RTP for transmitting data packets allows the application to inter-work with other RTP-compliant products.

5. System Architecture and Design

This project can be described both in terms of its application specifications and its software architecture.

5.1 Application Specifications


5.2 Software Architecture

The diagram above illustrates the software architecture of this project. The red lines indicate the flow of control information which is the user SDES information in the context of RTP, while the black lines indicate data flow (graphics object data, chat strings and RTP packets). Users interact with this application via the Java User Interface that comprises of the Login Session Dialog, the Chat Tool Panel, Whiteboard Panel and the User Information Panel (the Chat Tool Panel and the Whiteboard Panel being implemented as part of the Chat Tool and Whiteboard Modules repectively). These User Interface components are represented as yellow boxes in the diagram. The Chat Tool Panel presents users with a text entry field and display field for text-based communication, while the Whiteboard Panel forms the basis of manipulation and display of graphics objects.

The rest of the components in the diagram provides the communication functionality of the Communication Module. The RTCP Packet Handler consists of a RTCP Packet Assembler and a RTCP Packet Disassembler. The assembler performs the function of concatenating user information with other RTCP packets to form a compound RTCP packet, whereas the disassembler extracts user information from the received RTCP packet. Consider for instance the scenario upon application start-up where users are greeted by the Login session Dialog box and prompted for information like user name, email address, phone number and address. These user information are then assembled to form a compound RTCP packet for transmission. On the other hand, information of other multicast users are extracted from the received RTCP packet and forwarded to the User Panel for display. Likewise, the RTP Packet Handler can be described in a similiar manner, except that the content being handled is data rather than control information.

Unlike the control information which are encapsulated in one level (user information embedded within compound RTCP packet), two levels of "packet encapsulation" for data information is necessary for this application. Before data information can be embedded within the RTP packet, they have to be encapsulated based on our self-defined packet format for this application. The Chat Tool Assembler and Whiteboard Object Assembler are designed to perform such task. Since the packet format for the Chat Tool Module is different from that of the Whiteboard, the assembers are implemented as part of the methods within the classes used to implement each modules. The Object Disassembler, on the other hand, performs a task opposite to that of the Whiteboard Object Assembler.

As from the diagram, we can see that there are two forms of data to be handled in our application; one for the Chat Tool and the other for the Whiteboard module. In order to distinguish between the two forms of data, a Data Dispatcher has been implemented to forward incoming data to their respective modules for further processing by deciphering the first byte of the information contained in the data. Take for instance, data information such as chat string will be forwarded to the Chat Tool module which will display the string on the text display field of the Chat Tool Panel, while graphics object intended for the Whiteboard module will be passed on to the Object Disassembler which will, in turn, determine which graphics object classes of the Whiteboard module is responsible for displaying the received objects on the Whiteboard Panel.

Specific design choice and alternatives have been covered in the Program Documentation of this project report.

6. Program Documentation

This section contains links to program documentation and user manual of the project. Please also refer to the "improvement list" for a list of latest improvements and additional enhanced features.

7. Task List

Chi-Hao Li : Whiteboard Module (graphics object and stack implementation).
Lai-Tee Cheok : Communication Module (RTP & RTCP implementation), Chat Tool Panel, User Panel, Login Session Dialog, remote object move and deletion, improved user interface and added copy and paste functions for the Whiteboard Module. (Please refer to the "improvement list")

8. Acknowlegements

For acknowlegements, please refer to the Acknowledgements Section of the Program Documentation.

References

[1] IETF Internet Draft, November, RTP extension for Scalable Reliable Multicast , 1996.

Please refer to the Reference Section in the Program Documentation for a list of other references.