université d'ottawa universi@ of ottawaacknowledgments 1 would iike to sincerely thank my...
TRANSCRIPT
Université d'Ottawa Universi@ of Ottawa
JETS: DESIGN AND IMPLEMENTATION
OF A JAVA-ENABLED TELELEARNING SY STEM
by
Shervin Shinaohammadi, B ASC.
A thesis submined to the School of Graduate Studies and Researcti
in panial fulfillment of the requirements for the degree of -
Master of AppIied Science in
Elecuicai Engineering
Omwa-Carleton Institute for Electrical Engineering
Department of Electncal Engineering Faculty of Engineering University of Ottawa
O Shervin Shimoharnmadi, Ottawa, Canada, 1996
National Library B~Wdhbque naûionale du Canada
Acguisitions and Acquisitions et Bibliogaphic Services senrias bibliographiques
The author has granted a non- exclusive licence dowing the National Library of Canada to reproduce, loan, disbribute or seli copies of M e r thesis by any means and in any farm or format, making this thesis avdable to interested persons.
The author re- ownership of the copyright in M e r thesis. Neither the thesis nor substantial extracts f?om it may be printed or otherwise reproduced with the author's permission.
L'auteur a accordé une licence non exclusive parnettant a h Bibliothèque nationale mi Canada de reproduire, prêter, distn'buer ou vendredescopiesdesathésede quelque manière et sous quelque foane que ce soit pour mettre des exemplaires de cette thèse à la disposition des personnes intéressées.
L'auteur conserve la propriété du droit d'auteur qui protège sa thèse. Ni la thèse ai des extraits substantieis de celle-ci ne doivent être imprimés ou autrement reproduits sans son autorisation.
Abstract
Teleleamhg systems, in which students and instnictors share mdtiraedia documents in real
tirne, have been a subject of interest for many years. Recent advanceraents in the Internet
technoiogy such as the enaergence of Java-enabled browsers, VRMI, Active X, and
simiIar technologies have provideci users with access to dynamic multimedia content and
appiications on the WorM Wide Web. One seems to be justined to take advantage of these
available and widely-used technologies for today's interactive systems such as telekaniing
environments, in this thesis, a platfom-independent, generic, client-semer mode1 for
multi-user/cohborative applications through the Internet with emphasis on teIeIeaming is
proposed. The approach used to design the system ensum the operability and
compatibility of the system with existing technologies and guaranties its accessibility by
the majority of Internet users.
Acknowledgments
1 would Iike to sincerely thank my research supervisor and profkssor, Dr. Nicolas D.
Georganas, for a nurnber of reasons. First, for assigning to me such interesthg and
challenging research topic; namely teleleaniing. Second for giving me the opportunky to
experirnent with Merent leading edge software and hardware technologies, such as
VRML, lava, SUN Uitra, and so on. F d y , for his motivation, guidance, experience. and
encouragement which were the most important façtors that helped me e h my M.kSC.
program in four consecutive semestes.
1 would aIso Wre to acknowledge the support and sponsotship of the Telelearning
Research Network of Centers of Excellence who provided the necessary fun& for this
project, as weil as the Ontario Graduate Scholarship Program for granting me an OGS
scholarship for 1996/97-
Last, but dennitely not least, 1 want to thank my parents for their constant support and
encouragement, specially my mother who talked me into studying at the graduate leveL
Without their careful and long tecm planning, this whole thing wodd never had happeneci.
2.1 VLRTUAL REALJTY ................*.......... ............. ....... .... .... *~-.~.........~C................~......C-......*......oCC~........ 16
R e g ........o. . . . . . . . . ............................................................................................. 19
Perception StaJtdardr .......... .....,.. ......... . ........................................ . ............... . . 19
Newrking ...................................... ~t.....~..~.................................. . .......o....................... 19
Scnpting h g u a g e .,...,,... ,., ...... .......CC..C~C~...~~ .*... **.o......-..............*.........* .... ............................ 20
2.2 VRML (VIRTUAL REAUW MODEUNG LANGUAGE) ..+........ ........ ............. ............ ...... 20
2-21 Introduction ...... . ............*........ . ....... .... ................-. ..*..*......-........* .... .. .... ......* .... .........* . . . . 20
2.2.2 O .......... . . . . . .......................................................................... 21
22.3 W L Speciftcationx Defining Virtual Workis ....,,.-...........at... .... ....................................... 22
2.2.4 VRML Tools .............. . ...................................... - . . . . . . . ............ ............. 24
2.2.5 Moving WorIds: VRML 2.0., ....... ,.,......,.,,...I,.~...t~~........C.CC.........*.~......... .............. ........... . 26
CEAPTER 3 . JAVA: APFLICATLONS TBROUGE THE WORLD WIDE WEB,. .....-.. ...... ...... 27
3.1 I~JTRODUCI~ON* ........................................................................................................................... 27
.............................................................................................................. 3.2 JAVA AND ITS -'TCIRES 31
3.2. I WIiClt IS Jima?. ...................................................................................................................... 31
3.2.2 Some Advmced Feotures of Java ................... -....... ......................................................... 33
3.3 APPLE~S AND THEIR RESTRI~ONS ....................... ............-. ......................................................... 38
............................................................................................................ 4.1 GENERALSPECIFICATIONS 41
........................................................................................................... 4.2 PROPOSED AR=- 44
4.2. I Luyout .................................................................................................................................. 45
4.2.2 Operation ............................................................................................................................. 48
4.3 SUMMARY ............~~~~................................................................................................................... 61
................................................................................................................................... 5.1.2 Client 67
5-2 JETS PROTOTYPE.^..^^..^..^......... ....................................................*.............................................. 68
5.2.1 Char ..................................................................................................................................... 69
5.2.2 Shured HîML Documents .................. ................ ........ ... . 70
5.2.3 Whitebmrd .......................................................................................................................... 71
5.2.4 VRMt viewer ........ ....................................... .............................................................. 72
5.2.5 The client Interface ................... ., ........................................................................................ 75
CaAPTER 6 . PERFORMANCE EVGLUATION".o.œ ..~m~~om.oooœ.o~.~ooooooooœ.œoo~.~m*o.o~oo.o~oooooo ..omooooo.moœ.o 77
APPENDM A: aTML CODE FOR TEE BROWSER ...-.......... .......... 93
APPENDMB: ......... .. ....... .. .............. .. ..... ....... .. ...................................................... - ............ 95
JAVA AND CODE OF TEE CCD TEST APPLET ..---.-.--- .................................. 95
.......................................................................................................................................... Reciever 96
TestSemer ................................................................................................................................... 97
B2 . HTMLCODE .............................................................................................................................. 98
sender.htm1 ..................................................................................................................................... 98
receiver . hrml .................................................................................................................................. 98
List of Figures
F [ G ~ 1 . A UASSLOOM ............................................................ ............................................. 9
FIGUREZ V ~ T U U R E A U ~ ~ U I P M E K C . ............................................. .............................................. 17
................................................................................................... FIGURE^. ANEXAMEXE~D 2 2
R G U R E ~ . VIEWGENEWIED FROMTHESCENE IN FIGURE1 BY A BRQWSER ................................................. 23
FIGURE 5 . S N A ~ S H O T O F ~ ~ E VRWm BROWSER .................................. ........................... ................... 24 F I G ~ ~ . SNAPSHOTOF A MODELER ................................................................................................. 25
....................... FIGURE 7 . ~ H A N G I N G INFORMAïiON THROUGH NETWORK SOCKETS: SERVER OPERATIONS 36
FIGURE 8 . EXCHANGING ENFORMATION THROUGH NETWORK SOCKEIS: CLIENT OPERATIONS ....................... 37
FIGURE9 . DIAGRAM UF'MESERVER .................................................................................. - 4 5
........................................................................................... FIGURE 10 . S m MON~LDRING INTERFA CE. 46
FIGURE 11 . CON-IEJCTDIAGRAM OF mCL[EEPT .................... .. ....................................................... 4 7
FIGURE 12 . ~ T i O N AU'T0MAnCALLY PERFORMED BY THE CLIENT .................................. 48
FIGURE 13 . OPERATION OF THE SERWX ................................................................................................. 53
....................................................................................................... FIGURE 14 . DATASERVER OPERATION 54
...................................................................................... FIGURE 15 . AN EXAMKE OF MESSAGE ~~LLISION 56
FIGURE 16 . OPTIONAL GUI INIERFACE OF THE S E R m FOR MONMURING CLCENTS ...........,....... .............. 57
FIGURE 17 . SIGNALSERVER @E%ATION .................................................................................................... 58
FIGURE 18 . ~TLWZATION OPERAnON AS m R M E D BY THSSERVER ............................................... 59
FIGURE 19 . ODP ENGINEERWG MO= OF THETELE-LEARNING S m ............................................ 6 3
FIGURE 20 . THE CHAT APPLET ............................................................................................................ 69
FIGURE^^. THEURLAPPLET ................................................................................................................... 70
Rem22 . T H E ~ O A R D ~ ...................................................................................................... 71
FIGURE 23 . THE VRML V~EWERAPPLET ................................................................................................... 72
FIGURE 24 . A SAMKE THE-LEARNING SESSION RUNNING [N m NETSCAPE BROWSER ............................... 75
FIGURE 25 . FRAME HiERARCHY OF THE HThfL DocüMENTS ...................................................................... 76
....................................... FIGURE 26. LOCAL BEiWORK C O N F I G ~ T i O N OFTHE QiENTS AND THE SERVER 80
................................................................................................................. FIGURE 27. UYOUT 81
......................................................................................... FIGURE 28 . PING ~ M E I Enmumr VS- ATM 82
List of Tables
TABLE 1 . BUILT-IN PA- ~RTHECLIEIUTMSS .......................................................................... 51
TABLE 2 . B m~-EN SIGNALING OP THE SIGNA~SERVER C~ASS ......................... - ..................... . 5 6
TABLE 3 . SERVER COMPONPFIS ................................................................................................... . 61
TABLE 4 . CLENTUAS COMPONPITS ..................................................... .......................................... 62
................................................................... TABLE 5 . MESSAGING SCHEME OF THE W ~ O A R D 71
TABLE^. MESAGMGSCHEMEOFTHEVRMLAPPLE~ .............................................................................. 74
........................................................................ TABLE 7 . CCD IEST RESU~TS WR DEFFERENT NG~WORKS 82
.................................. .......*...........*............ TABLE 8 . SOMEQOS PARMEERS PUBUSHED BY ...... 83
List of Abbreviations
AAL: ATM Adaptation Layer
ATM: Asynchronous T d e r Mode
CCD: Client-toclient Delay
CTA: Common Training Architecture
DELTA: Developing European Learning Thr~ugh Technological Advance
ECOLE: European Collaborative Open Leamhg Environment
DSD: Delay Sensitive Data
GUI: Graphical User Interface
HTMt: Hyper Text Markup Language
VO: Input 1 Output
IP: Intemet Protocol
WC: Inter-Process Communication
JDK: Java Development Kit
JETS: lava-Enabled Teleleamhg System
Just-In-Time (cornpilers)
LAN: Local Arta Network
MIME: Multipurpose intemet Mail Extensions
MMCF: Multimedia Communications Forum
OCRhet: Ottawa-Carlton Reseacch Institute network
ODP: Open Distributed Processing
OISE: Ontario Institue for Studies on Education
QoS: Quality of
RMI: Remote Method Invocation
TL-NCE: TeleLeaming Network of Centers of Excellence
URL: Universai Resource Locator
VR: VirtuaI ReaIity
VKML: Viaual Reality Modeling Language
Conventions Used in the Thesis
Courier New Font:
standard (core) Java packages and classes;
standard Java methods; methods end with O, e.g, run ( 1.
Bold:
some tities;
Java classes or methods of the tele-learning system, when they are fmt introduced.
Italic:
new terrns wherie they are first defmed-
Chapter 1. Introduction
Tele-1e-g has been a subject of interest for many years. The idea of a virttral classroom
where students aad instmctors shve multhda material fiom their cornputers without
king actuaüy p ~ s e a t at the same location is a vwy appealirig subject for research, Figure
1 depicts a simplistic repmentation of a viaual class-roorn.
Figure 1. A virtual classfoom
As one can see, the idea here is to share multimedia documents as weU as to see and speak
to other participants. Up until now, the progress in the development of such virtud
classroom has been limited rnainly by the lack d the foiiowing factors:
high speed networks;
powerful workstations for ordinary users;
network access for ordinary users;
a standard interface for presenting multimedia matexid;
a standard for multiuser applications.
Some of these probkms are not as significant as they used to be a few years ago.
Workstations today are qaite powerfiil and affordable for ordinary users. h o recently,
companies and organizations known as Internet providers are o f f e ~ g affordable netwodr
access for households. As a cesult of both affordable powecful workstations and network
access, the number of users joinhg the Web commWUty is increasing at a uemendous rate.
It is anticipated that Inteniet access wili be part of the standard utiJities of a household. as
are electricity, water, cable television, and telephone.
These improvements in technoi~gy have stimuiated significant global activity on tele-
leanùng over high-speed networks. The European Commission, for example. has a
strategic research and devdopment program caiied DELTA (Developing European
Learning Through Technological Advance). that involves major industrial and govenunent
organizations. Two main pro@& in DELTA are the CTA (Common Training
Architecture) and ECOLE (European Coiiaborative Open Leamhg Environment) [2d.
These projects involve both field trials, multimedia tool development, multimedia
communication platfoms and tec hnical and administrative coordination.
In Canada, OCRhet, sponsored by the Ottawa Carleton Research Institute (OCiU) and
industry, is the fïrst wide-area ATM (Asynchronous Traiisfer Mode) broadband test bed
[3]. It launched its operations in Ottawa on January 1994, with a coUborative work
application over video coderencing, between BNR and the Multimedia Communications
Research Laboratory (MCRLab) at the university of Ottawa. In addition to its high-speed
networking, OCRInet currently links 12 industrial. goverment Iabs, and academic sites in
the Ottawa area. This maires OCRInet the perfect set-up for research about knowledge
sharing, distance edwation, tek-kamhg, coilaborative wodc, as well as a test bed for
running and evaluatmg tbe performance of high-speed muItimedia coi~~~~~unications
applications, such as the iiesearcb project of the TekLeamhg Network of Centers of
Excelience m-NCE).
TL-NCE repments an unprecedented collection of Canadian mearchers and the potential
for remarkable advances in Canadian education and training. The goal is to brhg
cornputer-supported environments, artincial intelligence, high-performance networks,
multimedia and collaborative tools into coherent systems- TeleLeanung, which makes use
of multimedia leaming environments based on cornputers linked by the information high-
way, is a technology and a social innovation of fundamentai importance for education and
training at aii levels in a knowgedge-based, leamhg society. T e l e M g extends access
and brings high quality education to aLl citizens, regardlas of their location, age, or status.
The startuig point for the TL-NCE ~esearch is a number of Canadian beacon technologies:
TeleCSILE, a wide-area system b d t around a hypennedia database constructed by the
Ontario Institute for Studies on Education (OISE);
MRTUAL-U, a networked multimedia environment specincaily custornized for
educational açtivities and course delivery with kld tests mnning at universities and
workplace education sites across Canada;
TELEFORM. a set of tools for delivery of TeieLearning in the workplace and at home.
Work at he LICEF iaboratory of Quebec's Teie-universite is complemented by
technologies resuiting fio m Ontario's Telepcesence project and research at the
University of Ottawa MCRLab to provide coherent karning environments for
workspace;
CADRE, a set of design and autboring tools and rnethodology on work at the
Universities of Gueif and Waterloo, the WCEF laboratory at Tek-uivversit6, intelligent
tutoring work at U~versité de Montreai, University of Saskatchewan and Alberta
Research Council.
The responsibility of the MCRLab is TGNCE sub-pmject 6.1.5: WMultimedia Tek-
learning over ATM Networks : architectures, application development, expehents and
performance evaiuation over OCiUnet and CANARIE". This project is lead by Dr.
Nicolas Georganas with Dm. Dan lonescu and E d Petriu as principal investigators. The
6rst client group will be Professors J- Houseman and A. Morin, department of biology,
University of Ottawa and their students, They have deveIoped a multimedia course
application in Zoology, which we intend to enhance with 3D ob@ts and the ability to
btuwse and manipulate those objects using 3D and V i a 1 Reality toois. Eventually,
participants in tbat course wiü be able to s h m 3D objects and course material as in a
mal chsroom.
The goal of the reseatch for this specific ttiesis is the design and Unpkmentation of
multimedia collaborative tele-learning appkations over high-speed networks. in other
words, a virtual ciassrnom must be created where users from distant locations can access
and coUaboratively share various appiications incorporating different media such as image,
text, and 3D objects in real thne. The ernphasis in this research is on shared browsing and
manipulation of 3-D abjects, as WU as sharing a 'W&board", documents containhg text
and images, and a means of sending textual messages. The video and audio-conferencing
aspect of a Wtual classroom wii l not be covered in this research since they are beyond the
scope of this thesis. Live vide0 and aodio-conferencing is a separate research issue on its
own and is king tackied by many cesearches and organizations in that field.
It is important to d i z e that because of the pmject's nature w k h de& with leanimg and
education, it is exuemely important that the ~ t ~ c t u r e of the system be designed in a
way that makes it accessible for everybod~ a teacher at school with an IBM cornputer,
students at home with PC's and Macintoshes, a supervisor at an organization with SUN
Station or Silicon Grapfiics station, and so oa This creates a problem right fiom the
beginning:
Since the education community, including students, teachers, instnictors, professors, as
well as private or funded ducational organizations, is very large, the use of a specinc
operating system or platform should be avoided. It would be untealistic to assume that ail
of these users will migrate to a specioc plagom just to use our tele-leamhg system.
Therefore, it immediately becornes apparent that the tele-ieaming system must be
platformindependent at least at the user's end.
In addition to being pladomindependent, the design and implementation of the
architectures and applications must be compatible and interoperable with the current
existing technologies and infiastructure. Adhecence to standards is very important for a
tele-learning system since it will fùrther ensure that the system can communicate to as
many people as possible. The standards of interest to this research are standards for:
networking;
3D object representation;
interface for presentîng mdtimedia material ;
virtual classroom en* for rnuitiuser applications.
In ternis of netwod0ng. the chob seems to be clear: the Intemet. As mentioried earlier,
the Intemet, which utiüzes IP as its netwodciag protocol, is pwing at a tremendous rate.
It is now possible for the average person to obtain connection to the Intemet at a
reasonabk cost; although not at a satisfactory network speed to deliver multimedia
content in real t h e . However, both the cost and the netwoik speed are improving rapidly
as technologies imptove in that field. For example, ATM promises to deliver multimedia
content at a given quaLity of service, including high bit-rate and low loss-rate. The high bit-
rate of ATM, which c m be in the range of gigabits per second, will facilitate the transfer
of broadband traffic.
It is worth mentioning though. that ATM technology itself does not have a netwodcing
protocol simüar to IP. Furthemore. in order to be successfùl, ATM must also adhere to
the already established and widely used network standards; which is IP in this case. That's
why in the practiçal implementations of ATM, the user stations still nin IP as their
network protocol and the IP to ATM translation is perfomed by ATM ARPI. This is also
how the OCRInet is impiementeci 1171. In some cases, even the data-link and the physical
iayers are implemented by some legacy LAN like Ethemet or Token Ring. In this case the
transition h m LAN to ATM is p e r f o d at a speciai ATM switch that acts as a
gateway. In any case. IP has weii established iiselfas the default networking protocol and
that's why it was chosen for this project.
l Addms Rcsolution Rotood (ARP) is a protocol that translates addresses fmm one standard to ihc other. For enample, when an application requests to send data to IP address 137.122.20-163, ihe ARP iafonns the underiyïng ATM aetwork to use VPIVC LI203 to deiivei. that &ta.
The other chree standards mentioned above wiii be discussed in this thesis. Chapter 2 will
briefly htroduce VRML, the &-facto standard for 3D object representation on the
internet, with a short discussion on virtoal teality standards; while chapter 3 will present
Java, a new approach to programming for the Intemet. Chapter 4 discusses the design of
the tele-leamïng software engine inclnding the generic client-semer modeL Chapter 5
presents the implementation of some sample applications including a 3D object viewer,
chapter 6 contains the pecfWmnce evaluation of the system, and chapter 7 condudes the
thesis.
The work in this thesis contains some original contributions including:
design and creation of a platform-in&pen&nt, d - t h e coiiaborative environment;
design and impIementation of a generic cknt-semer mode1 for shared, real-time
applications through the Inteniet;
creauon of generic Java classes that fom the idkastructure of any collaborative
environment and can be extendd to hplement speçifiç client-semer applications;
implementation of a working prototype of the system.
There is one research presentation resulting from this thesis: "JETS: A Java-Enabled
Telelearning System" which was presentd at the 1996 TeleLeamhg Research Network
Conference held on November 5-7, 1996 in Montreai, Quebec. In addition, the prototype
of the JETS systern was exhiibited in a demo session at the same conference as weii as in
the 1996 GASCON Contérence held on November 12-14, 1996 in Toronto, Ontario. A
paper was also subrnitted at the 1997 IEEE International Conference on Multimedia
Computing and Systems t~ be held on Iune 2-6 in Ottawa, Canada.
Chapter 2 VRM L: Virtual Reality Standard for the lntemet
It was decided to incorporate 3D objects in the context of this project since these objects
are one of the most important media in tele-leamiug. A 3D object is not a picturc or image
but a thteedimensional cornputer generated representation of a real object that cm be
interacteci with as in the real wodd. It is the medium of interest to viaual rieality.
The Intemet standad for 3D object representation is the Virtual Reality Modehg
Language (VRML). In order to understand VRML, a concise discussion about wtual
reality itseif is inevitable. This is the purpose of the foiiowing section.
2.1 Virtml Reality
The basic goal of virtnal reality (VR} is to produce an environment that is indistinguishabie
Born reality in which certain things can be done or experienced- For example, a "virtuai
conference room" would be an enviconment where upon entering, one can see other
participants, interact with thern, and exchange information just as one would do in a real
conference room.
Viictual Reality is considered to be the ultimate goal of communications: to overcome the
distance barrier. When the teiephone was fkst invend, this goal was tealized for audio.
Similarly, tekvision overcame the distance barrkr for video. The dtunate objective is to
overcome the distance barcier no t just for audio and video but for di human perceptions:
vision, sound, touch, taste and srneil. In other words, communications must enable users
to feel as if they are physicaily present in a distant environment where in fact they are not.
This feeling of king physicaiiy -nt in some location is referred to as Victual Realicy.
The idea of Wtual reality may be considered to have been conceived by Van Sutherland
when he introduced the idea of expressing pictures in 3D fonn in 1965 and proposed the
use of "Heaà Mount Display" in 1968 [7]. A paper, pubkhed in 1972 by D.L. Vickers,
one of Sutherland's cokagues, describes an interactive cornputer graphics system utilizing
a head-mounted display and wand. The display, wom like a pair of eyegiasses, gives an
ïiiusion to the observer that helshe is surrounded by three-dimensionai, computer-
generated objects. The challenge of VR is to make those objects seem as reai as possiiie in
many aspects like appearance, behavior, and quality of iateraction between the objects and
the userlenvironment.
Complete immersion into a vittual reality environment requires the use of sophisticated
and expensive equipment such as special goggles, headgear, and gloves (see below
picture) [4]. This is one of the reasons that research and development in the field of VR
has not been too impressive.
Figure 2. Vial Reality Equipmeat
17
However, recent efforts have brought virtuai reality to ~~'duiary desktop cornputers,
dowing users to use a typical simple mouse to intetact with the 3D world on their screer
This simplistic approach has boosted up the development of various VR ôased applications
on the Internet and bas resdted in rapid development in the 6eld of VR. Consequently.
VR has started to become avaiiabk to general Interner users. Jost wiihin the last year, we
witnessed the ernergence of simple 3D browsers leadmg to more sophistkated VR
applications such as Quickïïme VR and RedW Trmeler.
QuickTime VR is a viftual d t y sofkare based upon Apple's QuickTime Technology.
QuickTime Vt( allows interaction with panoramas and object moviesz [19].
RealVR Traveler, Erom RealSpace Inc.. is a virtua.1 reality player that combines panoramie
viewing with VRML rendering, compositing aad URL ünLing. Resembiing QuickTime
VR, the RealVR Traveiec shows photographie panoramas with sprites and VRML objects
moving around within the panoramas [20].
Both of the above appkations are currently avaikble as a plug-in for Netscape Navigator
on the Power Macintosh and Windows 9S/NT,
The other problern in the kL1 of VR has been the fact that everybody was working on it
hdependently. Since too many people independently wocked on it, they all had their own
ideas on how things shouid be done; therefore. everyone did t dinerenty and too many
standards appeared. Today, however, the VR community joined by the lnternet is working
together to corne up with very few VI2 standards. Evennially, one or two main standards
will emerge that wiiî be accepted by the ma.rity. The successfpl standard must cover al l
of the foiiowing issues in an efficient manner:
- --
Panoramas and object moviu are scenes in which the user can look in aimai any direction.
18
Rendering
This is the interfàce to the user. the graphical way in which the v i r t d environment3 is
presented to the user, A successfiil VR hnguage must de& a weU-defineci rendering
system.
Perception Standards
The main area of concem for a VR standard is perception; after ali, perception is what
rnakes the real worid so ceal, Therefore, a VR language has to deai with the foiiowing
perceptions:
Tou&: This occurs when two objects "coUide". Souad: When two objects are aware that they are in the same environment, they can produce sounds detectable by each other. Sound can be sent (taiicing) or received (hearing). Vision: An object in the same environment as other objects is able to render itseif to othet objects in order to produce views of itself. SmeIi: Cutrently, an appropriate hardware technology for producing smells doesn't exist nor is there an ùnniediate need for such technology at the present; however, provisions for smeli must also be made in a VR standard. Taste: Wre srneil, there is no immediate need for this perception; however, in the future, VR systems must carry smeil and taste to M y support the idea of virtuai reality.
Networking
Networking is also a very important issue in virtual reaiity. There must be a way for the
objects in a virtual environment to utüize the underiying networking protocols to exchange
information with remote objets; furthemore, the environment itseif must be able to fetch
remote objeçts.
- -
A vimial environment is a 3D e n v i m e n t chat contains objects of different media types includiog oiher 3 0 environments or 3D objects .
Scripting Language
There is an absolute need for a scripting language in order for the standard to be genecic.
A Scripthg language is ased to describe specinc properties such as:
Behaviot: Components of a Wtual wockl shodd be able to demonstrate behavior on their
own or in response to a user interaction. Foc example, a fish in an aquarium must be able
to swim by itself as weil as swùn away h m a user who is knocking on the aquarium's
glass.
Synchronization: In a disui'buted system, it is ditlîcult to make sure that everything that is
supposed to happen synchronously does so. Fknce, the= is a need to specify scenarios in
a VR standard.
Multi-Participation: One of the most important issues of virtual reality is how to dïow a
virtual world to be shared by many users at the same tirne. Multi-user support requires
support for access control and consistency.
Next, we will see how VRML addresses these issues.
2.2 VRML (Wrtual Reaiity Modeling Lringuags)
2.2.1 Introduction
VRML is the most widely accepted standard for virtual reality on the internet, Mark
Pace, one of the creators of VRML, describes it as follows:
"The Virtual Reality Modeling Language is a language for describing multi-participant
interactive virtual worids co~ec ted via the global Intenrec, AU aspects of virtuai world
display, interaction and inter-networking can be speçified using VRML,." [15]
Simüar to the Hypex Text Marhip Language (HIML), which is a language for the World
Wide Web text documents, the Vimial Reaüty Modehg Language is a m a g e for
virtual worlds. VRML was developed as an anmer to the pmblem of a VR interfhce to
WWW. The foiiowbg is a brief histoty of VRML.
2.2.2 History
VRML was conceived in the spring o f 1994 at the b t a m a i World Wide Web
Conference in Geneva, SwitzerIand. Tim Berners-Lee. developer of WWW, and Dave
Raggett organized a Birds-of+Feather (BOF) session to discuss Virtual Reality interfaces
to the World Wide Web. Attendees agreed on the need for these tools to have a common
language for speciSing 3D sœne description and WAW hyperlinks - an andog o f HTML
for virtual reality. The term Virtual Reality Markup Language was coined, and the group
resolved to begin spedkation work after the conference. The word 'Markup' was later
changed to 'Modeling' to reflect the graphical nature of VRML. . . . The group quickly
agreed upon a set of quirements for the k t version. After much deliberation the iist
came to a consensus: the Open Inventor ASCII File Fonnat from Silicon Graphics Inc.
The Inventor Fi Format supports complete descriptions of 3D scenes with polygonaiiy
rendered objects. lighting, materials. ambient properties and realism effects. A subset of
the Inventor Füe Format, with extensions to support networking, f o m the bais of
VRML. Gavin Ben of Silicon Graphics has adapted the Inventor File Format for VREla,
with design input from the mailing kt. SGI has publicly stated that the nle format is
available for use in the open market, and have contributed a nle format parser into the
public domain to bootstrap VRML viewer development [2 11
2.2.3 VRML Specifications: Defining Virtual Worlds
From a VR ianguage point of view, the b t version of VRML (VRML 1.0) ailows for the
creation of virtrral worlds with limited interactive behavior by specifynig some standards
for rendering7 networking, limited touch, and vision. nie vinual w o r b created by VRML
can contain objects which have hyperlinks to othet worlds, AML documents or other
valid MIME types.
As mentioned earlier, the carrent VRML format is a subset of the OpenInventor File
Format fkom silicon Graphies plus extensions to support networking. A vinaal world can
be simply defined by specifyiig its objects. The objects are denned in terms of their shape
(sphere. cube. surfaces...), size7 position7 material and color. In addition. cameras c m be
defined as if the user is lookuig at the scene through that camera. Also light sources and
their position are specifed.
For example. let us present the following scene in the VRML format:
Figure 3. An example 3D scene
This scene basicdy consisu of a red cube, a green sphere and a blue cone in &ont of a
white waU Here is the correspondhg VRML 1.0 description for the above scene:
#VRML V1.0 ascii Separator (
DirectionalLig h t ( # sceae tighting direction -1 O -3 iatensity 2
1
PerspectiveCamera ( # camera bokuig at scene position 0040 orientab-011 O O 1 O
10 10 5; -10 10 ) # vertbs of the w d l
Rotation ( rotation O 0.000001 O 3 . 1 4 W )
IndexodF&t( coardladcx [ 3,2,1,0,-1] ) tcwaectioa maûix fa the vatices 1 separa- ( #E?-=p&re
Translation ( CrawIation 5 -5 O )
Material (difhiseColor O 1 O } # cdor in RGB
Sphere ( radius 15 ] 1 Separator ( Wredcuk
Transform(roiati0~ 1 1 -1 1.0 epaslaiion 1 -5 O}
Matenai ( diffuseColor 1 0 0 }
Cuôe (widlb 2 2 height 2 2 deptb 21) 1 Separatm ( # blue conc
Traasfonn (roiation -1 1 -1 -0.8 translation 8 -45 0)
Materiai ( diffusecolor O O 1 )
Cone (bottomRadius 12 beight 3)
1 1
Here is a snapshot of the view generated from rhis description:
Using the mouse, a user can navigate in the above scene and view the objects from
different angles and distances. Aiso. any object can be associateci with a hyperlink such
that by clicking on that abject, the doc~ment pointed to by the hyperlink is loaded into the
appropriate browser. Hence, as we can see VRML 1.0 bas standards for rendering, very
limiteci interaction, and some networbg.
In order to create or use VRML files, some software tools are needed. Software
applications that allow the users to view VRML nles are usuaiiy availabie for free Born the
Internet On the other hand, the modeling toois are usualIy commercial,
2.2.4 VRML Tools
VRML, Bmwsem
Figure 5. Snapsbot of& VRWeb Browser
VRML-Browsers are software tools that generate views h m a VRML &. You would
need a VRML-browser to "see" a VRML nle as you would need an HTML-browser (like
Netscape) to view HTML nies.
VRML Modeleas
Figure 6. Saap~bot of a Modeler
It is extremely difhult, if not irnpossiiie, to ditectly write the VRML description for
highly complex shapes (such as the above scene); therefore, there's a need for VRML
authorhg tools or modelers.
A modeler is used to cmte thtee-dimensional scenes or objects. A user can simply draw a
scene and the modeler would export it to VRML format. Most modelers also import 3D
objects written in other standards such as OFF (Object File Format), Softimage 3D, IBM's
Visualization Data Explorer @X), and many more.
2.2.5 Moving Worlds: VRML 2.0
As we saw, VRML 1.0 de- standards for ceade~g, very limitecl interaction. and
networking. In order to enhance the capabilib of VRML m terms of a standard for
M u a l reaüty as discussed in 2.1, many proposais were submitted. Among these, Moving
Worlds by Silicon Graphics 1231 was acceptai for VRML 2.0.
Moving Worlds Mers the capabiüties of VRML 1.0 by inuoducing the following:
a scriptinn h n p a ~ binding in Java and Javascript;
events that c m be muted h m one object io another;
Sound:
the, motion, click, and other types of sensors.
Java is a platfonn-independent objet-orienteci pmgramming language. We will see more
about Java in chaptet 3. hvaScript is Netscape corporation's extension to HTML
implemented in the Java language. JavaSaîpt is a programmable APL that aUows cross-
platfonn scnpting of events, objects, and actions 11 11121.
If implernented cornpletely, VRML 2.0 comes very close to a nch VR standard. However,
currentIy there are very few browsers available for VRML 2.0 and none of them
completely meet the specincations for VRML 2.0. [22]. Nevertheless, it must be noted
that the final specincation for Moving Worlds was released on Aupst 4, 1996 1231 and
that it is a very new standard. h the, more VRML 2.0-cornpliant browsers are expected
to emerge.
So, VRML can be used as a 3D standard for the tek-leaming system. In the foiiowing
chapter, the issues of a standard for user-interfaoe are addressed
Chapter 3. Jaw: Applications through the World Wide Web
3.1 Introduction
As pointed out in the introduction, there is a need for an interface in order to present the
multimedia applications such as the whiteboard, document viewer, chat session, and 3D
viewer to the user, We ais0 mentioned thai it was necessary to use tbe existing standards
for the development of the tele-ieaming applications in order to make it accessible to the
rnajority of users on the Internet. As a cesuit, it was d d e d to use the most basic interface
to the Internet: a Web browser.
Basicdy, a Web browser is a window to the htemet that can present various multimedia
documents such as text and images in an orderly fashion. A Web page, dispiayed by a Web
browser, is a document that contains advanced text, graphies, background templates, and
hyperlinks to other documents. The h g u a g e in which Web pages are cceated is the Hyper
Text Markup Language, abbreviated as EFLmL. Analogous to VRML, which is a language
for presenting 3D data, HTML is a hguage for presenting 2D data. Praictically al i
Internet users are equipped with an Internet browser. It is by fa. the most widely used
interface to the intemet.
So, documents containhg text and irnages can be presented with HTML ushg an inteniet
browser. But how about the applications comprising the virtual c ~ s r o o r n : the
whiteboard, the chat session, and the 3D browser?
It tums out, there are three main ways to run applications through an Internet browser:
using helper applications, plug-ins, and applets.
A helper application is basicaiiy a ce* platforrudependent application mnnuig on a
workstation To use a hem application, the user has to nrst dowdoad the application for
hisher specific platfocm. then install the application on the workstation and make sure it is
running properly, and finaily infom the Web browser about the application by configuring
some parameters in the Web browser. As a resutt, evecy time the browser encounters a
document that is intended for a helper application, the browser fétches the document,
invokes the appropriate helper application and passes the document to the helper
application.
Plug-ins take the idea of helpr appücations one step further. A plug-in application uses
the Web browser a s its interface and displays its documents inside the browser. As with
the helper applications, plug-ins are platfonn-dependent and have to be downioaded and
pennanently installed on the workstations.
Applets introduce a different approach for cunning applications in a browser. An applet is
an application that is embedded in a Web page. It is autornaticaHy downloaded when the
browser encounters the appbt's Web page and it is erased when the Web browser's
operation is tenuinateci. Furthemore, applets not only use the browser to display their
activities, but also cun M i e the browset. The latter property is the rnost important feature
of an applet; since the appbt mm in the browser it becllmes pIatform idmendent. In
other words, runnÏng applications becomes the question of whether or not a browser can
run applets and not the question of îhe undedying operaihg system or platform.
Currently, the ianguage used to write applets is Java. A browser that can run Java applets
is referred to as a Java-enabied browser. Today, more than 9096 of Web browsers king
used are Java enabled. More than 80% of users use the Netscape Navigator browser which
is available for a variety of platfom. Also, close to 10% of users use the Internet
Explorer browser by Microsoft which runs on the Microsoft W i o w s platfom. Both
these bmwsers are Java enabled, In addition, Sun Miçmsystems' Hot Java bmwser, whkh
is a browser written in the Java language, also supports Java applets.
Other than the avaüability of Java enabkd bmwsers, there are more indications that Java is
becorning a standard for Internet programming:
WebTV, a newly developed device h m WebTV Networks, is a set-top box that enables
web-browsing with an ordinary television and a phone Illie; no computers needed. It has its
own proprietary software and web bmwser, which offers most of the features found in
Netscape Navigator and Internet Explorer including Java. Users cm subscribe to
WebTV's online service, which includes an e-mail address and banking seMces, at a flat
rate of $19.95 per month for unlimited usage 1241.
Another brand new network pmduct is the IBM Nenvork Station, a network terminal that
provides network access over lnternet using Ethemet and Token Ring connections, The
main advantage of the Network Station over the non-programmable "dumb" tenainais is in
oflering graphical interfaes, Java prograrnming capability, and a browser for connection
to the intemet, corporate intranets and server networks. It offers plug-and-play simplicity
and an intuitive Windows-style graphical interface, but is managed through a semer
network. This reduces hardware, software and management expense by 50 to 75 percent
over traditional personal computers. Here are a few statistics fkom IBM's Network Station
press release 181:
22 percent of ail Intemet access devices wiU be non-PC machines by the year 2000,
accoding to International Data Corporation;
seventy percent of corporate executives Say they wiii use the Intenet for business
transactions by 1997, according to a Fonester Research horpocated survey. The
study also States that sixty percent of the two million new Internt users each mnth are
fkom the business wodd;
More than 35 milüon non-programmable tenninnls are in operation workiwide,
according to IBM eshates.
As we can see, many of the future network deMws wül mn Java. These devices are not
just computers but simple devices such as televisions, rerminals. ceiiular phones, and so
on.
In short, Java has certain advantages over current languages that make it superior for
Internet programming. Java applets posses unique f e a m Wce:
no downloading andlor instaüing of any special software if used with a Java-enabled
browser or device;
platfom-independence;
supported by more than 90% of current Web browsers and many of the future network
cornputers and devices, meaning accessibility to a large user population.
Because of the above features, specially the platforni-independence and accessibility
properties which are very important for this project as elaborated d e r in the
introduction, it was decided to use Java applets as the standard for writing tele-learning
applications. This choice cream both conveniences and challenges which are discussed in
the next section.
3.2 Java and lts Fmtums
3.2.1 M a t Is Java?
Sun Microsystems, the Company that crieated lava, describes Java as foiiows:
"Java is a simple, object orienteci, distributecl, interpreted, robust, secure, architecture
neutral, portable, high-performance, multi-threaded, and dynamic language."
Although the above statement might seem Like an aduertisement's chah of buzzwords, it
truly describes the chatacteristics of the Java language, Let us briefly examine some of the
above features.
Simple: Java is simple in many aspects but rnainly because it is easy and quick to barn
compared to other languages- It looks famiiiar to C and C u programmers even though its
language constructors are much smaller. Furthemore, thete are no pointers in Java which
is one of its most pop& features compared to C and C++ as pointers are one of the most
bug-prone aspects of C and Cu. In addition, Java programmers don? have to worry
about garbage collection as it is automaticaiiy implemented by the mn-the.
Object-Orienteà: Unlüre C* which was an extension of C, Java was designed to be
object-oriented fiom the beginning. Java cornes with an extensive set of classes, ~RSented
in different packages, For instance, Java contains classes which create graphical user
interface components (GUI), classes that handle UO, classes that handle networking, and
so on.
Distributeci: Java is designed to rnn applications on networks, It provides the
programmer with classes for network connectivity, includig sockets.
Interpreted: instead of producing native machine code, which is what C and C++ produce
as executables, the Java compiler produces byte-corles. A Java interpreter is used to
actuaiiy mn the byte-code. A Java program can run on any platform that has a Java
interpreter and mn-&ne system, known togetber as the Java vimd machine. Java enabled
browsers implement a Java virtual machine. What makes Java perféct for the Interner is
the exuernely smaU size of the compiled byte-codes; it takes very lit& t h to download a
Java applet compared to its corresponding C or C u application.
MuItithreaded: Programmers know that writing code in C and C++ that deah with
muItipIe threads can be very fiustrating. It is h a d to maintain concurrency, and wciting
code to handle Iocks on certain rouhes and variables can result into deadIock situations-
Java offers built-in support for handling threads, including concurrency and consistency.
It is interesthg to note that in the Java ianguage, applications and applets themselw are
objects. A Java "program" is a class that is either an extension of another ciass, an
implementation of one or more inter$aces, an extension of a class aMf implementation of
one or more interfaces, or a brand new clas.
The difference between a class and an intedace is that ai i rnethods of an interface are
abstract: they are not de- and are impiementation-specific.
To 'hn" a Java application, the application's class must be instantiated; ie., an object of
that class must be created in the Java virtual machine. To mn a Java applet, the browser
must be told to fetch the applet's corresponding class. This is done by embedding the
applet into an HïML document by using a format similar to the foiiowing:
When the browser encounters the above code in an HTML file, it will fetch the class
MyApplet from the same location as the HTML fi and will nui the applet in a 300x300
area inside the browser. In addition, the two parameters, file and repeat, wdl be
initiaüzed in the applet with the values image.gg and 3, respectiveiy. In other words,
parameters are a way to initiali;tp. applet's contents h m the E l ï M L fïk they are
analogous to command-iioe options in applications.
Let US now sxamine some of the classes of Java that are of interest to this mearch.
3.2.2 Some Advanced Features of Java
The foiiowing classes are only some of the classes of some of the packages of the Java
ianguage. They are b M y describeci here because they are core to the tek-learning
software engine. For more elaborate description of Java packages, pIease see references
[SI and [13].
Networking
The j ava . net package contains classes that are relevant to networking. These classes
include:
j ava . net. ServerSocket: used by servers to listen for connection requests from
clients ;
j ava . net. Socket: impîements a socket for interprocess communication over the
network;
A socket ir a module for accomplishing inter-process communication (IPC); a socket is
used to aiiow one process to speak to another via a network, very much iike the telephone
is used to allow one person to speak to another. When two entities on sepme
workstations want to communkate, a socket is established to handle the communication.
The entities then use the socket's metho& d variables to obtain açcess to network
functions such as sending and reœiving data
Sockets are created for specinc ports. A port can be thought of as an address for a specinc
application that is nuuiing on a workstation. The port is needed since there might be more
than one application nuuiing on the same machine at the same t h e that requires the use of
network connections; ports are used to distinguiîh which data incoming nom the network
(or outgoing into the network) belong to which application.
In~uUOutDut (Y01
The j ava . io package contains classes that deai with different Il0 streams. including:
j ava . io . f nputsttean: provides basic input methods for reading raw data;
j ava . io . Output S tream: provides basic output meihods for writing raw data;
java. io.~ataInputStream: provides input methods for reading Strings and
primitive data type@;
j ava . io . DataOutputStream provides output methods for writing Strings and
primitive data types;
java. io.Piped1nputStteanr: provides the input haif of a pipe used to
communicate between threads on the same machine;
4 Remitive data types are: boolean. character. byte, short inkgers. integer, long integer. fioating point num bers, and double precision floating point numbers.
java . io . PinedOutputSttesm: provides the output half of a pipe used to
comrnunicate beween threads on the same machine*
A pipe is a sueam that cYries data between two modoles or threods that are rwuiing on
the same Java virîual machine.
Although all of the above classes provide different methods for reading and Wtiting thek
conesponding data; they have no methods for sending or receiving data through networh.
However, a socket object can retum an InputStream object and an OutputSueam object .
These objecu can be furthet abstracted into DataInputStrearn and DaraOntputSaeam
objects for more convenient Y0 operations. Using the read and write methods of these
objects. data can be exchanged across the network.
Hence, the procedure of sending data through the network between a server and a client
becomes similar to the foilowing:
Semer:
1. start a Serversocket object on a predetecmined port and wait for connection
requests from clients;
2. when an incoming connection request is received. accept the co~ection and retum a
Socket object of that connection to the object that handles the data (the semer);
3. the server gets the InputStream and OutputS tream abjects from the Socket
object, further enhanchg them to DataInputS tresm and DataOutputS tteam if
necessary ;
4. now, data sent by the client cm be read b r n the XnputStream (or
~ata~nputstream) object and data to be sent to the client can be written to the
OutputStream (or DataôutputStteam) object
The following diagram iilustrates the above procedure:
Figure 7. Exchghg information tbrough neiwal SOdEets: m e r operations
Ciient:
1. create a Socket object, requesting connection to a predetermined port on a known
machine;
2. get InputStream and OutputStream objects h m the Socket object, funher
enhancing them to DataInputStteamand DataOutputStream if necessary;
3. data sent by the server can now be read h m the InputStream (or
DataInputStream) object and data to be sent to the semer can be written to the
OutputStream (or Dataûutputstream) object.
The foilowing diagram illustrates the above procedure:
Gra~hical User Interface
The java. awt package is the Abstract Windowing TooUut. This package contains
numerous classes for impiementhg graphics including coiors, fonts, and polygons;
windowing components including GUI components such as buttons, menus, lists, and
diaiog boxes; and haUy layout manager for conuoiüng the layout or mapping of the
components into their container.
No specinc classes of this package will be d d b e d like the j ava . net and j ava . io
classes were described because of the large number of java. awt classes. Specific
classes will be discussed as they corne dong.
Multi-Uireading
The j ava . lang . Thread object provides basic means of multi-threading in Java with
the foliowing methods:
e tart ( : starts the tbriead;
et op ( ) : stops the k a d ;
ru(): thebodyofahread;
suspend ( ) : temporarily halts a thread;
resume ( ) : resumes a suspended thread;
e leep ( ) : suspends the thread for a specifïed amount of tirne.
This class itseif is an impiementation of the Rmabie interface whkh contains the abstract
run ( ) methods. In addition. the Thread cbs has methods that provide mans of access to
the threads priority.
A thread can be written as an extension to the Thread class, or an implementation of the
Rumable interface. Multi-threading can be done b y instantiating many thread classes.
3.3 Applets and Tneir Restdctims
As mentioned earlier, using applets causes both conveniences and challenges. The main
advantage of ushg applets is that once an appiet has been written, it can mn in any Java-
enabled browser on any plat$om. Other advantages are the result of using Java as a
programming language which were disciissed in 3.2.
The first disadvantage of using applets is speed. Although speed of applets is more than
adequate to nin interactive GUI and network- based applications, since byte-codes have to
be interpreted by the Java virtud machine before mnning. Java applets are considerably
slower than thw cofzesponduig C or C++ applications. However, Java designers are
working on just-in-n'me (JZT) compilers that translate byte-codes into machine code for a
particular CPU ai run-time. Prelimuiacy JITs have started to appear for the Intemet
Exp lo~r [12] and the Netscape bmwser.
The main challenge caused by using applets is overcomhg th& security restrictions. Since
applets are loaded over a network, the only way to maLe sure that they do not perfom
any rnaücious action, k e dekting system files and sending fake am&, is to nin them in a
very lirnited environment. While desigaing an applet, the designer must keep certain
restrictions in mind. There are many applet restrictions. For this research, it must be
realized that applets are not allowed to:
read files on the local system;
d i e files on the local system;
delete fües on the local system;
renarne mes on the local systern;
create a dïxtxtory on the local system;
List directory content
check for the existence of a me;
obtain the type, ske, or modification t h e of a nle;
create a network connection to any cornputer other than the one firom which the a ~ ~ i e t
was loaded;
Listen for or accept network connections on any port of the local system;
obtain user's name or home directory name;
define any system properties;
invoke any program on the local system.
As one can see, these restrictions are rather severe when approached by the conventional
C or C++ progtamming perspective. Therefore, it is evident that programming applets
must be with the mentality which is different h m that of the conventional programming.
For instance, it is obvious that if applets are ever to communkate with eaçh other, it has to
be through a central-server archiîectote as applets can only make network connections to
the machine frorn which they wece dowdoaded,
In generai, the approach to designhg advanceci applet-based systems. such as the tele-
learnhg system, must be that of an object-orienteci, distributeci, and client-semer
architecture. This was the approach used for designhg the tele-iearnuig architecture as
completely desçribed in the following chapter.
Chapter 4. Design of the Multiuser Client-Semer Model
From design point of view, the main characceristic of the tek-leaniuig system is that it
should be simple, generic, and robust. The systeiii shontd neither be too cornplex nor too
specinc as those wiil prevent integration of the system with other systems, as well as limit
the evolution of the system and make it u s e b in the long nia On the other hand, it
shouId not be too simple either as that will cause a lot of effort and work for the fùture
developers of the system to enhance its feanires. Currently, most existing approaches to
shared environments offer some son of primitive distribution mechanism such as
asynchronous message passing which gives littk help to the developer because al1
distribution and synchronization issues must be dealt with explicitly[lS]. The tele-leaming
system must provide fiinctionality which is ttie common-denomùiator of functionalities
required by all collaborative applications, plus some advanced features. With that in rnind,
the specifications of the system are described next.
4. i General Specifications
As mentioned in 3.2, a centralized-server architecture is inevitable because applets can
only communicate to the cornputer h m which they were downloaded. Any message-
passing as weil as other types of communication must be done through the semer. Hence,
it becomes apparent that the senter must be able to handle asynçhronous message-passing
amongst applets.
Since the environment is multi-user, issues such as access connut and cunsistency &O
becorne a problem. In this thesis, access control is referred to the action of assuring that
ody one user has access to a shared object at a time and that no two or more users can
modQ an object at the exact same time. Consistency is ceferreci to the state that ai l users
are simultaneously pmsented with the same data and objets.
Aii of the above are common to collaborative applications; though not aii applications
require both consistency and access control In addition, the secver shodà also be able to
monitor clients' States (active, &nt, dead) and to exchange signals with specific clients.
So, the features that the senet muse provide are:
consistency
access control
asynchronous data passing
monitoring of clients
signaling abiiity between client and server
The 6rst three features are justikd based on the system's needs. M o n i t o ~ g of clients
becornes necessary for security reasons. It sshould be possibie for the secver's administrator
to see who is lagged into the system, who is accessing objects, and what state individual
clients are in. Signaiing abiiity between a client and the semer is also necessary for various
rasons such as a client requesting access to a shared object an so forth; there is a need for
the client to talk to the server privately.
The client must inherently posses the foiiowing features:
automatic network connation to the server
a client thread to handle incorning messages in rd-time
acceSs rnonitor
automatic signaiing of the client's status to the server
dialog with the user
As a buïit-in feature, the appIet, once downloaded into the browser, should be able to
automaticaliy establish connections to the server ftom which it was downloaûed fkom.
Also, the applet s h o d fork at k t one thread whrh is responsible for cd-time handluig
of incoming data and messages. It is important that this tasic be pecfonaed as a sepatate
thread since the applet itseif is interacting with the user in mi-tirne. This mdts in
instantaneous response to user interactions as weU as incoming data and maices the system
more rd-time.
However, it might well happen that the incoming message causes the a p p k to perfonn a
task which is confiicting with current user interaction. For example, in a shared 3D ob@t
viewer, the incoming message might indicate that the ob*t should be rotated to the right
by 90' whereas the user might want to move the ob@t forward by 2 meters. That's why
there is a need for an access monitor at the client. The client must provide a means of
requesting access to a shared object as well as releasing an accessed shared object
Also, the client must autornaticaiiy infonn the semer of the cknt's state. For example,
when the user nünhks the browser the applets becorne inaccessible to the user for as
long as the browser is minimued. In this situation. the client appiets should infonn the
server that they are silent and not active. When the user quits the applets or the browser,
the client applets must inform the server to close down the connection and û.ee network
resources for other clients.
Finally, the client must have methods to show messages to the user in order to inform the
user about some actions such as downloading nle and pacsing 3D object, as weil as ermr
or w a n - g messages.
The proposed cknt-server architecture provides an infrastructure for developers to create
coilaborative applrations without having to deal with the main issues of conœm for
coiiaborative environments. Programmers cm b 3 d shared applications just by writuig the
code for what the application is supposeci to do without ever worrying about issues such
as communications to other clients, access control, consktency and so o r niese issues
becorne abstract to the user since they are automatically perfonned by the tek-Ieaming
s ys tem.
Consequentiy, the goal here becomes the creation of a shared Server class and a shared
Client class that f o m the basis for the development of shared applications. Developers
c m then extend these generic classes to write code for their specinc application. The
architecture for the Server and Client classes is presented next
In order to achieve maximum real-thne behavior, there is one Server ob@t kunched for
each application. If there is oniy one server serving aU clients of ail applications, that
server will be severely hit by performance problems. At the other exuerne, using one
server for each client creates to many servers and overhead on the machine mnning the
server. Therefore, it malces sense to have one server for each application, serving aJl the
clients for that application Each individual server can then launch smaU threads for each of
its clients to provide even fiuther ml-time behavior.
The architecture involves both the layout and the operation of the tele-leaming system.
4.2.1 Layout
SERVER
The generai layout of the server is shown in the following figue:
Figure 9. Context diagram of the Server
As it can be seen, the server consists of the following objects:
ServerSocket: responsible for accepting connections from clients;
DataSemer: responsible for asynchronous data passing between clients;
SignalSemer: responsible for handiing and exchanging signals with a specific client;
Consistency: monitors interactions with shared applications and can be acçessed to
find out the current state of a shared object;
Mutex: consists of a semaphore and its operating methods that can be used to attah or
release lock on a shared object;
ClienîList: an array of ~utput~tream objects that corresponds to output streams to
aü of the clients.
Except for the CiientList and the Mutex objects, aii the above objects are real-the
threads. This enswes maximum real-time behavior fiom the server. The DataServer,
SignalSemr. and Consistency objects are fodced a f k the ServerSocket has accepted a
connection. The forking procedure is explained la- in details.
Note that the SignaIServer and the Datasecver should not only nin as separate thteads, but
ais0 use separate Sockets to communkate with the cknt. This separates the job of
signaihg and data passing; the system can be thought of having a Data Channel and a
Signalhg Channel. The advantage of this, other than a highly red-time performance, is
that data and signals can be sent independently simultaneoudy.
There is also GUI-enabied version of the Server class which in addition to the above
objects, also contains a GUT object. This object is used to visually display the name, status
and object-accessing of clients to the server administrators. This display could be in fonn
of a table simila. to the one shown below:
Figure 10. Sample monitoring interface
The reason the GUI object is not included in the standard Setver class is that servers
usually run at aIi thes, even when semer administrators are not logged into the server
machine. GUI interfaces are kiUed upon log-out of users, resulting in interruption or
in this thesis. server adminisuatm is referred to the person that is responsible for the operation of the server.
destruction of their conespondhg processes, in this case the setver. Therefore, the GUI-
enabled version of the semer is used only for short tele-leamhg sessions or for machines
that are dedicated as servers, meaning the supervisor is always logged in.
Next, the client architectme is presented.
CLIENT
The general layout of the client is shown in the following figure:
Figure 11, Context diagram of the Ciient
The client basicaliy consists of the these objects:
Receiver: responsible for receiving and handling the incoming &ta in reai-time ;
Applet: the applet body itseif.
The Receiver is a ihread; it aiways listens for incoming data and p e r f o m appropriate
actions upon receiving data. This ob@t ceceives data fkom the DataServet object of the
Server class. The Applet is an extension to the java. applet .Applet class which is
the regular applet class used in Java. The Applet class is responsbie for automatic network
connection establishment, status signaüng, and access monitor. It automaticaily
corn municates with the ServerSocket and the SignalServer objects of the Server class.
4.2.2 Operation
CLIENT
Once downioaded into the browser, the Client applet establifhes a Socket connection to
the server. From the Socket, it gets VO Streams for Data channel and, i€ quired, Il0
streams for Signaüng channeL Data channe1 wili then be nItered h m InputStream and
OutputStream to DataTnputStrearn and a DataOutputStrearn to facilitate Il0 operation for
primitive data types. As mentioned before, the InputStream and OutputStream objecu
only support reading and Wnting of raw data. The flowchart below shows the operation of
the Client:
nid or@nat@ host and establish a Socket comcction ta it for data tramfier
61ta the raw streams of the Sockd iato data s t m a ~ ~
1 end i~iitiaîizaîion 1 Figure 12. Applet initiaïization automaticaliy perfonned by tbe Client
For appiications that require consistency, the Client appkt also performs an appkation-
dependent inithikation for consistency. This means that it will receive consistency data
fiom the server in order to adjust iwIf with the current session in pmgress. Since the
consistency data is application-dependent, an abstract initialization method for the Client
class is provideci that has to be denned by the programmer.
Note that al1 applications do not require consistency. It wouid be a waste of cesources to
provide consistency (on the semer and on the client) for applications that do not need it.
This is why consistency is supporteci as an option. We WU see more about consistency
when the Server operation is described.
The Client also has an abstract runo method. This is the Receiver part of the Client, In this
method, programmers must dehe what kind of data the appIet should be expecting, and
what the applet should do with those data. For example, in the case of the shared
whiteboard, the Receiver should expect four integers representing coordinates of the two
end points of a line, and should draw a line using those numbers.
Moreover, the application programmer must keep in mind that data needs to be sent
through the Data channel every time the user interacts with the applet. For instance, when
the user draws a line in the whiteboard application, the client should send four integers to
the server, representing the coordinates of the two endpoints of the line. This data is sent
to the DataSemer object of the server, which than relays this data to a i i other clients and
the Consistency object, if applicable.
The pre-determined way in which appiications send and receive data arnongst themselves
is labeIed Messrrging Scheme. When a user interacts with an appkt, the specific interaction
is mapped into a message, and the message is sent to other applets. The receiving applets,
translate that message into an action using the same messaging scheme and perfonn that
action. For instance let's assume that in a 3D-viewer applet, the messaging scheme is
similar to the foilowing:
O: rotate 1: move 2: zoom 3: get 3D file
When one of the users rotates the 3D objeçt by 20°, the 3D viewer applet maps this action
into 0-20, meaning rotate by 20°. ThiF message is sent to other appiets where it is
translatai into the appropnate action using the sme messaging scheme.
Hence, it becornes the responsibility of the programmer to build a rnessaging scheme for a
particular shared appiet. This scheme must be implemented in the runo method of the
Client class for receiving messages, as weii as in the ment-handiing rnethodr for sending
messages. Event-handling methods are methods such as mouseUp0, mouseDown0,
mouseDrago, and so forth.
AIthough the messaging scheme is the fastest way of reflecting interaction from one client
to the others, it is not the most convenient method for the programmer, The more complex
an application is, the lacger its messaging scheme becomes, The easiest way, but not
fastest in terms of performance, is to use sorne technique similar to Remote Procedure
Cull (RPC) in C and Ctt. Using this technique, a client can directly invoke other client's
methods. For instance in the above example, if the 3D viewer application has a method
cded rotate(float theta), an initiating client has to remotely c d rotate(20) on ai i other
clients to reflect its user's interaction.
Presently. Java does not support RPC. However, a similar technique callai Renwte
Method Invocation (RMI) is under development for Java. As of the âay of Wnting of this
thesis, RMï is not available as part of the cone Java packages.
The Client applet also has the foliowing bdt-in parameters:
TABLE 1. BUILT-IN PARAMEIERS ~ R T H E C~LENTCLASS Parameter 1 De!dption
name indicates the name of the applet, for example "3D Viewef'. The port number is the
one the applet uses to connect to the server.
The host parameter contains the domain name of the semer for exampIe:
"mango.genie.uotawa.ca*~. The question that arises here is that why should there be a
parameter for s p e c w g hostname if the applet is able to h d the hostname from which it
was downloaded from? SpeciQing hostname causes re-wtiting of HTML file when the
server machine is changed and creates inconvenience,
The answer is that because of security reasons. some cornputers are protected by a
jïrewall and are connected to the Intemet through a proxy semer. A proxy server fetches
Internet documents for its clients, rneaning that the computers behuid the Grewail which
are not connected to the intemet can have interna access through the proxy server [ l].
The problem occurs because the Web browser of a cknt that uses a proxy semer thinks
the applet's host is the proxy server and not the real server- So it must be told s p e c W y
name port host
signai consistency
name of the application port nuruber on server hostname of the server
signaling option consistency option
Applet -
"appIet's host" false false
to request comection to the applet's server and not the proxy server. That's why there is
need for the host pararneter.
The signal parameter indiCates whether or not a signahg charme1 is needed. The Server
ciass always offers a signalùig chaniel; however. specific applets might not need to use a
signahg channeL If the Servet is hunched with the GUI option to monitor clients, then
there is a need for ail appiets to use a signaling channe1 to report th& state to the semer.
Otherwise, the only other time applets require signahg is when they need to lock or
release a shared obpct. Thecefore. if applets neither report their state to the server nor
need to lock a shared abject, they won't require a signahg chamel Examples of such
applets are chatting applets, or shared whiteboard, or shared HTML viewer to some
extent. These applets really don? need to lock their application at any the.
There is &O the consistency parameter which indicates whether or not the applet should
perfom any initiahation for consistency purposes.
SERVER
The Server can be started with or without one or both of the two options: consistency and
access controL This kxibility is provided since different applications require different
types of distributed service. Some applications, for example the whiteboard, q u i r e
consistency but not access controL The whiteboard needs consistency since a new user
should be provided with what has already been drawn on the whiteboard; however, access
control is not rquired since it is aii nght for more than one person to sirnultaneously draw
on the whiteboard. Other types of applications require both consistency and access
control; 3D object viewer is an example of this type.
So, depending on the type of the application, the server can prode consistency or access
conuol or both. It would not only be a waste of resowces to provide both the above
seMces by default, but also a problem for the applications that don't need them.
The operation of the Semer is illustrateci in the foiiowing figure.
COllSaCllcy ~ïre*d) rad SavaSocktt
Figure 13. Operation of W Server
The Server starts by launching a Mutex and a ServerSocket object and, if instructed to, a
Consistency object. The ServerSocket will listen to connection requests on a speçific port
and accepts connections if the current number of clients is k s than the maximum number
of clients aiïowed. Upon acceptance of a connection, the SetverSocket returns a Socket
object representing the cknt. Depending on whether the cknt neeh that Socket for data
channel or for signaling channei, the server takes appropriate action. If the client is
requesting a signaihg channeG the Server passes the Socket to SignalServer and goes back
to waiting for new requests. In case of a data channel request, the Socket retwns an
InputStream and an OutputStream for data cominunication. The OutputStream is added to
the ClientList. The Sewer than perfonns initiaiization procedures if consistency is enabled,
and launches a DataServer thread passing to it the InputStream retunied fom the Socket
pIus the ClientList.
As we can see, there will be a separate DataServer thread ninning for each client. This will
ensure that the message exchanging speed of the Server is rnaximized as these threads run
DATA SERVER
The foiiowing fiowchart shows the operation of the DataServer:
Figure 14. DataSemer operation
The DataSemer, now running as a separate thread, listens to incoming data h m its
correspondhg client on the InputStream and relays the data to ail the OutputStream
objects in the ClientList, except for the client itseif.. At the InputStream levei, this data is
raw data; a bunch of ones and zeros. The DataServet doesn't know what the data
represents: an integer, a String, or an image. This will ensure privacy of data king
communicated and more important fast performance of the semer. So as we can see, the
DataServer accompiishes the task of data-passing.
In the case of access control king disabled, the DataServer locks the OutputSmams in
the ClientList before sending any data through hem, This action is not performed if access
control is enabled. This can be explained as follows:
When there is no access controi, every user can unrestrictedly interact with the
application. As mentioned before in the client operation section, these interactions are
trandateci by the pre-detennined messaging scheme and sent to other clients. The problem
occurs when two or more users do something with the application at the same tirne.
For example, suppose for application X that does not need access control client1 sends
the message "4,23.1,Hi" to its DataSemer whereas at the same time client2 sends the
message "4,24e9" to its DataServer. These messages collide at the Semer, producing a
new message which is not comprehensible for other clients (see figure 14). The result
could be anything fiom random graphics patterns appearing on the other clients, to Server
or DataServer crashes. This problem is prevented if each DataServer locks the
OutputStm ùefoce sencihg its message. But as mentioned eaclier, the DataServer does
not know what data is king transmitted as it only sees bytes. Therefore, a special control
byte is sent by the client every time the message is finished. This problem does not occur
for the case where access control is enabled, of course, since in that case only one user at a
tirne is aliowed to interact with the application.
Figure 15. An example of message coilision
In addition to the above key O perations, the Datasecver automatically perfonns garbage
collection. When the DataServer's corresponding client quits, it closes the InputStream
and OutputStream of the client and removes the cknt form the ClientList. It then shuts
SIGNAL SERVER
The SignalServer, also mnning as a separate thtead for each client, listens to the signals
coming from the client and takes appropriate actions. These signals are sent as bytes with
different values. The folowing table smmvUes the built-in signals of the SignalSemer.
T ~ L E 2. BUET-IN SIGNALWG œ THE SIGNAL!%RVERCLASS Signal
O 1 1 2 3 4
Name Mutex-release .
MutexX1ock . Mutex-lock
dent active blink
Mutex iocked locked fke
- - - -
Action release Mutex
- lock Mutex notify GUI notify GUI
Respoiise to Client - O I - -
The 6rst two signal5 deal with access conml When the client wants to access a shared
object, it sen& a lock request (Mutex-iock) to tk SignalServer. If Mutex is alteady
locked, the SignalServet denies the client request by sending it back a signal of value zero;
otherwise, the Mutex is locked and the client is gifonned about its request king granted
by king sent back a signal of valne one.
The last three signals are used in the GUI-enabled version of the semer. In this version of
the semer, each SignalServet is given a Display area in the GUI interface. This Display
area consists of a name filed, a astanrsfieId arad an access field. The name nled displays the
hostname of the client. The status field is used to display the status of the client, while the
access filed is used to indicate whether or not the client is accessing the object
Figure 16. Optional GUI interface of the server lor monitoring cIients
The dent signai is automaticaily sent by the cIient when the appkt is not accessible to the
user because of the browser having been rnrnunized . . . for example. This is refkted in the
status field of the Display area The active signal is automatically sent by the client to
indicate that the user is actively using the applet. This is also rekted in the status field of
the Display area. The blink signai can be sent to indicate temporary activity by user. This is
done by putting an X mark in the access neld of the Diiplay area for 5 0 h and removing
it (blink). Furthemore, in the GUl-enabled version, the X mark is put in the access Eiled
when a client has locked th object and it is rmoved upon releasing the object. The
SignaiSemer closes the client Socket when tk client has quit. The flowchart below
summarizes the operation of the signai server:
Figure 17. SignaiServer Operation
The Mutex object is also of interest here. As describecl earlier, this object consists of a
semaphore of type Booiean plus two opetating methods. At the kginning when the Mutex
is initialized, the value of the semaphore is set to false, meaning that it is not locked. The
object has two methods: reado and seto. The rad0 method is used to read the value of
the semaphore and the set0 method is used to set it. The semaphore is locked by setting
its value to true. Both these methods are synchronized, meaning they wiii lock the entire
Mutex object before perforrnuig any action. This will ensure that one client cannot read
the semaphore while another is setting it. Also, in case the semaphore is free. two clients
cannot read it as fm and lock it at the same the.
The hst buüt-in function of the semer and the most cornplex one, is the Consistency
O bject. The Consistency object is another thread which monitors the s e of the shared
application, For example. the Consistency object of a 3D bmwser monitocs ail the
rotations, motions, and coordinates of the 3D object. It simply monitocs what the users are
doing with the object and keeps the state of the object up-to-date. Heuce, it is application-
dependent. The consistency initiaiization as p e r f o d by the Server (figure 12) is show
below:
d o c k object w - Figure 18. initialization operation as performed by Ibe arver
The main use of the Consistency object is for a new user joining the session in the middle
of it and not from the beginning. When a user joins the tele-leaming session, it is notiFied
by the server about whether or not Wshe is the k t user to enter the session. In case of a
h t user, thete is no consistency pmbiem and initialization is minimum.
However, in case the new oser is rot the k t one, the application is locked, the
Consistency object is asked for the data tepresenting the current state of the application,
that data is sent to the new client, and the appkation is unlocked. AU of this is prformed
by the server at the initialïzation stage, before launchhg the DataSemer.
It is apparent that this initiakation is appkation-dependent. For a 3D viewer, the
inithhtion data represents the present coordinates of the 3D object; whereas for a SM
whiteboard, the data represents what's already k e n drawn on the whiteboard. This forces
the Server class to have an abstract initiakation rnethod.
Hence, it becornes necessary for the programmer to d e h e two t b g s for the servefi the
Consistency object, and the initialization method.
The Consistency ob@t is rehtively simple to program. It is the same as the target
application except it doesn't display anythîng, receive or send any signals, or send any
data It only receives data and updates itself h the same fahion as the application. For
instance, the Consistency object for a shareâ whiteboard appkation is the same as the
whiteboard appücation except it draws its images and Iuies into an Image object without
displayhg it. That Image is used at the initjaiization stage to provide consistency for the
new user,
If the server is started with the consistency option, the k t entry in the ClientList is a
PipedOutputS tream to the Consistency obpct, This way, when DataSemers send
incoming data to all ciients using the ClientList, they automaticaiiy send those data to the
Consistency object as weii without ever knowing it exisis.
The initiakation method of the server is also easy to program: get the initialization data
from the Consistency object and send it to the new client, For instance, get the Image data
kom the Consistency object of the s h e d whiteboard application and send it to the new
user.
The following section is an atempt to surnrnarize the above layout and operations.
The Server class contains the foilowing classes and methods:
1 ServerSocket 1 listens for and acceptsnew connections 1 - - 1 Mutex [ contains a semaphore ahd synchronized methods 1 -
for reading and se- it ~onsistency* monitors the state of the application - -
I DataServer I performs asynchronous data passing Mrough the Data channel 1
SignaIServer ClientList
GUI'
* optional
initSetup0
Except for the Mutex and the ClientList class, al1 other classes are ninning as separate
threads to ensure high performance. There is one DataSemer runnuig for each client and.
if required, one SignalServet ninning for each client The initSetup0 method, which is
used for consistency initiaikation, must be denned by the programmer and is application-
dependent. In addition. the Consistency ob&t m u t be separately coded and included in
performs signahg through the Signaling charnel contauis O u t p u t S ~ s (PipedOutputStream for Consistency) of al clients consists of Display areas to show various client activities
Mutex, GUI - -
obtains data, representing current state of the application, from Consistency and relays it to the application
Mutex, Cowistency
the Server for applications that require consistency. This object is a simulation of the
actual Client applet.
The Ciient class has the following classes and methods:
TAU 4. m c u s s c o ~ p o ~
signalout 1 OutputStream of the signai in^ channel 1
Name dataIn
dataout s i g n a
mnQ 1 -ives data and handles them 1
Ta& DataInputStileam of the Data charnel DataOutputStneam of the Data channel
- InputStream of the Signaiing channel
initSetupQ 1 rieceives initialization data and handies themg 1 * if consistency is enabled
The initSetup0 method, which is used for consistency initiaiization and communicates t
the initSetup0 method of the Server, rnust be de- by the programmer as it is
application dependent, Furthemore, a messaging scheme must be implemented in the
runo method and the event-handihg methods of the appkt to enable clients infonn each
other about their user's interaction.
In addition, the Client class takes the foiiowing parameters fkom the HTML 6ie containhg
the client applet:
name: name of the application;
host: hostnarne of the server for clients that access the Internet through a proxy semer;
port: predetermined poct number on the host correspondhg to this application;
signal: indicates whether or not there is a need for signahg channeL Must be set to
true for application that requk consistency;
conJistency: indicates whether or not consistency is required,
The iollowing figure is the Open Distributed Processing (ODP) engineering mode1 of the
tele-leaming system, iiiustrating the pr-to-peer conimunication of methods:
Figure 19. ODP engineering mode1 of the tete-learning s y s m
Using the above architecture, two main classes, Server and Client can be developed. The
Client cIass can be extended to implement a speciüc stiared application. The Server class
can be extended to implement the server for that s p S c application; however. the
extension of the Server class is minimal for typicai applications and almost zero for
applications without consistency cequitement. The majocity of work, in order to create
shared applications, is perfomed to extend the Client class,
Ln the next chapter, the hplementation of sample applicatioos are pmented in order to
show the realizability and implementabiiity of the pcoposeû architecture.
Chapter 5. System lmplementation
Using the architecture pcesented in chapter four. including specincations. layout, and
operation, generic S e m and Ciieat classes were written using the Java language.
Although the Server can be written in any oiher ianguage, such as C or C++ in order to
provide high performance, Java was used for the prototype to make the server platform-
independent as well. The following section presents the A . of the JETS system.
5.1 JETS Appli&8tion Progmm lntemce (A PI)
The API of the JETS sytem is very easy to use. The constructors and public elements have
been kept ot a minimum, eventhough the functionalities and features of the system are
optimum. The Sewer class in specinc, has a very srnail API since most of the work is
automatically done by the class; there ici ver lit* the programer has to do. The Client ciass
has been given a larger interface since rnost of the non-generic fbnctionalities are needed at
the client application With this intro, here is the API of JETS:
public class Sewer extends Thread ( //Public Constructor public Servet(String nonte, int port, int numberojt7Iients. boolean consistency.
boolean access, boolean gui);
//Public Instance Objects public OutputStream outu; ll clients List public PipedOutputStream pipe; // out@] in client list (consistency)
/Public A bstract Methods public void initSetup(int outputStreamNumber) ;
1
name is the name of the server; for example VRMiSewer. port is the port number bat the
server is supposed to listen to. NwnberofCients indacates the maximum nomber of clients
aiiowed t access the serve at a tirne- This is used to prevent overwhelmtog of the setver.
consistency indicates whether or not the corresponding application tequires consistency. If
consistency is m e , the server performs the initSetupO method; if consistency is falre, the
server ignores the initSetup() methd
access indicates if access control is enabled or not. This has direct effect on the way the
Datasemer hanciles incoming data fiom clients, gui indicam whether monitoring of ciients
by the server is needed.
out[] is an array of OutputStream objects corresponding to data channels of di clients.
This is used by the DataServer to reiay incoming data to a l i ciients. If consistency option is
enabled, the h t enuy in the client ht, out[O], is a PipedOutputStcearn O bject called pipe.
This pipe can be used to reiay data to the Consistency o b & ~ So, the Consistency Object
wiii have a PipedhputStream that acts as the feceiving end of the information sent by
DataSemer through the pipe. Just a reininder that the data represents user interaction
according to the messaging scheme. The Consistency object uses this data to simulate the
application as mentioned before.
The initsetup() method is an abstract method that must be de6ned for each spedic server.
It should contain the code that perfonns the consistency initiabation operation. It is
necessary to d e b the initsetup() method even if the application does not require
consistency, in which case the method cm be d e w empty as foiiows:
public abstract void initSetup(mt i) { 1
5.1.2 Client
public class Client extends Appkt hpletuents Rumable ( // Defau lt C o ~ t o r : public Client
//Public fmtance Objeca public DatainputStream dataIn; public DataOutputStream damut; public InputStream signrlIn; public OutputStream signalout;
/Public Abstract Merho& public boolean initSetup0; public void runo;
//Public IRrtance Methods public void destroyo; 4fOvemYes Applet.destroy0 public void displayS tatns(S tring message); public void endo; public boolean getMutex0; public void Mt(); public void reieaseMutex0; public void start0; //fierrides Apple~start() p u b k void stop(); // fierrides Applet.stop()
1
Built-in parameters: name, port ,hast, signal, consistency. (see page 5 1)
datdn and dataout are the input and output o f the Data Channel; they are used to uansfer
primitive data types. signalln and signalOut are the input and output of the Signal
Channel; they are used to trader signals between the client and the server, They are
activated only if the signal parameter is set to m e .
The initSetup() method must contain code for consistency initiakation and is executed
only if the consistency parameter is set to m e . The method retuns false if consistency
initiaikation was not sucçessfuI.
The m() rnethod must contain code that implements the Receiver of the client. It should
listen and read incoming data and perCorm approp- action according to the messaging
scheme,
The destroy(), star?(). and srop() methods are automaticaiiy called by the Web browser
running the applet. &stroy() should contain some garbage collection instructions Like
closing the sockets, starr() is called every time the applet is displayed to the user- stop() is
caiied every time the applet is hid&n h m the user, for example when the browser is
For the applications that do not require access control, end() is used to incikate to the
Server end of message. When DataSerwr sees the end comrnand, it will lock the
OutputStream and send the message.
getMutex(l checks the status of the semaphore ninning on the server and requests a lock
on the application. It returns m e if lock is granred, fuke if lock request is denied,
releaseMutex() is used to unlock an appkation that is locked. Note that an application can
only be unloçked by the client that has locked it,
displayStatusO is used to show emr or other messages to the user. It uses the browser's
status bar to display theses messages.
5.2 JETS Prototype
The above API was used to develop a prototype of the JETS systern. Four applications
that form the basis of a virtual classroom were developed. These applications are
presented next.
5.2.1 Chat
The Cknt ckss was extended to create a chatting applet. Using this applet, a user can
send textual messages to o t k users as well as view other users' messages. In order to
distinguish which user is sending which message, aü users are asked to enter their name
into a text neld in the applet. Messages are sent by wrïting them iato the appropriate text
field and hitting the ENTER Ley. In addition, messages sent by othet users are displayed in
a text area in the applet Below is a pictore of the Chat applet:
USanmemfidd 1 o ~ m a r s ~ ~ f i d d ~
Figure 20. Tbe cbat appiet
As far as the server for the Chat appkt is concerned. the only extension to the Server class
was to indicate a port nurnber and a name for the server (Chat Server).
There is no consistency for this applet. Consistency could be used to present a newcomer
client with the past messages that have been exchanged; however, at the the of making
this applet, no need for such action was felt necessary.
Also, there is no messaging scheme for this appiet since only one message is sent: the
content of the textual message.
5.2.2 Shared HTML Documents
This appiet ( c a W URLFetcher in the code) enables one user to share an EITML
document with other users. This is done by the user entering the Universal Resoutce
Locator (URL) of the HTML document hto the appropriate text neld in the appkt (see
picture below). The applet then asks the browser to fetch the HTML document and
display it in the document m. AU other users wili a h see the same document as
rquested by the initiatot user.
Figure 21. Tbe üRL appk
This application requires consistency because new users shoukl be presented with the
current HïML document in the ftame. In this case, the Consistency class (called
URLSimulator in the code) is simply a thread that keeps track of the latest URL requests
by the last user. When a new user joins the session, this WRL is sent to the URLFetcher
applet at the initiakation stage through the initSetupO methods of the Client and the
Server.
There is no mess~tging schenie for this partiçular applet since there is oniy one piece of
information that is king sent: the URL of the target Hl'ML document.
5.2.3 Whiteboard
This applet allows users to simuitaneousîy draw on a boad No access control is
perfomed on this applet since it is O.K. for more than one user to use the applet at the
same time.
clac button Figure 22. The whiteboard applet
The Consistency object for this appkt is a thread that updates an Image object. The
messaging scheme used for this applet is shown in the table below:
TABLE 5. F&~AOING SCHEME OF- W ~ O A R D APPLFT
Message O
1
- Meaning draw line
clear board
Fdlowed by ( ~ 0 , yO), (x, y) ~~pn=mting coordinates of the line, plus (r .g, b), representing the color of the line
-
5.2.4 VRML viewer
This applet dows sharing of 3D objects in VRML format. This applet requires both
access control and consisteocy. Access control is needed to ensure that only one user is
interacting with the object at a t h . Without access control there is sipifkant risk of
conflict between users' actions.
One feature of this applet is the abiiity to show different 3D objects as requested by users
as opposed to just one 3D object. Users can choose one of the many 3D nles presented in
the applet's 6ie choice menu and fetch that fde (see figure below).
Figure 23. The VRML viewer applet
It shodd be noted that the 3D rendering and display of the applet was part of the
WieFrame demo appiet distributed by Sun Microsystems as part of the Java Development
Kit 1.0.2 (JDK 1.0.2) [9]. That dem presents an applet that can dispiay 3D files
represented in Wavdhnt (.obj) format The code was SigninCany changed to add the
following capabïhties:
double buffering to mate smooth motion;
complete navigation: move. mtate. zoom; as opposed to only rotate
parsing of VRML (.wd) fües;
displaying multiple 3D fîles (one at a the).
The applet is iïxnited to wire-6nune display of objects. However, the goal here was not to
build a complete VRML browser as that is a very lengthy and complex procedure that is
done by computer graphrs speciaüsts and is beyond the scope of this thesis. An already
developed VRML browser that mns as a Java applet such as muid Reality6 [14] can be
used for that purpose.
The Consistency cIass for this applet (called VRMLSimulator in the code) contains the
following data:
a 3x4 geornetric rotation ma&;
a 2D coordinate pair,
magnifïcation factor;
name of current VRML fde in use.
At initialbation tirne, the initSetup0 method of the VRML server will fetch these
information to the new client. WhiIe performing this initiabation, the application is locked
Liquid M i t y is a VRML 2.0 cornplient browser ibat ruas as a Java applet inside Web bmwsers. It is developed by Dimensioa X corporation.
to make sure no changes are made durhg the initiakation process. If a cknt has already
locked the application, the initialiration will be suspended until the lock is ~ieased.
The messaging scheme used for this applet is show in table 5.
TABLE^. ~ A G I N G S C H E M E O F ~ ~ A P R E T -
It is intereshg to note that there is the possibiiity to send certain messages to only the
Message O 1 2l magaification factor 3 - net new VRML nle
Consistency object. This is done by not handling that message in the runo method of the
1 a string containhg the URL of the VRML N e
applet. SimiMy, one could send messages that are ignored by the Consistency O bject. if
Meaning interaction change navigation mode
1 oniy picked up by the Coasistency object
ever needed. This is done by not handluig ihat specifïc message in the nino method of the
Fdlowed by (K y). representing the piesent location of the mouse k w a k L=rotate. 2=zoorn
Consis tency object
It shouid be noted that the VrmlSimuiator does not fetch a new VRML file when the
applets do so. The m o n lies Pi the implementation of the VRML viewer. When a new
file is loaded into the viewer, the rotation m a t e and the cootdinates of the object don't
change. That's why message 3 is not picked up by the Consistency object. What does
change is the magnifkation factor which is sent to the VnnlSirnulator by message 2 and is
not picked up by other applets.
In addition to the reguiar Ciient applet pararneters, the VRML appiet takes a ''fiie" and a
"scale" parameter. The file parameter contains the names of the available 3D nles, wMe
the scale parameter indicates the initial magnification of the VRML object.
5.2.5 The Client Interface
The foiiowing picturie is a sample screen shot of a typkai tek-Ieaniing session
incorporaring a i i of the above sample applications:
Figure 24. A sampie telelearning session ~ ~ h g in the Netscape bro&
As one can observe h m the above pictuce, each applet is individuaiiy located in a
separate browser fiame. Although not aU the Web browsers support frames, the ones that
are Java-enabled do support &ames; therefore, there is no risk of loosing potential users.
The main advantage of using frames is chat new ones can be added and old ones can be
modined or deleted with little effort, makmg it easy to introduce new applets- This
faciltates the maintenance of tbe system, Tbe fiame krmhy for the session in figure 23
is shown in the diagram below:
viewahme
Figure 25. Frame hierarchy of UK FITML doamienrs
For the HTML code of the individual h e s , as well as the applets' HTML documents
Chapter 6. Performance Evaluation
The performance of the JETS system was tested using both subjective and objective
methods. The tests were conducted in two areas: pe~+onnance of the clients on différent
platforms, and performance of tbe servers over d B e t netwodrs, namely Intemet and
ATM.
6.1 Plaîform Issuas
The performance of the system was tested on severid different platfonns. Parameters such
as user interaction, screen-updating speed, and ease of use were tested in a subhtive way.
The server was launched on a SUN Sparc 20 machine with SoIaris 2.3. The k t results
occurred for the most powerfd machines, of course. The system was tested with Netscape
Navigator 3.0 on the foliowing machines on local Ethemet:
SUN Ultra 1 with Soiaris 2 5
SUN Sparc 20 with Solaris 2.4
Pentium 100 MHz PC with Windows 95; two browsecs:
Netscape Navigator 3.0 by Netscape corporation
Internet Explorer 3.0 by Microsoft corporation
Apple Power PC
Apple68OOO
The foiiowing discussion is based on user's point of view and not on objective
performance tests:
The best performance was seen on the S U N Ultra machine. Using Netscape Navigator 3.0,
a tele-leaming session was launched, The performance of the appiets was very good. Both
drawing on the whiteboard and interacting with the 3D ob&ts were quite smooth.
Sending messages and requesting M"ML nles were as ceal-tùae as it can be. Also. the
graphical behavior of the browser and the axeen-updatïng speed were very satisfactory.
The second best performance was seen on the Pentium 100 MHz PC with Netscape
Navigator 3.0. Aîthough the interaction with the 3D object was a little bit slower than the
SUN Ulm case. the pedomance was quite similar to that of the SUN Ultra.
There was a problem with ninning the system with the Intemet Explorer browser on the
Pentium machine. Each of the appiets ran in the Intemet Explorer with no problem;
however, when the system was m as a whole with aU applets, always one of the applets
was not working. Afkr some investigation, it was discovered that there is a Iùnit for the
number of network connections opened by the Internet Explorer browser at the same tirne.
Because of this limit, oniy four network connections cm be made at a the. Interestingly
enough, it was found out that Netscape corporation was accusing Microsoft corporation
of having deliberately created this iiznit to prevent the execution of some of Netscape
corporation's software!
The SUN Sparc 20 machine carne in next, with considerably slower yet acceptable 3D
O bject interaction. Also, the drawing and screen-updating operations were a bit slower
than the above two cases. The chat and shared HïML applets performed very well
Overall, it gave an acceptable level of user interaction and perfomance.
Slow performance of the system was o b s e d on the Power PC Macintosh. Although the
test is subjective and dEers from person to person. it is safe to Say that the interaction
with the 3D object was slow. pst around user toleme leveL Drawing and screen-
updating was not any better though the performance of chatting and HT'ML sharing
applets was acceptable. One "annoying" pmperty of Netsçape on the Power PC Macs was
the fact that every cime the user ca&s the browser while the browser is downloading the
applets, the browser reloads ail the applets again, even if there were only one more class
or file left to download. This çreates a lot of delay, specially for a hasty user.
The worst performance was seen on 6 8 0 M y Appk computers. This of course was
expected after observing the slow performance on the Power Macintoshes. in this case,
the screen-updating speed as weiî as 3D object interaction was unacceptable; although the
shared-HTML and the chatting applets gave an acceptable performance.
The lack of good performance on the Macs in generai is rnainly due to the implementation
of the Java virtual machine for Apple computers, The current implementation is slow and
not suitable for ai i d - t i m e appiets. Better hplemntations, including JITs for Mac, are in
the development phase and should be expected in the near future.
6.2 Network Pedonnance
The system was tested on both local and wide-area networks and for both ATM and
regular Intemet connections. ATM had a very good performance compared to the Intemet
for the non-local network case; it ais0 p e r f o d a iittie bit better than local Intemet for
the local network case.
Besides the subjective testing of the JETS sample session, a test applet was designed to
rneasure the effective client-to-client deluy (CCD) of the system. This is denned as the
average time it takes for a byte of data to reach a target client from an initiating client, Just
a retninder that the data has to go through the JETS server to mach the target client. The
test is performed as follows:
There is a Sender and a Receiver applet. The Sender applet sends a byte of data through
the data channel, the Receiver acknowledges the receiving of the data by sending a byte of
data through the data channeL The Sender, afier receiwig the acknowledgment, sen&
another byte of data, and so on. The procedure is run for a cime t, which is adjustable by
the user. If there are n bytes of data sent and acknow1edged in tirne t, the CCD is:
It shodd be noted that the CCD test r d will not only be an indication of the
transmission speed of the underlying network, but atso an mdication of the end-to-end
dehy of the entire system including dekys caused by the underlying layers such as
transport Iayer, network layer, ATM or LAN data= layers, and so o n The Java code for
the Sender and the Receiver appkts is presented in appendix B. At the MCRLab, the
JETS prototype was tested on both Ethernet and ATM backbones as show below:
Figure 26. Local network amfiguraiion of ibe clients and Ihe server
The server was mn on a SUN Sparc 20 wockstation with two clients, one running on a
SUN Sparc 20 and the other on a SUN Ultra machine; both using the Netscape Navigator
3.0 browser. The Ethemet network was of type 100BaseT. capable of 100 Mbps transfer
of data The ATM vansport was provideci by a Vivid Workgroup ATM switch with OC-3
(155 Mbps) links.
Subjectively, no practical Merence between ATM and Ethemet was observeâ and the
system seerned to have the same performance on both netwocks. In order to cletetmine the
exact end-to-end delay. the CCD test was prformed for three cases: local Ethemet, local
ATM, and non-local ATM.
The network configuration for local ATM and local Ethemet was show in figure 26. For
the non-local case, OCRInet was used to establish a JETS session between the MCRLab
and the COBRAnet labotatory at Nortel. Figure 27 shows the network layout of OCIUnet,
Figure 27. OCRlnet Layout
First, the CCD test was performed for the two clients at the MCRLab on Ethemt. Then,
the test was perfonaed for the same clients over ATM. F i y , the same test was
performed between a SUN Sparc 20 client at the COBRAnet laboratory and one of the
clients at the MCRLab. using the same server as for the previous tests. Ail tests were run
for a 15 minute duration. The resdts are shown in the foilowing table:
(nrpcc) (insec/byte) I
Ethernet 8763 900044 51.33 local ATM 8850 900005 50.85 nodocal ATM 8786 900001 5 1-22
Examining the above numbers, one can tealme why subjectively no difference was felt
between local ATM and local Ethemet. The end-to-end delays are very close; though
ATM does have faster pecfomance.
It should be noted that al l of these results are for very small packet sizes. There is no
question that ATM would perfonn far better than Ethemet for larger packet sizes. To
iliustrate this, P's ping utility was used to test the end-toend delay between the two
clients on both Ethemet and A m - The result is shown below:
Flgun 28. Ping Timo of Ethanet vs. ATM
The above plot shows that performance âiierence between the two local networks is not
very signincant for s d packet s k of approximaiely 0.5 Kbytes and srnailet. At packet
si= of approximately 2 Kbytes or larger, the clifference becomes signifcant.
The ultimate endpoints of communication are the human perceptions and the braui's actual
perception of sound. motion, and pictpries. For humans. the end-to-end letency has an
upper bound for acceptabiiity. For interactive audio this lunit is rooghly 100 ms 1181. The
following parameters were reîeased by the Multimedia Communications Forum W C F )
as a guideline for multimedia QoSClq:
TABLE 8. SOME QOS PARAMEIERS PUBWSHED BY MMCF.
Differentiai delay is the dinerence of arriva1 times between two media. The DSDlaudio
differential delay (msec) DSDVaudio differentid delav (msec)
delay is the parameter of interest for this research. It States the maximum differential delay
CIass C (high quality) a
b e e n 100 and 150 AudioNideo
between audio and user interactions. For example, when a user rotates the 3D object and
less than 1 0
says "now I'm rotating the object". the ditFerence between the tirne that his voice arrives
Class A (low quality)
N/A
and the tirne that the rotation message amives at the other cîients must be within the
Class B (medium qaalïty)
berween -40 and 2ûû
less than 20
DSD/audio panuneters.
, less than 100
For the JETS prototype, since the CCD i9 about 50 msec, the DSDIaudio parameter is met
for any kind of audio conferencing tool and for the highest quality (class C). The reason is
that even if the audio conferencing tooL to be used in conjunction with JETS. would have
a theoretical end-to-end deiay of O msec, the differential delay would be 50-0=50 < 100.
Hence, it c m be concluded that the JETS prototype cunning on local networks, either
DSD: Delay Sensitive Data. refcrs to data including pointers, conuoi, and echoplex iofomiation.[l6]
83
ATM or Ethernet, bas a sacisfactory performance and works well wirhin the tequired
parameters. This is also iùe case for ATM wide-area netwodÉs.
Due to security reasons at No&, no tests c o d be perfonaed between the MCRLab and
the COBRAnet laboratory on non-ATM netwo*; ie. the regular Intemet. Nevertheless, it
is O bvious that reguiar Interriet will @om drastically slower than ATM when it comes to
wide-area networks.
Anotkr interesthg performance issue is the CPU utihtion of the system, To measure
that, the VRML applet was tested with one, two, and up to 5 cknts. The CPU utiüzation
of the server was always bdow 2%. So, it turns out that the number of open sockets on
the server machine are m m Mitical uian the CPU utilization.
Chapter 7. Conclusion
The aim of this projeçt was to theorettcalty design an practicaiiy hplement a complete and
iünctional teleIearning environment tfiat is accessible by users on the Intemet with
minimum amount of user-software. It is imperative to be seamlessly interoperable with
currentiy existing and widely used technologies and standards to ensure the accessibility of
the system to the broad ducation community. In the development process of the JETS
system, this accessibility was achieved by a number of design decisions:
First, the VRML standard was deployed for the format of 3D objects. Though at its early
stages, VRML has becorne the most populat 3D standard on the Internet. Using VRML
further ensures the accessîbîiity of the system, But VRML is more than just a 3D standard.
It is envisioned as a virtual reaiity standard that will eventudiy address ail the VR issues
such as rendering, networking, perception. and so forth. Using VRML, one can create
complete virtual environments that include 3D objects and other multimedia content,
Hence, the decision of using VRML for the JETS system was not only made to ensure
interoperability with existing standards, but ais0 to facilitate the development of the next
versions of the prototype, since advancements in VRML would translate to advancements
in JETS.
Next, HïML was used as a standard for advanced documents. Perhaps this choice is the
most obvious one. Practically aü documents on the Web are written in HTML. By
sup porting HTML browsing, the huge number of already-developed HTML documents
c m be d k t l y integrated and viewed with JETS. In addition, since the systern uses the
HTML browsing abiiity of the web browser, any future enhancements in HTML that is
supported by web browsers wili autornaticaily be supported by JETS. Like VRML, the
development of HTML has also not reached its end yet and is constantiy improving.
Then, the use of Java a p p k to provide appiication kvel services to the users ensures that
any Internet user equipped with a Java-enabkd Web browser bas access to the system.
Other than -hg the oser h m the mponsibiiity of downbading and ùistaiJing software
and plug-ins, this approach utiihes a new concept in networked computers: let the
application fhd the user and not the user find the application, as was the case traditionaily.
Furthemore, Java bytecodes can run on not oniy Web browsers and computers, but also
simple network devices or mobile devices such as ceiîubr phones. tekvisions, network
terminais, and so on. This means that the system wül st i i l be interoperable with
tomomw ' s technologies withou t drastic rnociifications.
The other major advantage of using Java applets is the fact that they are platforni-
independent. This was in fact one of the properties that we were looking for to use for the
telelearning systern. Platforni-independence rnay not be cruciai for other types of
coilaborative environmentis; bat for a teieieaming system, it becornes essential simply
because of the large number of users.
However, there is a price to pay for this platfom-independence. Java applets are
contained within a very restricted environment in order to prevent possible rnalicious
actions perfomed against users. These restrictions 1 s t the iesearcher in tenns of the
number of approaches that can be used to corne up with a multi-user engine. For example,
because of networking restrictions, a compietely distributed system is not possible. There
simply must be a cenvalized server and any communication between the users must be
handled through this centralized server. Also. any kind of Ne manipulation on the client
side is prohibiteci; therefore, if an application absolutely must operate using nles, it has to
do it on the server,
These are some of the restrictions that enforce us to use a centralized secver approach
Now, it must become clear what kind of service the clients need h m the server. The two
major demands of muiti-user systems are collsisfency, whkh ensures di clients are
presented with the same uifonnation, and s f ~ g g contml, which restricts mociïfïcation of
documents by clients. Hence, the= are four types of multi-user applications:
need only consistency. like a shared whiteboard;
need only access control, Wre rnodifyùig a database;
need both, like a 3D viewer;
need neither, like a chat session.
It is not oniy important that these services be provided by the semer, but also that different
applications be able to choose which service they ne&. It would be illogical to provide
access control for an appiication that doesn't req* access controL The probiem with
some of the existing client-semer models is that the server provides for some sort of
message passing, and the rest of the services most be handled by the appiication developer;
Le., the clients must take care of hem. The JETS server supports both consistency and
access control so the clients can assume that the information they have is consistent. Aiso,
using access control a ciient can be sure that there is no conflict between its users actions
with other clients' user actions.
The JETS server provides consistency by cunnhg a version of the client that does not
display any graphies, receive or send any signals, or send any data The advantage of this
approach instead of running an exact copy of the ciient is saving resources and processing-
power. Since no one will ever see the consistency object which runs on the semer, it
would be wasteful to cun a complete copy of the client for that purpose.
Access contml is provideci by means of a semaphore, Any client cequiring to mod@
something that needs access control must request a lock on the semaphore. Depending on
whether or not the semaphore is aiready locked, the client's request will be granted or
denied. Mter petforming the modincations, the client releases the semaphore.
Although very important for a multi-user environment, consistency and access control are
not the only services that clients need, The semer must also exchange messages among
clients. The JETS sewer provides that service in a highly real-tirne fashion, There is one
rd-tirne thread mnning for each client, called the DataSemer, that listens for messages
from that client. When a message is received, the DataSemer relays that message to ai i
other clients. Since DataServers mn independently, different clients can send messages at
the exact same time. This is one of the major features of the JETS system.
The JETS system also supports signahg, which means clients can send control
information to the semer to request different services such as access to a semaphore. The
signals are sent through a different channel that the data; in addition, there is a real-the
thread running at the semer for each client that han& these signals. Separating both the
channel and the server thneads responsible for data and signals rnakes possible the ability
to send data and signal at the same time in real-the.
As one can observe, the JETS server is highly multi-threaded. In addition to the server, the
client is also multi-threaded. There are at kast two threads running that constitute the
client: a main body and a receiver. The sepiuation of the body of the thread from the task
of receiving and handling incoming data enables the client to respond to its user's
interactions at the sanie time that it is updating the application fiom the messages received
from other clients. Therefore, the client also behaves in a real-time manner.
Hence, it cm be concluded thaî the JETS system is a highiy multi-threaded system that
provides services in ceal-tirne. This notion was tested by the implementation of a
Using the above architecture, generic Server and Client classes were developed. They
were used to build specük sample applications: a whiteboard, a chat session, a 3D object
viewer, and an HTML viewer, The system was tested on local area network, both
Ethemet and ATM, and wide area ATM network The test results indicated that the
system is cornpliant with the MMCF requirements for the highest quality of service.
The prototype developed helped demonstrate that the system successfully works as
expected. It also showed that the design theory and architecture behind the system is vaiid
and imptementable.
There are several improvements that can be made to hrther inmeas the quality of JETS.
One improvement is to impiement the Server class using Ci+ language. Being an
interpreted ianguage, Java is stower that C++ in nature. Hence, if it is not mnnùig on
JAVAOS, whiçh is an operathg system devoted to run Java bytecodes, it wiü be slower
than its comportding Cct implementation. Ln order to be highly scalable, it is important
that the server be as fast as possible since it might be serving a huge number of clients.
Note that the impiementarion of the server in C++ does not take away the platform-
independenœ feature of JETS as the clients wiil still be Java applets.
Another improvement would be the introduction of Remote Method Invocation. Using
RMI, the clients can invoke raethods of other clients directly. This will eliminate the
developers need to corne up with a messaghg scheme. However, RMI will &O decrease
the system performance as it inuoduces some overhead in the communication process,
Currentiy, RMI is not part of the cote Java package. Consequently, using it at this stage
would drastically reduce che accessibiüty of the system as only people who do have RMI
wouid use the system. Furthermore, RMI does not work with Java applets becanse of
security reasons; although plans are underway to make RMI work with appiets. ûnce RMI
beconies avaiiable as part of the standard Java package and interoperable with applets, it
would be a good idea to evaluate the use of RMI in JETS.
in short, the JETS system is a successfiil experiment of designing an implementing a high
perfoma~ce multi-user system. king the ûrst platform-independent real-time teleieaming
system, it is at its early stages of development and can be used as an example for future
collaborative environments operationai through the World Wide Web.
References
[1] Ari Luotown, Kevin Altis, 'Wocld-\Ki& Web Roxies", '%np~/ePnfoSethzcNge~raltal infdWWW94/lstyh' , Apd 994.
[2] Arman Danesh, "JavaScripi". Sams.net Publishing. ISBN: 1-57521-0728,1996
[3] "Asynchronous Tnuisfer Mode (ATM)", ATM Forum. "http~/ww.atmfocurn.com"
[4] "Atiantis Cyberspace VR EquipmenSt, Atlantis Cyberspace, '6http~/vr-atlanoissom"
[5] David Fianagan, "Java in a Nutsheii". O'Reiliy & Associates Inc.. Califocnia, ISBN: 1-56592-183-6, Febmary 1996
[q GBlakowski and W. Steinbeck, "Hannonization of an riifrasauchire for Flexible Distance Leamhg in Europe with CTA", Proc. 2nd Intem. Workshop on Advanced Tele- services and High-Speed Communication Architectures, Heidelberg, Getmany, Sept. 1994.
[q H. Ohm and K. Habara, Wehind the Scenes of V h d Reality: Vision and Motion", Proc. IEEE, Vol. 84, No. 5, May 1996.
[8] 'TBM Network Station", JBM corporation, "'http~/~~~~intemet~ibm.comlcomp~~rs/networkstati~~~
W "Java Development Kit 1.0.2 APP', JavaSoft, "ht~://javasun.com/p~ucts/n>K~C~rrentReIdapir'
[LOI "Java RMI vs. CORBA" , JavaSoft Web site, "hnp://chatsubo.javasof~com/~~nt/f~.httnl#C0RBA"
[ 1 11 "Javascript", Netscape corporation, bbhttp:/home.netscapes~~II1/en~monlla/3.O/handbo~k/jav&p~
[12] "Java support in the Intemet Explorer", Microsoft corporation, " http://~~~.microsoEt,cod1e/ie3/javahmi~'
[ 131 Laura Lernay & Charles L. Perkins, "Java", Sarns.net Pubiishing, ISBN: 1-572 1- 030-4, 1996
[ 141 "Liquid Reality", Dimension X incorporated, '~http://www.dimensioll~~com/products/lrf'
[15J Mark Peste. "VRML: Browsing and Building Cyberspace", New Riders Pubiishing. 1w5
[ 161 Multimedia Communication Fomm hc., ''Muituriedia Communication Quality of Service", MMCF document, September 24,1995.
[17j OCRInet Web site : "hnp~/~~~..OCRInet.ca/~~nthorne.hunl"
1181 Olof Hagsand, "hlnteractive Muiti-user VE. in the DIVE System", IEEE Mdtimedia, pp. 30-39, Spring 1996
[19] "QuickTime VR", Apple Cornputer, "http~/quicIaimevr.appk.comf'
1201 "RealVR Traveler", RealSpace Incorporated, "hapd/wwwWWWrlspace.co~'
[21] "VRML 1.0 AF'I", The VRML Architecture Croup, "hap~//vnnLwid.com/vrml.tecMwmi 1 l l 0 ' .
[22] ''The VRML Repositoxy", San Diego Super Computing Center, "http~/msebud.sdsc.eddW'
[23] "VRML 2.0: The Moving Worlds Specifications", Silicon Graphies, "httpY/mLsgi.corn/moving-worlWsW
1241 'Web TV", Web TV NetwUrks (Sony/Philïps) , "httpY/www.web tv.neVP
[251 'What 1s Java", Sun Mimsysterns, "httpd~avasun.codaboutTav~rndexh~n1"
[26] W. Steinbeck, "ECOLE: Applyuig Multimedia at the Point of L,eaming-A distributecl Multimedia Environment for Fiexibie Distance Leaming", IBM European Networking Center, TR 94xxyy, 1994.
Appendix A: HTML code for the browser interface
session. html
left. html
right. h t d
url. html
chat. hbnl
<title>Paint <Ititle> capplet code=NerPaintcla~s width=3CK1 beighw275> <param namedport" rahiea6789'5 <param name="hostH ~alu~~maogo.genie.u~ta~ocaS <patam name="consistt?ncy" value=-falseW> dapple t>
Appendix 6:
Java and HTML Code of the CCD Test Applet
Bi. JavaCode
public class Sender extends Client{
TexfFïeld inputfield; TextArea outpu- long the; Date &te; booltxm go=false;
public void toit0 { supet.ioit0; GtidBagLaymt gb=new GndBagLayoutO; GtidBagConstraints gc=oew GtidBagConstraiatso; =davouQb); Label Il=new Label(Tme (mec):"); gc.f~=Gn'dBagCotls&aÏnts.NONE; g c . @ d w i d t h ~ d B a g C o m t t a i n t s ~ A ~ gb.setConstmints(l1, gc); *Ol);
inputtielâ=new TextFieldO; g~.f~dBagC~clsttaiats.HORIzONTAL; gc .gndwidiI ih=GtidBagCoasaaiats~E~ gb.setCaostraints(iiputfielâ, gc); add(iipurfeld);
public boolean ÛÛtSetupO ( tetum tme;
public void nmo ( Striog liae. ay(
fe3 ( i f (g0) l
intn=O; Dated=oew Dateo; long UdgetTmieO; whik ( (dgetTime0-tl)<time ) (
outwriteByte(1); while ( m.muiByteO!=l); n++; &aew DateO;
1 long t2=dgemmeO; outputareaappendText(n+" bytes exchangai in "i4-tl)+"
double cc+( t2-t1)/(2*n); oucputareaappendTextCCCD: w+ccd+"\n"); out.WnteByte(2); out.writeDouble(ccd); g-f*;
1 else Iry (Ttuead.sleep(lO0);) catch (InterruptedExceptim e) {);
1 1 catch (IOExœption e) (outpuiareasetText(e.toString0);)
1 1
Reciever
import javaawt*; import jarnio.*;
public class Reciever extends Client(
inputfield=aew TextField(" "1; g c . ~ d B ~ m ~ t s H O R I Z O N T A L ; gc-gxïdwid-dBagCoos-ER; gb.setCoosaaints(iipudield, gc); add(inputfield);
1
public boolean initSetup0 ( retm tme;
1
public void nmO { S triag Line; byte x=O; w (
fo&;) ( while ( ((x=in.readByteo)!=l) && (x!=2) ) ( ) //end whiie if (x=l) outwriteByte(l); e k if(x=2) {
double ccd=inJeadDoubIeO; inpudield.setText("CCDt: "+ccd-tn msec");
1 1
1 catch (IOExœption e) {oucputareasetText(e.WtriogO); 1
1
public class TestServerextends Server {
public TestServer(String name, iot port, int nmberoCiieots) {
public void initSearp(int Q ( int x=1;
1
82. HTML Code