The mWeb Presentation Framework

Peter Parnes, Mattias Mattsson, KŒre Synnes, Dick Schefstršm
Department of Computer Science/Centre for Distance-spanning Technology
LuleŒ University of Technology, Sweden
Peter.Parnes@cdt.luth.se, Mattias.Mattsson@cdt.luth.se, Kare.Synnes@cdt.luth.se, Dick.Schefstrom@cdt.luth.se

Abstract

This paper presents a framework for bringing the MBone and the World Wide Web closer together by introducing real-time distribution of HTML-pages and synchronization of WWW browsers. This framework will enable distributed presentations of WWW material using the mWeb application. Distribution is done using two new protocols, Scalable Reliable Real-time Transport Protocol - SRRTP and Scalable Reliable File Distribution Protocol - SRFDP. Synchronization is achieved using the WebDesk Control Bus, which allows for scalable messaging in large groups of programs and hosts. This paper also presents how the mWeb application can be used for programmed presentations resulting in a television-like Web-TV. The mWeb framework also includes support for creating HTML-slides and the usage of semantic remote-pointers.

Keywords: MBone, WWW, distributed applications, distance education, Java, reliable multicast, semantic remote-pointers, group messaging

1. Introduction

The World-Wide Web (WWW) is today mostly used as a request application where the end-user tells a browser to fetch and display information. Imagine instead your WWW-browser being used as a broadcast-receiver (broadcast in the comparison to TV-program broadcasts and not network-broadcasts) where the user tunes into a channel and starts watching the HTML-pages being distributed there. This would add a real-time dimension to the WWW that could be used for distributed presentations and so called programmed presentations (Web-TV).

The until now experimental Multicast Backbone (MBone) [1,2] is today being deployed on the Internet as part of the real production network and more and more sites around the world are being connected each day. The MBone is being used daily for both one-way broadcasts of many different events such as concerts, conferences, lectures and tutorials and for multi-way sessions as distributed meetings, virtual worlds, games, multiuser chat/talk, and computerized surveillance. Although many tools exist, there is a lack of tools for scalable distribution of documents, such as WWW-pages, and synchronization of programs, such as WWW-browsers.

Many documents exist on the WWW today and many more are produced every day. It therefore seems very natural that these documents should be used in distributed presentations. The realization of a good tool for this purpose would add a new dimension, a real-time dimension, to the WWW.

The problem of creating a framework for using the WWW as a distributed presentation medium can be divided into two parts, a synchronization part and a distribution part. Synchronization relates to how to make all WWW-browsers within one session display the same page at the same time. Distribution relates to how the HTML-pages are distributed to all listeners in a scalable and efficient way.

The first part is solved by using a new Control Bus (CB) protocol [3] which is a messaging protocol based on a reliable multicast framework called Scalable Reliable Real-time Transport Protocol (SRRTP) [4]. SRRTP is an extended version of the Real-time Transfer Protocol (RTP) [5] which include the ideas from the SRM framework [6].

A simple solution to the second part would be to let each client fetch the data to be presented using the standard way of fetching WWW documents, but if the group is large this would create a very large burden and high latency on the HTTP-server serving that particular page. This simple solution does not scale to many members. Instead, a new protocol, Scalable Reliable File Distribution Protocol - SRFDP, for distribution of not only files but also meta-information about these files, is presented as a solution.

This paper also presents an application called mWeb that can be used for simple collection of presentation material, distribution of this material, synchronization of WWW browsers, and a new concept called programmed presentations or Web-TV.

An earlier and shorter version of this paper was presented in [7].

1.1 Related Work

At least two earlier attempts have been made to use the WWW as a distributed and synchronized presentation medium:

In 1995, Ed Burns presented his work on Web-Cast [8], a platform for sharing WWW documents over the MBone by either multicasting URLs or HTML-documents. It interfaced the WWW browser XMosaic [9] through the Common Client Interface (CCI) [10] and distributed WWW pages and corresponding inline images using the Reliable Multicast Protocol (RMP) [11]. Tests were conducted during the spring of 1995 which showed that the multicast distribution model used by that version of RMP was not suitable for wide-area-networks, because only the original sender of the data could do a repair of lost packets. In more recent versions of RMP the distribution problems have been solved.
mMosaic [12] is another tool for sharing WWW-documents over the MBone. It is currently being developed and is an extended version of the WWW browser, XMosaic. Initial tests show that mMosaic works well with HTML-pages and smaller images, but the distribution delay gets too large with bigger images. A drawback is that it's very tightly coupled to XMosaic.

