JMule team 3/8/2004

Technical Report Multi User Learning Environment (jMule)

Ioannis Baltopoulos Robin Kilpatrick Hannes Ricklefs Neil Saunders [email protected] [email protected] [email protected] [email protected] University of Kent, University of Kent, University of Kent, University of Kent, Computing Laboratory, Computing Laboratory, Computing Laboratory, Computing Laboratory, Canterbury, CT2 7NF Canterbury, CT2 7NF Canterbury, CT2 7NF Canterbury, CT2 7NF

ABSTRACT This report provides an overview of the final year project undertaken as part of a BSc (Hons) degree in Computer Science at the University of Kent during the academic year 2003-4. The project involved creating a software application that enables multiple physically isolated individuals to collaborate, learn, and give presentations through virtual meetings. The solution produced was entitled jMule, the Java Multi User Learning Environment. This paper outlines the processes, design rationale, implementation and testing that were conducted during this project and offers an exploration of possible future enhancements. It concludes by offering critical evaluation on the overall success of the project.

Keywords Distance Collaboration, Distant Learning, Virtual Presence, Collaboration in Education

1. INTRODUCTION ...... 1 6.2 User Evaluations ...... 6 1.1 Background ...... 1 6.3 Performance Measures ...... 6 1.2 Aims ...... 2 6.4 Known Issues ...... 7 2. PROJECT PROCESSES ...... 2 7. FUTURE ENHANCEMENTS ...... 7 2.1 Project Management ...... 2 7.1 Directory & Calendar Server Integration ...... 7 2.2 Quality Assurance ...... 3 7.2 Voice over IP (VoIP) ...... 7 2.3 Configuration Management ...... 3 7.3 Multicasting ...... 8 3. INCEPTION ...... 3 8. CONCLUSION ...... 8 3.1 Approaches ...... 3 9. ACKNOWLEDGEMENTS ...... 8 3.1.1 Peer to Peer – Server ...... 3 10. REFERENCES ...... 8 3.1.2 RMI – Sockets ...... 3 1. INTRODUCTION 3.1.3 RTP Multicasting – Multi Unicasting .....4 1.1 Background 3.2 Preliminary Work ...... 4 Since the advent of the Internet, the computing 3.3 Mathematical Analysis ...... 4 communications industry has progressed very rapidly. Today, any user with a desktop computer can access and 4. SYSTEM DESIGN ...... 4 multimedia documents with others through the 4.1 Specification ...... 4 Internet and it seems certain that the new future will see almost every person networked and online every hour of 4.2 Top-level Architecture ...... 4 the day. Due to this rapid growth, collaboration 4.3 Server Components ...... 5 technologies have become a big business. At a time when the IT industry has hit a slump, businesses are required to 4.4 Client Components ...... 5 do more with less and, coupled with the every increasing 5. IMPLEMENTATION ...... 6 cost of air travel, virtual presence is a buzzword that’s making itself known. As a result there has been a surge in 6. TESTING ...... 6 both the research being conducted and the amount of 6.1 Approaches ...... 6 money invested in this area; this is exemplified by

Page 1 of 9 JMule team 3/8/2004

