Whiteboard with Java multicast and simplified RTP

Hong Shi
Center for Telecom Research
Columbia University
New York, NY 10027
hshi@ctr.columbia.edu


Abstract

In this project I implemented a simplified whiteboard (a chat tool) with Java multicast and Real-Time Transport Protocol (RTP) [1] as the underlying network platform. The project focuses on building the chat tool for collaborative computing, and explores the feasibility and applicability of using RTP in this non-real time application. This report describes the architecture of this application and implementation details.

Introduction

Whiteboard is an application that provides its user an area to post messages and other objects for sharing with other users and also to receive other users' posts in near real time. When a user posts an object, all other users in the same session see it. The basic tool is a text tool, with which text messages are posted. Drawing tool is also very common, where one drawing is shared by all other users, and multiple user can work on the same drawing. More advanced tools will give users the ability to post images, and even audio and video clips, to the whiteboard. The delay between posting and receiving should be small, but the variance is not critical, except when audio and video are used and are streamed from the source.

Related work

There are many whiteboard implementations. DataBeam Corp. has a commercial whiteboard application, neT.120, implemented according ITU T.120 standard, provides an application and a toolkit for development over their implementation. ACM hosts a Web page which provides a lot of information on shared whiteboard applications. Java implementations are also available. Stuttgart University Computer Center's TeleDraw is a comprehensive set of tools for data conferenceing. RTP/RTCP and multicast are used as network support. One group (Cheok and Li) in this class in fall '96 implemented it with the same network platform. Andersen, Denmark, and Lew  also implemented a whiteboard with functions relevant to a classroom scenario.

Background

Most whiteboard implementations fall into two categories: server based and non server based.

In server based whiteboard, all users log on to a server. Data exchanges are all between the server and individual clients. The server maintains the states of the session as well as the states of each client. Each client posts messages and drawings to the server, and the server forwards the messages to each client in the session. Clients could also obtain session information, e.g. participants list, from the server.

In a non server based whiteboard, all clients communicate to each other. This is often done through broadcast or multicast. In the case of multicast, each client who wish participate in a session should explicitly join the session (in multicast, a session is represented by a multicast IP address and a port number). Clients send messages on this IP multicast address and the port number. The messages will be forwarded to every clients who have joined the session. There is no central control point, so each client should main its own states and the states of the session.

Non server based whiteboard avoids the problem that server based whiteboard has, that is, the server is a single point of failure. When the server fails, no session could take place. This implementation also has better scalability, because it does not depend on the processing power of the server. On the other hand, because there is no single session control point, the control of the session is distributed among all participants, and this is usually more complicated than centrally controlled implementations.
 
Java is used for implementing this whiteboard application. Java is a platform independent programming language and computing platform. It is available for most major hardware/OS platforms. Java programs requires little or no effort to port from one platform to another. Using Java to implement the whiteboard simplifies the task of cross platform communications. JDK1.1.4 is used in the development. It provides support for IP multicast within its core API.

RTP is a protocol designed for real-time applications over internet, RTCP (Ream-time Transport Control Protocol) is the accompanying protocol which specifies how the control is carried out in a session. In this implementation, RTCP is used to carry session information such as participant names and email addresses. RTP/RTCP are designed for real time applications, it specifies comprehensive timestamps to facilitate accurate playback and intra-media synchronization. These features are not needed in whiteboard (no streaming in this implementation), and are not implemented. And due to time constraint, only a chat tool is implemented. Please refer to Future Work in Program Documentation for discussion on future improvement.

Design and Architecture

The whiteboard is implemented as a Java application instead of a Java applet. This is due to the security restrication on applet that it can only make network connections to the host where it comes from.

The whiteboard application accomplishes the following tasks:

RTP and RTCP are used in my implementation. User messages are encapsulated in RTP packets. Session control information are encapsulated in RTCP packets. These packets are in turn put in IP packets and sent out using multicast. A pair of port numbers are needed. One for RTP transmission, the other for RTCP transmission. At the beginning of a session, user enters an IP address and a port number. This port number is for RTP. RTCP port number is simply the RTP port plus 1, and the two share the same IP address.

The whiteboard has three major components in its main window. A text area for displaying user messages (including those sent by itself), a text area for displaying participant list (in the format of user@host), and a text field for user to type in messages.

The whiteboard is implemented as a multi-threaded application. At start, the application initializes a dialog box with four entries for the user to fill in: User Name, Email Address, Session IP Address and Port Number. After the user fills in these items, the application (main thread) initializes a multicast socket for user message transmission. It then spawns a thread called RTPReceiver. This thread takes in the IP address, joins the multicast group and listens on the designated port. When a message is received, it extracts the message from the packet, and posts it in the user message area in the main window. The thread blocks when there is no message.

The main thread takes care of the transmission of user messages. A class RTPSender is created for this purpose. An instance of this class is created after the user provides necessary information. This instance is registered as a key event listener of the user message input text field. Each time a key is pressed in this field, the keyPressed method of this instance is called. And if the key pressed is the Enter key, the text in the field is extracted, encapsulated in a RTP packet, and sent out.

The main thread spawns another thread after it starts the RTPReceiver thread. This thread is the RTCPHandler thread. This thread keeps track of the session control information. It takes the IP address and port number passed from main thread, and spawns yet another thread, RTCPReceiver, for receiving RTCP packets. Sending is handled in the thread itself.

RTCPHandler maintains a vector which contains the participant information. This vector is updated by the RTCPReceiver thread after each RTCP packet is received. If the RTCP packet contains information about user whose information does not exist in the vector yet, it is added into the vector, and participant information text area is updated. If some user leaves the session (a BYE packet is received), the thread removes the corresponding information contained in the vector, and notifes the user in the participant list area that some user has left, together with the user's informaiton.

RTCP packet is sent periodically to keep other user notified the existance of this user. The packet is either SR or RR compounded with SDES packet. Within SDES packet, CNAME, NAME and EMAIL fields are present. In the RTP and RTCP headers, there are several timestamp fields--RTP timestamp, NTP timestamps. The whiteboard does not need accurate rendering, so these timestamps are not used and are all set to 0 in the headers.

The architecture of the program is shown in the following figure:

When a user joins a session, it picks a number, Synchronized Source (SSRC) as its id. This number is 32 bits long and should be unique within a session. In this application, it is generated by the Java random number generator (Java.util.Random) using the current machine time as the seed. Collisions are possible if many users start at about the same time. But for a small session, the probability is very small, and is not considered in this implementation.

Another randomly generated number is the starting sequence number. This is a 16 bit number again generated by the Java random number generator. The generator generates signed numbers, so the sequence number and SSRC id can be negative, but this does not vialate the specification of the RTP protocol.

Program Documentation

Reference

[1] RFC 1889, RTP: A Transport Protocol for Real-Time Applications, February, 1996