Web Applets

One of the Big New Things in computer networks is the idea of Applets, programs which run inside the Web browser.

Applets can make Web pages dynamic. Forms and CGI programs allow some two-way interaction, but with applets this interaction can occur in real time. In principle, there is no restriction on what an applet can do - everything from simple animations to full featured spreadsheets and word processors - all within the browser.

An applet is specified in a Web page as (eg):

<APPLET CODE="spread.class" WIDTH=200 HEIGHT=100> </APPLET>
This reserves a rectangular space in the browser for the applet to execute in, then loads the applet from the server and runs it.

It is extremely important that applets execute in a secure way - ensured by the browser vendor.


Java

Virtually all applets are coded in the Java language, developed by Sun Microsystems.

Java is an object-oriented language with characteristics derived from C, C++, Pascal and Smalltalk. It has some weak aspects, but is generally regarded as a very good general purpose programming language.

Source code written in Java is compiled to a special form of binary executable file called bytecode. No (common) computer executes bytecode directly - it is the binary format for an abstract computer architecture, and is "executed" by a software bytecode interpreter.

A Java bytecode interpreter is built-in to most modern browsers. In addition, some browsers implement a Just In Time compiler, which converts the bytecode binary format into the format of the native processor on the fly, for much faster execution than interpretation, which is intrinsically slow.

Java programs are usually developed in a development kit, containing a bytecode compiler, standard libraries and a standalone bytecode interpreter (applet executor).

Finally, there is no reason why applets cannot be developed in other source languages once suitable bytecode compilers become available.


Network Computers

One of the most interesting recent developments has been the emergence of Network Computers. An NC is a machine which only runs a browser, such as a special version of Netscape - no operating system is used. Neither do NCs have a disk drive. The browser can be stored in ROM, but is more likely to be downloaded from a server on the LAN when the NC is started up.

Because an NC is running a browser, it can access any available Web pages, and can be used for normal database queries and updates using forms and CGI programs running on the server.

However, the real power of the NC idea comes from its ability to run Java (bytecode) applets. For example, in a conventional PC, a (eg) spreadsheet binary is loaded into memory from the hard drive, and used to perform some work. Data files are stored on the hard drive. On an NC, a spreadsheet applet can be downloaded from a server. Data files can be stored on the server.

The cost of the NC should be less than a standalone PC, and the cost of management of a group of NCs much less than PCs. Whether it is sucessful remains to be seen...

Also - see WebTV...


Networked Multimedia

In general, multimedia means the integration of text, still images, audio and video in computer presentations. As originally conceived multimedia was delivered on CDROM. One of the biggest challenges for the Internet is delivering real time networked multimedia.

The World Wide Web has support for most of what we usually consider as multimedia. Most of what is presented is only usable in batch mode - download first and play/view later. It is less successful in delivering real time content.

Rudimentary real time audio is available using highly proprietory products such as RealAudio. These systems use extremely clever encoding systems to allow quality realtime audio over low bitrate links.

The problem with systems of this kind is that the entire "bit stream" must be duplicated for each client who is currently listening. For example, if 10 people at Bendigo listen to a single "28.8kbps" RealAudio channel, a total of 288kbps must be sent over our link from Melbourne. A more clever system would send one copy of the "packets" to Bendigo, and then duplicate them.

Which brings us to...


Multicasting

The Internet supports multicasting using class D IP addresses.

A class D address represents a group of hosts on the Internet. A packet which is addressed to a class D address is (or should be) delivered to all hosts which belong to the group. This can be very efficient - on a LAN, for example, only one packet needs to be sent for all hosts. Some permanently allocated class D multicast group addresses are:

224.0.0.1 all-systems.mcast.net
all systems on a LAN
224.0.0.2 all-routers.mcast.net
all routers on a LAN
224.0.1.2 sgi-dog.mcast.net
Silicon Graphics dogfight game multicast net.
Temporary class D groups are created as desired. Multicast Routers (mrouters) communicate with other mrouters and with hosts on the local LAN using IGMP (Internet Gateway Management Protocol) and DVMRP (Distance Vector Multicast Routing Protocol).

The MBone (Multicast Backbone) is an experimental set of (many) mrouters connected by tunnels. Each mrouter serves a local LAN.

A full analysis of how the MBone operates is (far) beyond the scope of this unit.


The MBone

The greatest advantage of multicasting is that packets are only duplicated as necessary.

If a user at Bendigo desires to join a particular multicast group, she simply "asks" the local mrouter to supply the packets. The mrouter in turn talks to each mrouter that it has a tunnel to, requesting the packets. This continues across the MBone until an mrouter is found which "has" the desired packet stream. The packet stream is duplicated at this point, and delivered across the MBone to our user.

If another person on the same LAN as our user desires to join the same group, there is no extra overhead whatsoever. He simply picks up the packets as they go by.

Some multimedia activites which use MBone technology include:

This lecture is also available in PostScript format. The tutorial for this lecture is Tutorial #20.
[Previous Lecture] [Lecture Index] [Next Lecture]
Phil Scott