Microsoft’s recent $200 million acquisition of PlaceWare, Finally, we aimed to combine these features in to an a leader in the production of collaboration software. [37] application that was Platform independent, Enterprise It is undeniable that the ability to allow a group of people strength, scalable, and intuitive to use [1,2] to interact and collaborate together irrespective of location at virtually no cost is an idea whose time has come. 2. PROJECT PROCESSES In order to successfully achieve all the aims specified and 1.2 Aims to ensure that the project was delivered to high standards, To begin with the team produced a Product Objective clear processes were established for the development of Statement (POS) [1] that loosely defined the scope of the the product. project, which was to create: 2.1 Project Management “A platform independent multimedia collaboration tool The first step in the Project Management process was to enabling people to communicate and learn irrespective of define roles of the team members. As all of the team location.” members had their own personal preferences the following division of roles was decided upon: More specifically, the team aimed to create an application Ioannis Baltopoulos, Software Architect that incorporated the following features: Robin Kilpatrick, Configuration Management Hannes Ricklefs, Project Manager Neil Saunders, Quality Assurance • Textual chat Although the roles assigned were very specific, each team • A shared digital whiteboard member contributed to the overall design and • File implementation of the system; code and document • A facility to communicate through the use of authorship was evenly distributed. Due to the limited size multimedia features including streaming audio of the team and the uncertainty surrounding some and video technical aspects of the project, an appropriate product development lifecycle had to be selected. This basic feature list was derived from a 2 week period The evolutionary development model was chosen as our of research in which we investigated and evaluated several implementation process for the project [3]; this model commercially available collaboration packages. involves developing an initial implementation, exposing In addition to the aforementioned features, we planned to it to users and gathering comments before refining it enhance and develop these ideas in order to provide an through many versions until an adequate system has been innovative and original perspective to the problem, and so developed. The model was chosen because it allows the extended the aims to include the following additional specification to be refined during the development process features: as obstacles were encountered. These were anticipated and allowed for through the use of slack time in the project plan. • The ability for a latecomer of a meeting to receive the current meeting state upon joining, According to literature [3], the main issues known of such as chat history and whiteboard contents using this process model were that resulting systems had a tendency to be poorly structured with poor process • The facility for a presenter to modify the functionality of the connected users’ clients visibility. As a result of this, the project manager during the meeting decided to further refine the evolutionary development model and, in doing so, the process gained extra • A presentation management system that would easily allow the presenter to deliver a structure. presentation to all users The project lifecycle began with the Inception Phase in • Potential to record the contents of a meeting and which the research was conducted. This allowed the make them available online when the meeting progression into the Planning Phase where the project has finished processes were defined. After this the evolutions began, • A queuing system for multimedia to provide an each containing a Design, Implementation and Evaluation intuitive priority queue that the presenter of the phase. meeting can control Initially the team agreed on having three evolutions; • A ‘Question forum’ that would keep track of however, following the first evolution this was cut to two specific questions posed by users during a due to unreasonable initial expectations. meeting, as well as responses given by the host The work activities allocated to individual team members were called Action Items (AI); all of which were noted in the relevant Meeting Minutes and were also entered into

Page 2 of 9 JMule team 3/8/2004 the team’s chosen project management tool, ‘DotProject’. semantic checks and ANT integration among other things, Dotproject [4] is an open source tool that allowed the it assisted greatly in coding and the team estimated that it Project Manager to delegate tasks to the rest of the team sped up development time considerably. The team as well as assign tasks to specific individuals. This tool utilized a plethora of the plug-ins available for the allowed the Project Manager to automatically produce program, allowing automatic code formatting (through Gantt charts as well as member specific ‘to-do’ lists. Jalopy [38]) and integration of IRC chat for team communications. 2.2 Quality Assurance Due to both the distributed development of jMule and the 3. INCEPTION high aspirations of the team, it was important that a The inception phase is concerned with deciding the aims process be established early on that ensured that the and requirements of the project through evaluation of the quality and consistency of team deliverables, both code research conducted [13], before considering the possible and documentation [5]. approaches that could be taken for the design. For documentation we decided to employ a peer review 3.1 Approaches approach, whereby every member of the team would For each major design decision, the team evaluated a review and comment on others documents, suggesting range of potential options, comparing the advantages and changes where necessary. The author of the document disadvantages of each before arriving at a justified would then take responsibility for integrating those decision on the best approach to use. changes, or raising discussion on any points of disagreement. 3.1.1 Peer to Peer – Client Server To ensure the quality of code we defined strict coding In the initial stages of the project, the team was faced standards based on Sun Microsystems’ java coding with the question of which overall architecture should be recommendations [6]. We utilized a tool called used for the jMule System, namely Peer to Peer or ‘checkstyle’ [7] to automate the creation of reports that Client-server. detail the number of standard violations each file If implemented using Peer to Peer (P2P) [14], it would be contains. In addition, we also defined a multifaceted possible to create a decentralized system that would testing procedure to ensure that code functioned according ensure that there would be no single point of failure. This to its specification. More details of this testing procedure could be implemented using a pre-existing P2P can be found in section 6. framework such as JXTA [15]. Disadvantages of this approach included unfamiliarity with the technology in 2.3 Configuration Management addition that the problem did not intuitively lend itself to Software Configuration Management was a key part of the P2P architecture. development process throughout the project. In contrast, a Client server model would be easier to design & develop, as well as making the system easier to Concurrent Versions System (CVS) [8] was used heavily integrate in to a corporate environment. throughout implementation and was configured to allow the control of binary documents in CVS as well as ASCII The downside of the client server model is that it doesn’t files. The versioning for source was maintained by the scale very well, as all traffic is directed at a single CVS, and the code tagged at the end of each evolution machine, and due to the high bandwidth nature of appropriately. Documentation was versioned manually, multimedia, the work required to be performed by the details of this and further configuration information can server would increase considerably with each new client be found in the Software Configuration Management connection. Document [9]. Despite this, it was decided that the Client-server model ANT [10] (Another Neat Tool) was another tool integrated would form the basis of our design, as it would enable us into the environment, used for the automation of build to concentrate on the applications functionality rather than tasks such as code compilation, test execution, document developing the underlying architecture. generation and packaging. All configured through a single 3.1.2 RMI – Sockets XML file, the tasks defined could be run on-demand as Once the team established that the system was going to well as overnight builds to enforce error-free source be build using a client-server model, a choice had to be control on the team. made about the specific remote communications For communication the team used an Internet Relay Chat mechanism. The prime candidates for this were raw (IRC) chat. Using the sponsor’s IRC chat server, an IRC Sockets and Remote Method Invocation (RMI) [16]. Both [11] channel was created and configured to record the have their advantages and disadvantages but in the context conversations that occurred. of a multimedia system where performance and absolute control over what was sent was what over control over the network is critical, The team used a highly customized version of an IDE Sockets were chosen over RMI [17] developed by IBM, [12]. With CVS integration,

