摘要

  • CU-SeeMe 降低了终端成本与设备要求,但多方会议依赖一台独立的 Unix 反射器,因为当时 Macintosh 的 TCP/IP 软件没有项目所需的组播能力。
  • 反射器通过复制、分发数据流让多人会谈成为可能,同时把带宽、配置、参与人数上限、可见范围和使用规矩集中到一个共享节点。

多一位参与者,网络结构就变了

最初的承诺很具体。Tim Dorcey 在 1995 年 3 月的文章中,把 CU-SeeMe 描述为适用于 Macintosh 和 Windows 的桌面视频会议软件。接收画面只需联网电脑与灰度显示器;发送画面还要摄像头和数字采集器。Dorcey 说,Macintosh 用的摄像头与采集器组合可以买到 100 美元以下。这个价格指的是设备组件,并不代表完整的互联网视频站点;低分辨率灰度画面则适应了当时的计算能力。

两个人可以直接相连。再加入更多人,就不能简单地增加相同的点对点连接:每个参与者都要连到一台运行 CU-SeeMe 软件的 Unix 电脑,即“反射器”,由它复制并重新分发数据包。Dorcey 写道,开发反射器的直接原因,是 Macintosh 的 TCP/IP 环境没有组播功能。个人电脑负责产生画面,共享机器则搭起多人会议室。

IP 组播规范当时已经存在。RFC 1112 于 1989 年规定主机如何发送和接收发往组地址的数据报。限制更具体:CU-SeeMe 面向的 Macintosh TCP/IP 实现没有项目所需的组播接收能力。反射器解决的是一类终端的平台缺口;这段历史并不表示整个互联网都不支持组播。

共享节点还要做会谈协调

CU-SeeMe 并非把每种媒体都无差别地发给所有人。按 Dorcey 的说明,各客户端会周期性发送 OpenContinue 数据包,列出想从其他参与者那里接收的视频、音频或幻灯片。反射器检查这些消息,形成以来源为单位的分发列表。它既复制数据包,也协调接收对象;没有人请求的媒体可以不发过去。

这种灵活性让实时会议状态落在反射器上,也要求每位参与者处理其他所有人的动态信息。Dorcey 在 1995 年认为,这套协议在大约 30 人以上扩展不佳,小型会议则能稳定运行。这个判断描述的是协议的扩展表现,并非每个反射器配置都强制采用的固定人数上限。

反射器也成了人们相约的地方。Cornell 项目网页称,多方会议必须经过反射器,并提醒用户软件会把会谈数据流重复发给接收端。连接到正在使用的反射器,就可能看见谁加入了会谈。这个会面地点也设定了一条可见性边界:转发方式决定了谁能观察谁。

容量问题写进了使用礼仪

留存下来的操作说明把共享成本写得很明白。Cornell 的反射器礼仪页面建议先联系运营者;没有邀请时不要连接数小时;停止长时间发送静止画面;把客户端速率上限设在每秒 100 千比特以下;使用共享线路前先了解影响。说明特别指出,静止图片也会占用网络带宽和反射器容量。这不是抽象的协议建议:共享资源由另一方提供。

随 Internet TV with CU-SeeMe 发布的运营指南给出一组规划示例:质量尚可的一路连接约需每秒 80 千比特;接收八位参与者的数据流需要每秒 640 千比特;再向会议成员反射流量,指南估算需要每秒 5.12 兆比特。最后这个数字是指南的示例估算,不是测量结果。它呈现了工作量的乘数效应:反射器先收流量,再把副本送出去。指南还解释了 Unix 主机为何适合此任务——网络连接、处理能力和持续运行时间——并提供文本配置项来限制参与者和发送者。

1993 年 5 月流传的一份 Cornell README 建议:除非清楚流量会经过哪里,否则速率上限不要超过每秒 100 千比特。同一时期的一份使用者说明称,一台反射器曾承载至多六名参与者。两个数字都不能代表普遍上限;它们共同显示,规模取决于本地设备、网络线路、配置和运营者的判断。

门槛降低了,运营工作转移了

Cornell 的机构史把反射器的出现放在 1992 年末的一次需求之后:一位 NSF 项目负责人询问 CU-SeeMe 能否支持面向小学生的多人会议。Richard Cogger 提出反射器概念,John Lynn 开发独立的 Unix 程序,Scott Brim 对协议设计提出意见。随后 Global Schoolhouse 项目的一次会议连接了美国多个州和伦敦的学生。这个来历说明了反射器的用途:真实的教育活动需要多人共同接入,而不只是两人演示。

Dorcey 谨慎描述了设计取舍。他说团队努力避免让用户在复制和分发之外依赖反射器,同时也逐渐认识到,反射器能按接收者调整数据流。它是实用的桥梁,设计目标没有把服务器塑造成通信的全权管理者。即便如此,桥梁仍需要主机、运营者、充足容量,以及共享它的人共同遵守的规则。

到 1995 年,项目扩展了协议,增加音频、彩色画面、文字聊天和带宽管理等功能。功能增多并没有消除运营问题。价格可承受的摄像头降低了用户终端的成本,却没有提供会议室的上行带宽、Unix 主机、维护或协调。CU-SeeMe 降低了一道门槛,也把另一道门槛移到了共享服务上。

现有资料不能证明反射器托管费用高到难以承受,也不能证明每个运营者都执行了公开规则或所有人都能平等接入。它们确实记录了这项架构交换:客户端让人们愿意尝试参与;反射器把多人会谈变成现实,却把工作集中在一个有容量边界、同时对参与者可见的共享节点。

资料来源