mMosaic:
Yet Another Tool Bringing Multicast to the Web

Gilles dauphin
ENST Departement Signal
<dauphin@sig.enst.fr>

Abstract

mMosaic is a tool that allows to transmit Web pages using the Internet multicast protocol. mMosaic wish to be use interactivly like the Whiteboard. It is not a multicast httpd server. mMosaic don't solve any problem. It just try to be a new interactive multicast media.

mMosaic is based on NCSA Mosaic 2.7b4. Starting from the fact that NCSA Mosaic stores all the components of a Web page in memory, the idea is to reread the components and send them out via multicast. Thus, a sender can be implemented with minor changes to NCSA Mosaic.

On the receiver side, a browser listening to the multicast data only needs to rebuild components and shows the hypertext. This can be implemented with minor changes to NCSA Mosaic.

If you don't use the multicast option of mMosaic, you are near to use NCSA Mosaic. However some parts have been remove as WAIS, JPEG...

Sending datas

A Web page is composed of :

Before sending out the page, mMosaic reads it from memory once and parses the text. It then assigns a number to text parts, and to each embedded object. It build an extra object containing the email of user. Number 0, 1 and 2 are reserved for the URL, email and text components. If the component is too big (greater than 400 bytes) , it is split into packets, mMosaic adds a header (~ 35 bytes) to the packet and sends it.

The packet header has the following structure:

char code;           /* not useful but check. For future use... */
unsigned int ipaddr; /* to get Unique number */
unsigned short pid;  /* to get Unique number */
unsigned int url_id; /* url_id++ when change of page */
unsigned int gmt_send_time; /* Why not ? */
unsigned int nombre_eo; /* total number of embedded object */
unsigned int num_eo; /* the # of this object */
unsigned int seo;    /* size of object in byte */
unsigned int nombre_packet; /* total number of packet for this object*/
unsigned int num_packet;/* The # of this packet */
...data

The tupple ipaddr/pid forms a theoric unique number. gmt_send_time is not use.

A loop resends all data every 4 seconds to avoid lost packets. This is only in the prototype and the choose of a better solution is in progress.

Receiving datas

A loop listens to multicast data and stores it. When a new part of text is completed, mMosaic begins its work. It puts the text part in the HTML Widget. The text is parsed and a callback is run each time an embedded object (i.e an image) is found in the text. The parser used at the receiver is identical to the parser at the sender. The callback asks for an embedded object number. The called routine returns the full embedded object data, if data is completed, or any synthetic datas as broken image by example.

Each time a full embedded object is completed, mMosaic updates the screen.

How mMosaic works?

First, user use mMosaic as NCSA Mosaic. User get html page from HTTPD server or from a local html file.

Second, mMosaic silently multicasts datas. This enable mMosaic to send out private html page without an httpd server.

Command line multicast options

 -S sessionName the name of session (see sdr - future use)
 -M mediaName   see sdr (future use)
 -ttl ttl       the multicast ttl
 -a aliasName   your email
 -mcDest ipaddr/port    The multicast address/port from sdr.
         If you don't use this option, you run standard NCSA Mosaic.

What are new capabilities of current mMosaic version?

User example

Left part of picture shows the mMosaic window sender part. Notice the menu 'Multicast'. Clicking in 'Show Participants' poped up the 'User's List', in the bottom of picture. Clicking on a user in this list pop up a mMosaic window receiver part on the right side of picture.

Test result: What is good, What is bad

Preliminary tests indicate that mMosaic performs reasonably well when multicasting text (like slides) and little embedded object (like the W3C icon). It is very difficult to test this on large scale. We tested on our local network, with a Korean site (kybae@cosmos.kaist.ac.kr) with Germany (pfenning@thomaspfnt.microsoft.com) and USA (s253343@gettysburg.edu).

You wait a long time if object is too large. But I don't know how more long is it, versus a TCP connection.

Possible Enhancements and optimisations.

Related Projects

Acknowledgements


dauphin@sig.enst.fr
Update: 6 Sep 1996