Page 3 of 9 JMule team 3/8/2004

3.1.3 RTP Multicasting – Multi Unicasting (JPEG encoding is a widely used image compressed As the initial consideration for the media delivery mechanism). H263 is a video codec designed specifically mechanism, the technology of multicasting promised for video conferencing with very low bandwidth considerable advantages over alternatives. Since this utilization. The choice of video resolution, although infrastructure simply is not in place and one of the restricted with the use of H263, was affected by the requirements for jMule was for it to work over the results [21], where an exponentially increasing bandwidth internet, the approach was abandoned in favour of multi- requirements with video dimensions suggests the need for unicasting. [18]. a balance between reasonable perceptible quality and bandwidth usage. The H263 supported resolution of 3.2 Preliminary Work 172x144 was decided to be optimal, receiving a medium In order to prove the technical feasibility of some of the visual quality rating with very low bandwidth utilization. features of the system a number of throw-away prototypes were developed. An example of such a prototype was a 4. SYSTEM DESIGN simple media transmitter and receiver model, which was In order to successfully develop a software system, clear developed to test both the capturing facilities as well as specifications and component designs needed to be the network transmission capabilities. The tests proved defined to assist the developer through the successful, confirming the ability to stream media to implementation process. another client and showing promise for extension into multi-unicasting. Another media test prototype was also developed to research the multicasting capabilities of 4.1 Specification JMF. The initial prototype was successful, proving The purpose of the jMule server is to provide the multicasting worked on a single subnet. However, further conferencing services to multiple clients including, but investigation of the matter showed that the results are not limited to, the tracking of clients’ state and the highly variable depending on the network infrastructure forwarding of multimedia. The server supports multiple which led us to abandon the idea of multicasting. simultaneous meetings, both scheduled and unscheduled. 3.3 Mathematical Analysis The client provides an intuitive interface for the users to Mathematical analysis comparing a number of media interact with one another. The client software encapsulates codecs was conducted to find both the most suitable all the specified functionality as defined in the SRS [2]. stream encoding method and codec to use for audio and video transmission. 4.2 Top-level Architecture The overall architecture of the jMule system is built upon the concept of modular and abstract component design

mpegaudio/, 44.1kHz, 16-bit, Stereo [17, 24].

mpegaudio, 44.1.0kHz, 16-bit, Mono mpegaudio, 44.1kHz, 16-bit, Stereo The following diagram shows a layered view of both the mpegaudio, 22.050kHz, 16-bit, Mono client and server components. The layered approach to the mpegaudio, 48.0kHz, 16-bit, Mono system’s design allows for different implementations of ULAW, 8.0kHz, 8-bit, Mono the individual layers with no or minimal changes at the gsm, 8.0kHz, Mono interface boundaries. g723, 8.0kHz, Mono

dvi, 22,05kHz, 4-bit, Mono

