Problems

Perhaps the most significant advantage of the distributed implementation model of this project is the separation of concerns it affords; each team can concentrate on its own project without having to implement the entire network infrastructure from scratch, and the entire group can come up with an interesting total work. However, our application is expected to work regardless of whether or not the rest of the infrastructure is in place.

Perhaps the most significant setback is that our role as an application on top of this telephony system makes us highly dependent on the interfaces provided by the signalling team and that they will be implemented as specified. However, in order not to be penalized in the event that the signalling team is unsuccessful, we ensure ourselves of a backup plan. That is, we must take extra care in generating code that is both well encapsulated and easily interchangeable with other teams' code in order to make maximum use of the resources with which our teammates have provided us.

At any rate, we began our coding using these predefined interfaces. This strategy, however, led us to a situation where testing became impossible since the code on which we were absolutely dependent was still quite unavailable. To further the point, the mere ability to compile was a milestone in itself. The fact that the code that was available (on cvs) was often out of date, if available at all, and that each class seem to link endlessly with other classes made isolating what we need impossible.

In addition, we were faced with many problems of our own. Our inexperience in developing multi-threaded applications, integrating functional user interfaces, and working in this kind of student-run programming environment hindered us significantly. As an application team, we were always among the last to hear of any thing. The amount of support we received was minimal. It appears as if it was only within the last two days that our group began integrating and providing us with a stable environment to test in. This was most definitely not what we hoped for. What this meant to us was to give up our sockets implementation of connections and begin plugging Signaling's interfaces into our code. Integration was, to say the least, not an easy job. Getting our code to work fluidly with the system was a goal we never achieved.

As for technical problems, we found it near impossible to test our code on multiple machines (which is a requirement given the nature of our application). As a matter of fact, testing time on our own MIA machine was hard to come by, let along time on it and on another CS519 machine simulutaneously. In addition, it seems that the JVMs in jview and Microsoft Visual Studio 6.0 have significant enough differences that our code running under jview was unable to communicate properly with the SigServer that Signalling provided to us. Another problem we encounter the machine cs519mia had a different IP address from the one the DNS knew it by. We wasted considerable time wondering why our code suddenly would not work on our own machine despite its correctness on other teams' computers.

Additionally, we could not run WBD on most of the NT machines, because WBD requires write access to C:\, which was forbidden to our accounts on all but the MIA machine. However, because of the difficulty in securing computer time on multiple CS519 machines, we resorted to using Windows 95 machines in the Upson basement computer lab. This leaves us somewhat unsure of its potential performance in the CSUGLab.

From what we did gather from WBD, it performed very well in unicast. However, under multicast conditions, the applications showed very noticeable lags when more than two users scribbled simultaneously. This however does not detract from its suitability. We suspect that in an actual conference, more than one user will rarely need to draw at a time.