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.
The whiteboard application accomplishes the following tasks:
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.