摘要

  • Andrew G. Malis 在 1983 年 4 月的 RFC 852 中，为接在 C/30 IMP 上的 ARPANET 主机规定了可选择的“短阻塞”方式。旧方式可能因一条消息把主机后续输入挡住最长 15 秒；新方式在最多两秒后拒绝仍无法处理的消息，并发回带原因的 Type 9“不完整传输”应答。
  • 早点放开入口也会改动排队结果：后发消息可能先被 IMP 接纳，早发消息的拒绝回音却还在路上。对相同优先级、来源和目的地，网络保证的是按接纳顺序递送；需要原始提交顺序的软件必须自己安排，或不使用短阻塞。

柜台里有位办事员，收到一张麻烦表格，得先等隔壁办公室腾出材料。他索性关了整个窗口。下一位只想办一件几秒钟的小事，也被拦在外面。RFC 852 描述的主机与接口消息处理机（IMP）之间，曾有这种不分青红皂白的排队方式。IMP 收到一条消息后，需要依消息类型、长度和目的地调配资源。若资源暂时不齐，它就停止接收该主机的下一条消息。一个难办的目的地，连累其他本可立即处理的目的地。

原有阻塞可达 15 秒。Malis 的办法是在主机提交消息时给它一个选择：要求“短阻塞”，IMP 最多等两秒。两秒仍不够，IMP 拒绝这条消息，返回 Type 9 应答并说明缘由，同时继续筹措所需资源。主机可以先送别的消息，过一会儿再试刚才那条。窗口重开，并不等于那张表格办成；被拒的任务回到了递交者手里。这项差别决定了主机软件能否正确处理后续工作。

选择写在消息子类型里。普通 Type 0 消息的子类型 0 保留原有消息与错误控制，允许最长 15 秒阻塞；子类型 1 保留同类控制，却把上限缩为两秒。“不受控”分组另有一对：子类型 3 沿用较长上限，子类型 4 采用短上限。这类分组本来就没有递送保证。使用短阻塞的主机要认得 Type 9 拒绝应答，不能把“已提交”记作“IMP 已接纳”。RFC 852 将功能范围放在 C/30 IMP，主机使用 1822 或 1822L 接口均可。此前 1822 报告里有过一种非阻塞接口设想，但从未实现；这份 RFC 为新设计征求实现者意见。

Type 9 的原因码相当于一张窗口故障地图。新码分别指出连接建立延迟、端到端流量控制、目的地 IMP 缓冲区不足、路径拥塞和本地 IMP 资源不足。前四类可以只影响某一连接或目的地，让别处的消息继续走；本地 IMP 缺缓冲区或表项，影响面就广得多，除了不受控分组几乎都可能受牵连。“网络很忙”四个字太粗，无法告诉主机该先试哪条消息。

其中一项限制有清楚的数字：同一连接最多有八条“尚未得到处理结果回信”的消息。第九条再递上来，流控就可能拒收。另一项看长度：超过 1,008 比特的消息（另有 96 比特引导头不计在内）需要预留目的地 IMP 缓冲区。预留不到，这条长消息要等；短消息或别的连接却可能照常进入。短阻塞让主机不必为了第九张表格，把所有柜台顾客都留下陪等。

省下等待，顺序就变贵了。ARPANET 对同优先级、同源、同目的地消息提供的顺序保证，是按 IMP 接纳它们的次序递送。主机发消息与收 IMP 应答不是同一节拍。第一条被拒的回音尚未到达时，主机可能已经交出第二条，而第二条被接纳。随后再试第一条，它在 IMP 队列中的位置反而落后。Malis 明确写道：若应用严格依赖子网的顺序递送，就不该选短阻塞。

RFC 852 改掉的是柜台的脾气，随后重新分配了记账工作。IMP 不必为了一个缺资源的消息扣住整个主机，却必须尽快给出具体拒绝理由。主机换来了递交其他消息的机会，也接手了重试时间和顺序安排。两秒钟能把窗帘拉开；排队号码还得有人管。