High-performance telepointers

Abstract

Although telepointers are valuable for supporting real-time collaboration, they are rarely seen in commercial groupware applications that run on the Internet. One reason for their absence is that current telepointer implementations perform poorly on real-world networks with varying traffic, congestion, and loss. In this paper, we report on a new implementation of telepointers (HPT) that is designed to provide smooth, timely, and accurate telepointers in real-world groupware: on busy networks, on cable and dialup connections, and on wireless channels. HPT maintains performance at usable levels with a combination of techniques from multimedia and distributed systems research, including UDP transport, message compression, motion prediction, adaptive rate control, and adaptive forward error correction. Although these techniques have been seen before, they have never been combined and tailored to the specific requirements of telepointers. Tests of the new implementation show that HPT provides good performance in a number of network situations where other implementations do not work at all -we can provide usable telepointers even over a lossy 28K modem connection. HPT sets a new standard for telepointers, and allows designers to greatly improve the support that groupware provides for real-time interaction over distance.

Improving network efficiency in real-time groupware with general message compression

“…Examples include model-layer updates, telepointers, streaming multimedia such as voice or video, system-level control and feedback messages, text chat, and session-management messages. Different message types have different characteristics, but two main groups can be considered [5]: transactions concern longer-term changes to the system, such as modifications to data structures or lock requests, and are usually infrequent; streaming messages are much more frequent, and provide information about the transient state of a user's activity or communication. An important further distinction within the category of streaming messages is between awareness messages and multimedia.…”

“…Streaming awareness messages have different QoS requirements than do transactions: in particular, they do not all have to arrive, but they do need low latency. This means that they are better sent using UDP -which is faster but non-guaranteed -than TCP [5].…”

“…One main concern is reliability -some transport protocols (e.g., UDP) that are commonly used to send groupware messages are not guaranteed to arrive. These protocols are essential because they provide a much better fit to the QoS requirement of streaming awareness messages than reliable protocols such as TCP [5]; therefore, the message compression technique must be able to deal with the loss of some parts of the overall data stream. As a result, the Ziv-Lempel techniques that refer to previous parts of the stream (e.g., LZ78 [27]) cannot be used for compressing the entire stream as if it were one file (these techniques can still be used to compress individual messages, however).…”

Using an experimental study to develop group awareness support for real-time distributed collaborative writing

“…In order to distinguish telepointers of different users, each telepointer is assigned a different colour or a different shape or even have the user's name and/or image attached to it [29,30,32,52,53]; Fig. 2.…”

Supporting High Coupling and User-Interface Flexibility

“…Second, the system should be allowed to choose a level of coupling that gives the desired quality of service. For example, NetMeeting and other commercial collaboration-aware applications do not support immediate or synchronous remote updates to a graphical object being dragged (Figure 1) probably because of jitter problems in a wide-area network, while some systems that address these problem do support incremental graphical updates (Dyck 2004).…”