dvi, 11.025kHz, 4-bit, Mono

dvi, 8.0kHz, 4-bit, Mono

0 100000 200000 300000 400000 Throughput (bytes)

Figure 1 - Raw throughput of audio codecs As shown in Figure 1, GSM [19] and G723 [20], two low bandwidth audio codecs, were the main contenders where bandwidth limitations were the primary concern. Further investigation [21] on the relative perceptible quality of these streams was carried out with the result of finding GSM to be the most advantageous option available. Figure 2. JMule Layered Architecture Other media related analyses included the encoding of the At the lowest layer, the Persistence layer, we have the video stream which yielded H263 [22] to be chosen over least abstract components of our architecture. This layer is the Joint Photographic Experts Group encoding. [23] responsible for storing the data and for exchanging the

Page 4 of 9 JMule team 3/8/2004 data between the server and the client(s). The components found at this layer are a database server, a file server for the storage controller abstraction, the multicast backbone, and the transport control protocol (TCP) for the network controller. Each one of these components represents a different way in which one can store and transfer data. Additional components could be added in this layer such as an in-memory cache that could be periodically triggered to save the data to a magnetic medium but this is out of scope for the jMule Project. One level above, at the Abstraction layer, we have the two major abstractions in our systems that take us from a traditional server to an object oriented server. Both the storage and network controller are responsible for providing the associated services to the layers above hiding all the implementation details from the callers. A component using the storage controller is not interested in Figure 3. Server Components Diagram where the actual data is stored but only that it can be stored, indexed and the retrieved using a clear interface. The Storage Controller is a key component for the server Similarly for the network controller what is important is as it provides a way for persisting information. It is used not how an event will reach each client but the fact that it by the Registration Management Website for creating has to reach them. For the purposes of the jMule system Planned Meetings, by the Media Server for saving the these components have been trivially implemented but a incoming streams and by the Session Handler for saving lot more functionality can be put into them like all the events that are exchanged within a meeting (used bandwidth optimizations of the network controller based for meeting playback). In the current implementation it on the load of the server, the number of clients currently uses a flat file structure where individual objects are connected and the nature of the data that is being serialized to and from files. Under stress, this component exchanged. has proved to be a bottleneck for the system which implies the need for some sort of caching internal to the The third layer of our architecture is the Business Logic controller instead of directly writing to the file system. Layer. This layer is essentially the integration layer where all components are tied in together using the information The Configuration Manager, as the name implies, is a coming from the layers below fulfilling the software common (server and client) component responsible for requirements for software. As this is the widest layer in holding all the runtime configuration properties that are our architecture, a lot of components have been left out of necessary for all the components. Instead of having the diagram or have been merged under more generic several different components all trying to access the same headings. The most important components in this layer properties files or locally extracting the same information are the configuration manager, the event router, the media this is done in one central place. When one component server and the session handler. More details on the server sees some new information that might be useful it saves and client components can be found in the next section. it in memory and all components can use that piece of information in the future. Finally, at the top of our layered architecture we have the presentation layer which is responsible for all the user 4.4 Client Components interactions and for presenting the information back to the user in an intuitive way. The current implementation of the system only uses the three technologies depicted. 4.3 Server Components The jMule server consists of a collection of interconnected components that are used for enabling individuals to participate in virtual meetings. The following diagram shows how these components are interconnected and relate to each other for providing the necessary facilities. A short discussion follows about two important server components but the reader is referred to the detailed documentation [39].

Figure 4. Client Components Diagram

Page 5 of 9 JMule team 3/8/2004