Both these tools and other earlier Web-distribution tools are all tightly connected to the XMosaic browser. One of the main design-constraints on the mWeb application is that it should be browser independent.

Readers not interested in the underlying network-protocols might want to jump to section 3 where the mWeb application itself is presented.

1.1.1 Real-time Transfer Protocol (RTP)

The new protocols presented in this paper are based on the Real-time Transfer Protocol and the framework of SRM.

The Real-time Transfer Protocol (RTP) [5] is designed for real-time traffic over both Intra- and Internets. RTP functions include loss detection for quality estimation and rate adaption, sequencing of data, intra- and intermedia synchronization, source identification, and basic membership information. RTP is designed to operate on any kind of network-protocol and is therefore completely self-contained, meaning that it does not depend on any information in the lower levels of the network model. RTP is only implemented over IP/UDP today, but the protocol can be used on any type of packet-network, e.g. native ATM or ISDN.

RTP consists of two different protocols, the RTP that transports the payload data and the Real-time Transfer Control Protocol (RTCP), which exchange meta-information about the current session. The protocols operate on two separated channels where transmission is of 'best-effort' quality, meaning that packets can be lost without retransmission. All members on the RTCP-channel send regular messages about how much data they have sent (if any) and how well the data on the RTP-channel is being received. This information can be used to detect packet-loss and request senders to adapt their transmission-rates to the current packet-loss.

1.1.2 Scalable Reliable Multicast - SRM

Scalable Reliable Multicast (SRM) [6] is a reliable multicast framework for application level framing and light-weight sessions. The algorithms of this framework are efficient, robust and scale well to both large networks and large sessions. The framework has been prototyped in wb, a distributed white-board application, and has been extensively tested on a global scale with sessions ranging from a few to more than 1000 participants. The framework can be summarized by describing the three types of packets: heartbeats, NACKs and repairs.

Each member periodically sends out a heartbeat including the sequence number of the latest sent packet. These heartbeats are used by the other members to detect packet loss by comparing the sequence number in the heartbeat and the sequence number of the last data-packet received.
When a packet is lost, a negative acknowledgment (NACK) is sent to all members using the same method of transportation as the original data. As all members see these NACKs, everyone can participate in the repair of the traffic. This is important because it lessens the burden on the original sender and makes the repair process faster if the distance between the NACK sender and the original sender is large.
Each member of the session cache the latest data-packets received (and sent) and if they see a NACK for a packet they have in their cache, they retransmit that packet to the whole group as a repair.

To minimize the number of NACKs and repairs, these two operations are preceded by exponential back-off. This means that instead of sending the packet directly, the client waits for a random time (based on the distance to the related other party) and if another client sends a corresponding packet it withdraws its own potential transmission.

2. Reliable multicast

This section present two new protocols for reliable multicast and file distribution.

2.1 Scalable Reliable Real-time Transport Protocol - SRRTP

In [4] a proposed protocol, called Scalable Reliable Real-time Transport Protocol (SRRTP) is presented. This protocol incorporates the framework from SRM into RTP by extending both the RTP and the RTCP protocols. This provides a reliable and scalable protocol for services like wide-area file-distribution and messaging between applications. (Note that an earlier version, called DVRMP, of this protocol was presented in [13].)

All pseudo-random timers and back-off times in SRM are based on the distance to the originator or destination. The distance is calculated using the heartbeats and the round-trip-time it takes for a packet to travel between two members.

The added control messages (heartbeats, NACKs, time-stamp queries and replies (data needed for distance-calculations)) are sent using a new RTCP packet type. Each packet in a session is uniquely identified by the senders SSRC (a RTP-header field which is used to uniquely identify a member within a group) and the packet-sequence-number. This packet identifier is used when sending NACKs. To minimize the number of NACKs if several packets are lost from the same source, NACKs can be grouped together into one NACK-request.

2.2 Scalable Reliable File Distribution Protocol - SRFDP

SRRTP provides a scalable and reliable framework for distribution of data within a large group of members. Because SRRTP is based on packets, there is a need for a protocol for division of files into packets and control of file-distributions. This sections presents a new protocol called Scalable Reliable File Distribution Protocol (SRFDP), which is a protocol for distribution of not only single files but also groups of files and meta-information about these files.

