Summary

  • CU-SeeMe lowered the price and computer requirements at the edge, but its multiparty mode depended on a separate Unix reflector because the contemporary Macintosh TCP/IP software lacked multicast support.
  • The reflector made group calls usable by copying and selectively redistributing streams; it also concentrated bandwidth, configuration, participant limits, visibility and operator etiquette at a shared point.

The extra person changed the architecture

The first promise was modest and specific. Tim Dorcey’s March 1995 account described a desktop videoconferencing program for Macintosh and Windows. Receiving video required a network connection and a grayscale monitor; sending required a camera and digitizer. Dorcey said the combined camera/digitizer could be bought for a Macintosh for under US$100. That was a component price, not the cost of a complete working Internet setup, and the application’s low-resolution grayscale images were a deliberate accommodation to the computers of the time.

Two participants could connect directly. Larger conferences could not simply repeat that arrangement: Dorcey said each participant connected to a “reflector,” a Unix computer running CU-SeeMe software that replicated and redistributed packet streams. The reflector’s original purpose, he wrote, was the absence of multicast capabilities in the Macintosh. The endpoint could make a picture; the shared machine made a room.

That distinction matters because IP multicast was already specified. RFC 1112 had defined host support for sending and receiving group datagrams in 1989. The limitation was narrower: the Macintosh TCP/IP facilities CU-SeeMe targeted did not provide the multicast capability the project needed. The reflector was an application-level answer to a platform gap, not evidence that the Internet as a whole lacked multicast.

A shared point did more than forward packets

CU-SeeMe did not treat every participant as an identical fire hose. In Dorcey’s description, each client periodically sent an OpenContinue packet containing its interests in other participants’ video, audio or slides. The reflector examined those messages and built source-specific distribution lists. Its job was therefore both replication and coordination: it could avoid sending media a recipient did not want.

This was useful flexibility, but it placed live conference state at the reflector and required each participant to process changing information about every other participant. Dorcey judged that protocol unsuitable for large conferences, roughly beyond 30 people, while saying it worked robustly for smaller groups. That estimate describes the protocol’s scaling behavior in the 1995 paper; it is not the same as a fixed maximum imposed in every reflector configuration.

The reflector also became a place people could find one another. Cornell’s project page described it as necessary for multiparty use and warned that the software repeated conference streams to receivers. On an active reflector, anyone who connected could see who tuned in. A meeting point was also a visibility boundary, and the software’s forwarding behavior shaped who could observe whom.

Capacity became a matter of etiquette

The surviving operator instructions make the costs unusually plain. Cornell’s reflector etiquette page asked visitors to contact the operator, avoid staying for hours without an invitation, stop transmitting idle still images, keep the client cap under 100 kilobits per second, and check before using a connection shared with others. It warned that a still image could consume both network bandwidth and reflector capacity. These were not abstract protocol recommendations; they were requests made to users because someone else owned the shared resource.

An operator guide published with Internet TV with CU-SeeMe offered a planning example: about 80 kilobits per second for a reasonably satisfying connection, 640 kilobits per second for the reflector to receive eight participants, and 5.12 megabits per second to reflect the streams to the group. The guide’s figure is an illustrative estimate, not a measured benchmark. Its value is in showing the design’s multiplication: the reflector had to receive traffic and then send copies onward. The guide also described Unix hosts as attractive because of their network connectivity, processor capacity and ability to stay running, and exposed text-file controls for participant and sender limits.

Contemporary users were asked to set caps below 100 kilobits per second unless they knew where their traffic would go. A May 1993 README circulating from Cornell reported that one reflector had carried up to six participants. Neither figure establishes a universal ceiling. Together, they show a service whose usable scale depended on local equipment, network links, configuration and the judgment of the person keeping a reflector available.

Accessibility moved work instead of erasing it

The Cornell retrospective places the reflector’s creation after an NSF program officer asked in late 1992 whether CU-SeeMe could support multiparty use for schoolchildren. Richard Cogger proposed the concept; John Lynn developed the separate Unix program, with protocol critique from Scott Brim. A successful Global Schoolhouse conference connected students in several US states and London. That history helps explain why the reflector existed: a real educational use required more than a point-to-point demonstration.

Dorcey was careful about the trade. He said the team tried not to make users dependent on the reflector beyond replication and distribution, while also recognizing that it could tailor streams to recipients. The reflector was a practical bridge, not a claim that a server should govern every part of communication. Even so, a bridge requires a host, an operator, enough capacity, and rules for people who share it.

By 1995 the project had expanded its protocols and added features including audio, color images, text chat and bandwidth management. Those additions broadened the service, but they did not erase the central operating question. A low-cost camera could make an endpoint affordable; it could not supply the room’s upstream bandwidth, Unix host, maintenance or moderation. CU-SeeMe lowered one barrier and relocated another.

The record does not show that reflectors were prohibitively costly, that every operator enforced the published etiquette, or that all users had equal access. It does show the architecture’s bargain in unusually concrete terms: the client made participation cheap enough to try, while the reflector made the group possible by concentrating work at a shared, capacity-limited and socially visible point.

Sources