摘要

  • 1969 年 10 月 29 日，Charley Kline 在 UCLA 尝试登录 SRI 的主机；据 Leonard Kleinrock 后来的回忆，L 和 O 已送达，输入 G 后 SRI 主机崩溃。
  • Kleinrock 将故障归因于 SRI 主机内存溢出，并排除了 UCLA 主机、两台 IMP 和长途线路。软件稍作调整后，下一次登录成功。
  • UCLA 的手写日志只留下一句：“UCLA 与 SRI 主机通信。” 早在 4 月发布的 RFC 1 已把 IMP 网络软件与主机软件分开；这次测试让职责边界在一次真实操作中显形。

分析

电话线连着两端的人

这项测试的目标很具体：从 UCLA 登录到 SRI 的分时主机。Charley Kline 输入 L-O-G，远端系统应返回 I-N，在本地终端补完“LOGIN”。一个宏大的网络承诺，被压缩成几个字符和一项能否继续运行的任务。

Leonard Kleinrock 回忆，Kline 在 UCLA 3420 室，Bill Duvall 在 SRI。两组人保持电话通话，逐个确认字符有没有到达。电话不承载 ARPANET 数据；它让两边的人对照机器刚刚做过什么。早期网络的运行记录旁边，还有一句由另一端亲口给出的“收到”。

主机连接图只能表示线路和节点。它不能替远端操作系统接收一条命令、分配内存、维持会话，再把结果送回本地。登录测试碰到的正是这段图纸没有画出的工作：数据抵达之后，另一台机器能否把它变成一个正在运行的会话。

G 把故障位置指向 SRI

Kline 输入 L，Duvall 确认已收到；O 也一样。输入 G 后，SRI 主机崩溃。Kleinrock 在 2012 年的口述史访谈中，将原因归于 SRI 主机内存溢出，并明确排除 UCLA 主机、两台 Interface Message Processor 和长途线路。团队修改了一点软件，稍后再次尝试便成功。

故障归属会决定修复由谁负责。如果线路中断，网络承载方需要处理；这次回忆中的故障出现在远端主机处理命令之时。IMP 已经把输入送到足以触发 SRI 系统的程度；要继续会话，必须由 SRI 团队修复本机软件。

目前公开的证据由口述回忆和博物馆保存的日志组成。公开资料没有 SRI 崩溃转储或逐次尝试的分组记录；前者可以独立核实内存故障，后者可以把 22 时 30 分的日志时间对应到失败输入或成功重试。

六个词记录了成功，不是过程

计算机历史博物馆的 1960 年代互联网史将 UCLA 手写日志视作 10 月 29 日 UCLA 至 SRI 首次主机间连接的记录，并说明第一次登录使 SRI 主机崩溃、下一次成功。馆方展示了UCLA IMP 日志图像，博物馆的日志图注页面标出 22 时 30 分及两端名称。 该页面属于博物馆 11 月 21 日的历史条目；配图说明指向的是 10 月 29 日的值班日志。

Kleinrock 说，Kline 当时写下的那一行就是这件事留下的记录：“UCLA 与 SRI 主机通信。” 它记载两台主机建立了通信关系，却没有记下 G、内存溢出、软件修复或第二次尝试。这些细节来自后来访谈。把两种材料分开阅读，才能知道哪部分是值班日志，哪部分是当事人的回忆。

公共网络之外仍有主机软件

1969 年 4 月 7 日，Steve Crocker 发布RFC 1《Host Software》。它说明网络软件一部分运行在 IMP 上，另一部分属于各主机；BBN 负责规定 IMP 软件，各主机团队则需要就主机软件达成一致。这是同期的设计文件，不是 10 月事故的逐秒记录。

共同网络可以把消息送到主机。如何解释命令、维持进程、使用内存、返回结果，仍由主机端的软件承担。各部分有不同的任务，也有不同的维护者。G 让这条边界一眼可见：两个字符通过，第三个字符让远端主机停摆。

因此，传输成功不足以宣告登录完成。字符抵达是网络结果；会话建立还要求 SRI 主机继续运行，并返回预期的 IN。Kline 和 Duvall 能一起观察端到端结果；网络层的绿色指示灯替代不了应用程序的回应。

一次历史连接，留下了修复痕迹

10 月 29 日留下的不是一段无故障的起源故事，而是一次真实测试：远程主机在特定输入处崩溃，团队修正软件，重新尝试并成功。ARPANET 的早期成就包含了很普通的调试工作，也包含两端操作员对同一结果的核验。

共享接口解决了如何交换数据；每台主机还要把交换变成可用的功能。判断一次跨主机操作是否完成，取决于哪个端点还在运行、谁负责检查结果、谁把结果写入记录。那行六词日志保住了成功。Kleinrock 的叙述则补上了成功之前的故障。

来源