Each process of distributing a file consists of three steps: deciding the meta-file-information, sending the header and sending the file.

The meta-file-information consists of information about a particular file. This information include the file-name, file-size, MIME-type [14] and the last-modification time. The last field is used by receivers to check if a locally cached copy of the file should be invalidated. This information is also referred to as the header.
The second step is to send the file-header to notify the members of the group of the upcoming file-distribution.
Finally the file itself is distributed using SRRTP.

Several headers can be grouped into an special index-file, which is used by clients to identify the files available from one sender within the session. Index-files also contains information about current file-distributions. Several index-files can be available within one session if several senders are offering files.

A typical client-scenario would look like this; the client joins the session and requests the index-file. If he does not receive any index-file (no one is offering files), he waits until an index-file is offered. After receiving at least one index-file, he selects the files of interest and requests that these files will be distributed. Before any request, he applies exponential back-off to check that no-one else is also requesting the same files. For instance, if the session was recently announced several clients might join the session and at the same time requesting the same information. He also checks the current traffic-flow for any active file-distributions. If a file he is interested in is already being distributed, then he saves the part of the file currently being distributed and when the end of the file is reached he requests the missing parts as if they where lost.

2.3 SRFDP and SRRTP

In SRRTP, the NACKs were based on the packet identity. SRFDP extends this to allow NACKs based on a file-name and a byte-offset within that file. This can be used by a client to request a particular part of a file, without having to know the current packet size being used.

Furthermore, the time-stamp in the RTP-packet header is constant (the time of when the first packet is sent) on all packets related to the same file distribution. This allows for several files to be distributed from one sender at the same time within one session.

3. The mWeb application

The technology represented by SRRTP and SRFDP have been deployed in an application called mWeb. This application includes functionality for distribution of HTML-pages including in-line data and embedded objects, pre-caching of files to be used within a session, on-demand fetching of files, synchronization between browsers and interfacing different WWW-browsers.

As described in the introduction, the problem of adding real-time distribution of HTML to the WWW could be divided into two parts, synchronization and distribution. This section discusses the architecture of the mWeb application and how these problems have been solved in mWeb.

3.1 The architecture

The mWeb application acts as a gateway between a WWW browser and the MBone, mediating distribution of HTML-pages and display-messages (see section 3.2). The application can also run in a light-weight mode where only the URLs to be displayed are multicasted. This is useful in smaller groups.

Figure 1 displays the interface of the mWeb application.

Figure 1. The mWeb application.

HTML-pages to be displayed during a session can be collected in three ways:

URLs to be displayed, including URLs to any inline data, are specified manually in a file by the presenter. This file is then used by mWeb.
URLs are collected dynamically during a presentation using a browser that supports the Common Client Interface (CCI) [10] (currently only supported by the XMosaic browser). This means that whenever the presenter selects a link or change HTML-page (for instance using the history in the browser), information is sent from the browser to the mWeb application.
URLs are collected dynamically during a presentation using the special mWeb WWW-proxy that sends information about the requested pages to the mWeb application. This is achieved by telling the browser to request all pages through the proxy, instead of fetching them directly. Unfortunately this creates problems when using HTML-frames as mWeb interprets this as several quick request (an HTML-frame-page consists of several HTML-files). To solve this, mWeb tries to guess that it is a frames-page based on the URLs requested and the time between the requests. Another way of solving this would be to let mWeb parse each requested HTML-file and take proper actions when a frames-page is encountered but the gain doesn't justify the overhead.

The last two methods can also run in so called cache-mode, meaning that the presenter makes the collection of URLs to a file, before the actual presentation is held. This file can then be edited by the presenter to add or remove URLs. This is useful if a page to be displayed contains an embedded object, such as Java-applets (see section 3.4).

When the presenter is finished with his page-list, he tells mWeb to start distributing the pages using SRFDP. Each listening client will cache the files locally and wait for the presentation to start. On user request, information about the current transfers can be displayed.

During the presentation a pop-up-window containing a list of displayed pages is shown (see figure 1). At the presenters side this list will contain all the pages but on the listeners side only pages that have already been displayed are listed.

3.2 Synchronization of WWW browsers