In the jMule client application, the Event Router is the In addition to Unit testing, the group also performed use centerpiece of the whole architecture. This is the case verification – Taking each use case individually in component that provides synchronous and asynchronous order to verify that the system performed as anticipated. event passing between the client and the server. The architecture defines that send operations are synchronous 6.2 User Evaluations and receive operations are asynchronous. Each component Part of the team’s testing strategy involved conducting can be either a sending or receiving component (or both) two usability tests, the first of which took place in the by realizing the appropriate interface. To fulfill the Gymnasium Kaiser Friedrich Ufer, Hamburg, Germany on interface’s contract the components need to implement the th the 18 February 2004 [29]. The testers were 11 students send() or receive() methods and add their own logic in between the ages of 17 to 18 taking A-level computing. them. Upon receipt of a new message, the delivery of the The second test took place at the University of Kent, message to the appropriate component(s) is performed via th Canterbury, on the 27 February 2004, and this time a component registration mechanism. Components involved 15 students of various fields of study in order to register interest in receiving messages of a particular type get a broader feedback about jMule [30]. and the system sends the messages back only to them. A larger scale design for the client could utilize the Java The scope of these tests was to see the operation of jMule Messaging Service (JMS) [25] but this was clearly out of in a “real world” environment. In addition, by testing it the project’s scope. with inexperienced users the team would get a different view of the application. The general feedback confirmed 5. IMPLEMENTATION that the application fulfilled the original usability As outlined in the project plan, both evolutions contained requirements, as almost all testers praised both jMule’s an implementation period during which the team appearance and its intuitiveness. implemented the system based on the architectural and design documents that were produced in the design phase. 6.3 Performance Measures Even though the phase progressed smoothly some Part of the team’s testing procedure was stress testing the obstacles were eventually encountered as anticipated. server and measuring its performance under normal and Many of the issues surrounded the media implementation. heavy use. The client machines were Dell Pentium 4 and The use of the Java Media Framework (JMF) proved the the server was a Dell Latitude D600 Laptop connected to most problematic part of the project due to the group’s the Universities 100mbit network. All machines were inexperience with the technology, the problematic nature equipped with 512mb RAM. The results of these of the technology and lack of formal education on the measurements are aggregated in figure 5. This diagram subject matter. The main problems discovered were shows the response time of a client measured in related to the Real Time Protocol (RTP) [36] streaming of milliseconds in relation to the number of clients and the JMF [26]. number of objects that are being exchanged during a meeting. After studying similar applications for extracting One example of such a problem was the inconsistent the usage patterns we concluded that around 1000 objects reporting of certain events which caused problems with are exchanged in a 2 hour meeting [31]. Based on this the event based media server. Solutions discovered were measurement the jMule Server can guarantee a linear to first remove all endpoints and then dispose the entire increase of response time in relation to the number of RTP Manager object each time a transmission was clients which is smaller than 150ms on average for 70 completed. Another problem is that of unimplemented clients participating in a single meeting on the server. processors for cloned DataSource objects extracted from RTP Streams. 400 350-400 350 6. TESTING 300-350

In order to prove that a system operates according to the 300 250-300 specifications a clear and thought through testing plan 250 200-250 needs to be laid out. 200 150-200 100-150 6.1 Approaches 150 50-100

As mentioned previously, in order to ensure that code Response Time (ms) 100 0-50 functioned as specified, we approached testing from a 50 variety of angles. By utilizing the jUnit testing 5000 0 3000 framework [27], we wrote unit tests wherever feasibly 5 10 20 30 Objects Sent possible. Due to the fact that the validity of most classes Number of40 Clients50 1000 60 70 in the GUI relied on verifying some visual stimuli, unit testing was primarily undertaken on the server [28].

Page 6 of 9 JMule team 3/8/2004

Figure 5 - Server Response Time in relation to Basic observation of a running client has confirmed Number of Clients and Objects Sent. suspicions that there exist problems with the system’s The performance of the media server was tested with utilisation of resources. The team acknowledges that both increasing numbers of streams, recording the bandwidth memory footprint and bandwidth consumption would and CPU usage as the number of streams varied. Figure 6 benefit from optimisation, however, investigation of these shows the change in bandwidth usage; the changes were issues would require additional time and tools that were reflected similarly in the CPU utilization graph. The not available. results show a linear increase in bandwidth use, Further to the aforementioned issues, one of the biggest successfully retransmitting video (600 streams) before the the team is aware of is the performance of the Storage curve begins to plateau. The video streams being Controller on the jMule Server. Testing of the system retransmitted were also of equal quality up until this revealed that the storage controller was forming a point, above the 600-650 mark there was quite communications bottleneck resulting in low response degradation in quality and by 700 the stream was no times for all connected clients. A possible solution to this longer good enough for use in a video conference. problem would be caching the events and persisting them periodically.

