next up previous contents
Next: TCP + RPC Up: Problems with WWW Previous: Introduction

Real Time

One key problem with the WWW model is how one can add real time media. Currently, the access protocol model is based on the libWWW RPC approach, where a retrieval is initiated by the request, and the client cannot start displaying the result until the return.

Clearly, if the returned data is very large, then this may be inappropriate (see below). However, if the returned data can actually be played as it arrives (e.g. it is audio or video or similar data) then this is clearly not the right way to do things. Netscape does this to a certain extent, but only so that it can interleave GIF and text rendering.

Two approaches suggest themselves:

  1. Allow a returned stream of data to be played as it arrives (this would in fact be a simple change to client programs and the way they launch display programs).
  2. Use a separate channel to return real time data

The latter approach is particularly inviting when one considers some of the ways Internet access may be provided in conjunction with CATV: It is quite possible to deliver broadcast quality TV down current copper twisted pair phone wire, up to modest distances, so long as one uses nearly all the bandwidth in one direction. So one could use a second, low bandwidth return channel for HTTP access, and return high quality TV to the client player. One can envisage other networks where bandwidth is asymmetric, or else there are other technical reasons to separate out channels for delivery of data requests and responses from real-time delivery (or transmission).



Jon Crowcroft
Wed May 10 11:46:29 BST 1995