When a presentation is distributed over the MBone and a WWW-browser is used for presenting the slides, there is a need for synchronization between the involved WWW-browsers, meaning that all browsers display the same page. This is solved by sending a display-message to all members of the group using the WebDesk Control Bus (CB) [3,15]. The CB protocol is a messaging protocol used above SRRTP which provides a simple way of exchanging messages both internally within an application and between several distinct applications.

During the session, the listener can select what shall happen when a new display-message is received: display the new page directly, display a dialogue asking the user what to do or just display in the page-list that a new display-message have been received.

If a listener wants to go back and take a look at an already displayed page, he can select the page of interest in the list over displayed pages. He can also instruct the local mWeb client to send a display-message to all other listeners including the presenter. This is useful if the listener wants to comment or ask a question related to a page that is not currently displayed.

3.3 Interfacing WWW browsers

Incoming documents can be sent to the browser in two ways; using an fictive 'file'-URL or through an HTTP-proxy:

In the first method, mWeb would save all received pages and data on local disk. If the name of the file contains one or more '/'-characters, a relative directory-structure according to the name will be built. This allows for relative links to sub-directories to be resolved locally. When a page is to be displayed, a fictive URL with 'file:' as the protocol-part pointing to the local cache is constructed and the browsers is instructed to display that URL.

In the other method the user is asked to change her browsers proxy-setting to point to the local mWeb application. When the browser is requested to display a certain URL, it will connect to the local mWeb and receive the page locally without transferring it over the network from the original site. This is more elegant than the first method but puts a larger burden on the end-user who must know how to configure her browser.

In both methods, if a requested page is not found at a client during the session, mWeb will request that page.

3.4 Embedded and In-line objects

It is easy for a program to scan an HTML-page for references to inline images as these are stated clearly in the file, but it becomes more complicated if the page contains embedded objects, such as a Java-applet. A reference to an embedded object only points out the first element of what could be a complex program. In the Java-applet case, the applet can fetch more data in two ways:

Classes (program-parts of the applet) are fetched from the same source as the main-class (the one referenced in the HTML-page) so if the Java-applets main source is local disk, requests for additional classes will be serviced locally.
Other data can be referenced in any way the applet programmer sees fit, so special care has to be taken by the programmer on how the data is referenced if the applet is supposed to be copied to other sites using mWeb.

3.5 Members

Member information can be displayed in a pop-up-window during a presentation (see figure 2). This window also contains information about whether all listeners have acted on a display-message and are displaying the same page. This gives the presenter feedback on the current situation within the group. Further information, as email-address, phone-number etc, about each member is also available.

Figure 2. Current members of an mWeb session.

3.6 Remote pointers

A presentation system must include some sense of remote pointers where a presenter can use his mouse to point in the slide when talking about it. A major problem, is that an HTML-page might look very different depending on the display (resolution, fonts) and the browser (kind of browser, width of the browser-window). This excludes an pixel-based remote-pointer model and instead introduces the need for a semantics-based pointing where the presenter selects one of several predefined pointing-points. This has the consequence in that the HTML-page itself must be extended in some way. Two simple solutions are available:

Let mWeb modify the HTML-page to include special mark-up images that point out a special location in the page, for instance an item in a list. When the next point is to be selected mWeb instructs the browser to reload the page which then will have changed.
Insert special pointer-applets at certain points in the HTML-page. A pointer-applet is an applet that displays different images depending on some kind of external input. These applets connect back to the mWeb application, which controls the display of images in each applet. On the presenters side the applets get their input from presenter, send this information to the local mWeb which in turn sends CB-messages to the rest of the group.

The second method is much more flexible and faster as the page does not have to be reloaded between each pointing-event. This method is used in mWeb.

3.7 Creating slides

Although there are several HTML-editors available today, none is "slide-based", helping the end-user to create a set of HTML-pages to represent an presentation.

The mWeb framework contains a simple program for creating several HTML-files from one larger HTML-file. Each of the created HTML-files contains a predefined header and footer and buttons to link the pages together. The program also creates an index-overview over all the slides.

3.8 Programmed presentations and Web-TV

Although this paper focuses on distributed real-time presentations, the mWeb application can be used in so called programmed presentation mode where the presenter instructs mWeb to send display-messages for a set of URLs at certain times. This can be used to create a television-like system where the receiving browsers display a group of pages. We call this functionality Web-TV. This functionality could be used for dissemination of information within one group of listeners, for instance to spread important information within a company or organization.