7. FUTURE ENHANCEMENTS Throughout the developing process the ideas for enhancement were unstoppable but limited through time the team was not able to address any of them. 7.1 Directory & Calendar Server Integration Most corporate environments maintain a central repository of employee information, most commonly in the form of Figure 6 - Increase in bandwidth use with number of a Directory Server (e.g. Sun Java System Directory Server streams [40]). Integration of the Sun Java System Calendar Server would lend jMule far more to an enterprise market, Taking into consideration the projected capacity exhibited improving potential for deployment in a corporate in the mathematical analyses and the findings of the stress network. Since the S1 Calendar Server also hooks into testing we can extrapolate the results to make estimated the S1 Directory Server, integration of authentication projections for varying bandwidth connections. The would be achieved at both levels. Further work with the figures in Figure 7 take into account the effects discovered Calendar integration could allow the jMule client in the stress testing and the unpredictable nature of non application users to have control over their calendar and LAN connections. Real world scenarios may prove up to enable them to schedule meetings through the application. the theoretical capability limits or perhaps lower than the estimates. 7.2 Voice over IP (VoIP) Maximum Number of Channels Bandwidth VoIP (or voice over IP) is a technology that facilitates the Theoretical Estimated placing telephone calls over the internet, allowing you to 56.6 Kb 1 (Audio only) 1 (Audio only) make telephone calls for free irrespective of distance or 512 Kbps 5 2-3 time of day [33]. Traditionally this connectivity was achieved through the use of custom software, but 10 Mbps 115 80 hardware devices such as IP phones and gateways are now 100 Mbps 1163 600 starting to appear on the market, serving to expedite its Figure 7 – Media server capability adoption. The opportunities that this presents to the development of 6.4 Known Issues jMule are twofold. Firstly, by utilizing any existing VoIP Following the testing procedures, and subsequent bug infrastructure that may exist, it is possible to offload the fixes, the team are aware of an ongoing number of issues computation required to facilitate voice communications with the system. to dedicated hardware – Reducing the size and complexity of the client. Secondly it would most likely increase the The user testing revealed that the continuous drawing on quality of the audio as well as reducing the lag due to the the whiteboard by a single participant could render the fact that specialized hardware is better equipped to more jMule client unresponsive for participants in the same quickly and efficiently compress and decompress the meeting [32]. audio streams.

Page 7 of 9 JMule team 3/8/2004 jMule could tie in perfectly to a VoIP enabled In conclusion, the team consider jMule to be an enormous infrastructure, enabling a discussion to take place among success both in terms of meeting the original goals, and all participants of a meeting in real time, while the quality of the finished product. Although we hope simultaneously collaborating through the jMule client. that we’ve taken the donkey work out of remote For users with dedicated VoIP hardware the voice would collaboration – We had to put it in first. be independently routed, but falling back to software should VoIP facilities be unavailable. 9. ACKNOWLEDGEMENTS We would like to thank Dr. Peter Kenny for his continued 7.3 Multicasting support and direction throughout the lifecycle of the As already discussed, multicasting was considered as a project, and Dr. John. Crawford of the Kent University possible approach but was discarded during the research Computing Laboratory for the initial discussion on phase. Allowing for future internet development and the Multicasting, as well as providing us with direction for widespread adoption of multicast capable routers on the further resources. Thanks also to the System internet, it is feasible, and indeed probable, that Administration team at Kent University, whose patient multicasting will become a legitimate possibility for but efficient nature ensured that we never hit a technical implementation [34]. Figure 8 shows a possible dead end. We would also like to thank both the multicast implementation of the jMule system. Streaming and JMF working group at Sun Microsystems for the regular assistance with our JMF technicalities. Media Unicast to Server Last but not least, we would like to thank our girlfriends, whose tolerance, understanding, and support took the IP Multicast Client A Network jMuleServer edge off the 3am programming sessions and 9am starts. 12.4.10.210 129.12.5.240 224.1.1.0 10. REFERENCES

