For some reason, the UDP-code in the applet causes a SecurityException when run within Netscape Navigator on a Silicon Graphics Indy equipped with the Irix operating system. No problems are encountered when using Navigator on Solaris, or Navigator and Microsoft Internet Explorer on Windows 95 and Windows NT. A bug in the Java library on Irix may be the cause to this problem. People at USIT reported similar behavior with their own Java UDP-code on HP-UX.
The Java applet had no problems receiving and decoding the image stream at the current rate and size. The inner loop in the decoding process is quite simple, doing three additions, three bitwise operations, two type casts, and two array element assignments. An interesting project for further study, would be to implement more advanced image representation schemes, and do performance tests on new implementations. If better compression is added, the size or number of packets transferred would be reduced, requiring less time to be spent in the network related code. It would be interesting to compare the time released by reducing the data size, to the time required to do more advanced decoding.
Moving this implementation from the experimental to the useful state, requires several enhancements. First of all, a standardized video compression scheme should be implemented, to allow higher visual quality and lower bandwidth requirements. Secondly, to be able to do more than wave and smile to the spectators, sound should be possibly transferred along with the video. Unfortunately, Java's sound capabilities are rather limited. Currently, the only sound support is the ability to play AU sound files, suitable for low quality, prerecorded clips.
Another important step is to take into account a possible limitation or variation in available bandwidth, by allowing negotiation of transfer speed. This greatly complicates the handling of viewer clients in the proxy and the grabber, since clients can no longer be handled equally. To cope with variations in bandwidth between viewer clients, some clients should get a reduced frame rate or a reduced quality compared to the others. In the current setup, the proxy just distributes datagrams to all viewers, with no knowledge of the contents. The grabber program handles all video details, but knows nothing about the various viewer clients. The easiest approach will probably be to extend the grabber to handle all viewer clients, and create adapted datagrams. This will however, greatly increase the network traffic between the grabber and the proxy.