Accomplishments

Rather than implementing the whiteboard from scratch, we incorporate an existing piece of software called WBD, a Windows 95/NT port of the Unix wb program. WBD works independently of our code and is launched and killed on each machine parallel to the establishment and removal of conference connections. Here, we will briefly describe the use of WBD.

WBD is invoked with command-line arguments specifying the connection address and port:

    wbd <address>/<port>

For a unicast (point-to-point) conference, each host invokes WBD using an agreed-upon port and the other's IP address. For a multicast conference, an agreed-upon multicast address (in the range of 224.1.0.0) and port are used. An additional argument can be passed to indicate the desired time-to-live for packets, but we do not use it. The actual use of WBD is straightforward, much like any simple drawing tool.

As for the audio conferencing portion of the project, what we accomplished unfortunately was quite short of our original intent. Being very optimistic in the beginning, we aimed for excellent voice propagation through a rather fault tolerant bridging structure and many features that would make our software as complete as possible, such as the ability to select from and to join currently running conferences and to kick off unwanted guests. As it turned out, however, we were only able to implement connectivity between two clients with very poor voice transmission. Our inability to improve quality and performance of voice transmission rendered it impractical (and pointless) to extend our application to be multi-party enabled. That is not to say we did not strive for multi-party support because much of the code necessary for it is present. For example, the choice of storing all connections in a Vector data structure permits us to scale. This choice also allowed us to incorporate different ``connection'' objects that we substituted for Signaling's connection classes. The need for this kind of encapsulation is explained in the next section which characterizes our conerns.

The software has two functional roles. One is that of the master who controls the conference and invites others to join the conference. What we intended to do with the master was for it to control the entire conference, from managing guests to maintaining the bridging structure that we talked about. Of course, these embellishments to the software were never made. The other functional role is that of the client who basically waits to be invited into a conference by some master. Originally we planned to allow the client the ability to send a request to the master for admission into the conference. Since the client can have multiple connections in the bridging structure, its code is very similar to that of a master. The application begins with a log in screen. From there, the user can choose to be either a master or client. At this time, we also make a call to Signaling to register the user with directory services. By registering a user that is a client, we can provide our users with the ability to locate another user simply by entering his name or id. The process of doing so, we are sure, will be further described by Signaling and Directory Services since they are the ones that provide us with the functions to do so.

In selecting to be either a master or a client, if the user chooses to be a master. The user then needs to enter a name for the conference he or she is about to start, and provide a list of all users to be invited. The name of the conference, along with the name of the user and the machine he/she is on, is registered with a directory server of our own which we will describe soon. As the conference is being registered, the software also sends out invites to the various guests. The guests can then elect to accept or decline the invitation. Although, the user interface supports many guests, our code is only able to handle two-way conferences.

Oh the other hand, if the user elects to be a client, the client will be presented with a list a ongoing conferences that he can request admission. He can also choose to wait for an invitation to a conference. In our current state, the software only allows the user to wait for an invitation.

In addition to the client and master components, we also completed a directory server which we hoped to use as a means of keeping track of all currently running conferences. This server, which we called the List Server, services requests in one of several ways:

1.

adds a new conference entry into its memory,

2.

lists the conferences that are currently in session, and

3.

removes conference entries that have not been reset or reconfirmed after a certain interval of time.

Although the List Server is completed (to the extent that its core functions are implemented), not much effort was put into integrating it with the main audio conferencing application. Hence, although the List Server is completed, its purpose is not really used.