4. Implementation and Status

The mWeb application and its underlying protocols are all currently being implemented using the Java language [16].

WWW browsers currently supported are Netscape Navigator [17] under X11 and Windows and NCSA XMosaic [9]. Although the Java-language itself is platform independent there is no platform independent way of interfacing WWW browsers.

Further information about the status and implementation of mWeb can be found at [8].

5. Summary and Conclusions

This paper has described a new application, the mWeb, and a framework for scalable and reliable distribution of HTML-pages and their in-line data to a large audience. The mWeb allows for easy creation of WWW presentations, scalable distribution, local caching, on-demand fetching of data and synchronization between World-Wide Web browsers using the WebDesk Control Bus. The mWeb can also be used to create programmed presentations resulting in a Web-TV framework.

Distribution of the data to be displayed is done using two new network protocols, Scalable Reliable Real-time Transport Protocol (SRRTP) and Scalable Reliable File Distribution Protocol (SRFDP). SRRTP creates a scalable and reliable distribution platform for real-time data by adding the ideas from the SRM-framework to the Real-time Transport Protocol (RTP). As SRRTP only supplies a platform for reliable distribution of data, SRFDP adds a framework for grouping of files and distribution of meta-information about these files. The meta-information includes at least information about the names and the MIME-types of the files.

These new protocols and the mWeb application brings the WWW and the real-time MBone closer together and makes the distance to a true real-time WWW shorter!

Acknowledgments

Thanks should go to Ulrika Wiss and R.P.C. Rodgers for interesting comments and all nice encouragement.

This work was done within Esprit project 20598 MATES, which is supported by the Information technology part of the 4:th Framework Program of the European Union. Support was also provided by the Centre for Distance-spanning Technology (CDT).

References

The MBone information web, <URL:http://www.mbone.com/>
S. E. Deering, Multicast Routing in a Datagram Internetwork, PhD Thesis, Stanford University, Dec. 1991.
P. Parnes, Control Bus Specification, 1996, <URL:http://www.cdt.luth.se/~peppar/docs/>
P. Parnes, Scalable Reliable Real-time Transport Protocol - SRRTP, work in progress, <URL:http://www.cdt.luth.se/~peppar/docs/rtp_srm/>
H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A Transport Protocol for Real-Time Applications - IETF RFC1889, January 1996.
S. Floyd, V. Jacobson, S. McCanne, C. Liu, L. Zhang, ``A Reliable Multicast Framework for Light-weight Sessions and Application Framing'', ACM SIGCOMM'95
P. Parnes, M. Mattsson, D. Schefstršm, K. Synnes, mWeb: a framework for distributed presentations using the WWW and the MBone, W3C workshop RTMW, 1996, <URL:http://www.cdt.luth.se/~peppar/progs/mWeb/>
WebCast - Collaborative document sharing via the MBONE, <URL:http://www.ncsa.uiuc.edu/SDG/Software/XMosaic/CCI/webcast.html>
NCSA Mosaic for the X Window System, <URL:http://www.ncsa.uiuc.edu/SDG/Software/XMosaic/>
NCSA Mosaic Common Client Interface, <URL: http://www.ncsa.uiuc.edu/SDG/Software/XMosaic/CCI/cci-spec.html>
Reliable Multicast Protocol, <URL:http://research.ivv.nasa.gov/projects/RMP/RMP.html>
mMosaic Information, <URL:http://sig.enst.fr/~dauphin/mMosaic/index.html>
Network Support for Scalable Distributed Multiparty Virtual Reality, <URL:ftp://cs.ucl.ac.uk/darpa/dvr.ps>
N. Borenstein, N. Freed, MIME (Multipurpose Internet Mail Extensions) Part One and Two, IETF RFC1521 and RFC1522, September 1993
P. Parnes, D. Schefstršm, K. Synnes, WebDesk: the Collaboration Support in MATES, First European Workshop on Global Engineering Network, 1996, <URL:http://www.cdt.luth.se/~peppar/docs/>
JavaSoft Inc., Java, Technical Report, 1996, <URL:http://www.javasoft.com/>
The Netscape Navigator, <URL:http://www.netscape.com/>
The mWeb application, <URL:http://www.cdt.luth.se/~peppar/progs/mWeb/>

Return to Top of Page
Return to Technical Papers Index