Client B [1] H. Ricklefs, “Project Description Document”, 129.12.5.230 Project jMule Documentation, University of Kent, October 2003 [2] I. Baltopoulos, “Software Requirements TCP Socket Connection to Clients Specification”, Project jMule Documentation, University of Kent, October 2003 Figure 8 – Media server capability [3] I. Somerville “Software Engineering”, Addison Application Layer Multicasting (ALM) would provide an Wesley intermediary solution to the problems of multicasting. This approach would consist of making every client on [4] DotProject Home page the network act as both a media client (receiving media http://www.dotproject.net/ from another client) and a media server (transmitting the [5] N. Saunders, “Software Quality Assurance Plan”, media they receive to one or more other clients). Using a Project jMule Documentation, University of Kent, well formulated media control protocol, the transmitter October 2003 and receiver could result in a more efficient operation for [6] Code Conventions for the Java Programming all the peers. Application Layer Multicasting could also Language http://java.sun.com/docs/codeconv be used in conjunction with the entire peer-to-peer alternative, but the design and implementation details of [7] Checkstyle Homepage this are beyond the scope of this document [35]. http://checkstyle.sourceforge.net/ [8] Concurrent Versions System 8. CONCLUSION http://www.cvshome.org/ When compared to other similar products, it is fair to say [9] R.Kilpatrick, “Software Configuration Management that while jMule has some unfinished edges, it presents Plan”, Project jMule Documentation, University of an extendable platform on which to build an enterprise Kent, October 2003 strength application. By providing hooks by which the application could be extended, we ensured that jMule’s [10] ANT FAQ potential for expansion was not limited. http://ant.apache.org/faq ] As previously stated, whist the lifecycle of the project [11] What is IRC? was not without problems, the project progressed at a http://www.mirc.com/irc.html constantly efficient pace. While some may say this was [12] Eclipse Homepage due to being driven by a German project manager, the http://www.eclipse.org/ team agree that it was more accurately attributed to the respect between the team members, as well as the [13] R. Kilpatrick, “Research Evaluation”, Project jMule confidence in each others abilities. Documentation, University of Kent, October 2003

Page 8 of 9 JMule team 3/8/2004

[14] “What is peer to peer architecture?”, [33]Robert Jaques, “VoIP plugs into strong growth”, http://www.webopedia.com/TERM/p/peer_to_peer_ar vnunet.com, February 2004 chitecture.html [34]RFC 1112 - Host extensions for IP multicasting [15] JXTA Homepage http://www.faqs.org/rfcs/rfc1112.html jxta.org, http://www.jxta.org/ [35] N. Saunders, “Future Enhacements”, Project jMule [16] Sun Microsystems’, “Java Remote Method Documentation, University of Kent, February 2004 Invocation (Java RMI) “, [36] About RTP and Audio-Video http://java.sun.com/products/jdk/rmi/ http://www.cs.columbia.edu/~hgs/rtp/ [17] I. Baltopoulos, “Software Design Description” [37] Microsoft’s Placeware Acquisition Project jMule Documentation, University of Kent, http://www.directionsonmicrosoft.com/sample/DOMI October 2003 S/update/2003/03mar/0303amcsf.htm [18] R. Kilpatrick, “Multicast Unicast Research”, Project [38] http://jalopy.sourceforge.net/ jMule Documentation, University of Kent, November 2003 [39] I. Baltopoulos, “Software Design Description”, Project jMule Documentation, University of Kent, [19] http://www- October 2003 mobile.ecs.soton.ac.uk/speech_codecs/standards/gsm.

html [40] http://wwws.sun.com/software/products/directory_srv r/home_directory.html [20] http://www.siggraph.org/education/materials/HyperGr

aph/video/codecs/G723.html [41] http://wwws.sun.com/software/products/calendar_srvr /home_calendar.html [21] R. Kilpatrick, “Media Stress & Quality Testing”, Project jMule Documentation, University of Kent, February 2004 [22] http://www.siggraph.org/education/materials/HyperGr aph/video/codecs/H263.html [23] JPEG Committee http://www.jpeg.org/ [24] I. Baltopoulos, “Functional Specification”, Project jMule Documentation, University of Kent, October 2003 [25] Java Messaging Service http://java.sun.com/products/jms [26] R. Kilpatrick, “JMF Research and Issues”, Project jMule Documentation, University of Kent, January 2004 [27] JUnit Testing Resources http://www.junit.org [28] N. Saunders, “Unit Testing Results”, Project jMule Documentation, University of Kent, February 2004 [29] H. Ricklefs, “Usability Testing Report 1”, Project jMule Documentation, University of Kent, February 2004 [30] H. Ricklefs, “Usability Testing Report 2”, Project jMule Documentation, University of Kent, February 2004 [31] I. Baltopoulos, “Stress Testing Report”, Project jMule Documentation, University of Kent, February 2004 [32] H. Ricklefs, “Known Issues Bug Report”, Project jMule Documentation, University of Kent, February 2004

Page 9 of 9