2. 若干设计问题
2A. 基本假设
Telnet 进程的功能是让位于用户站点的终端在网络另一端看来, 与一台"直接"连接到服务方站点的终端逻辑等价。这一基本功能有若干含义。
i) 用户应当能够产生服务方系统终端所能产生的全部代码。对于网络信息中心和其他一些站点而言, 合理的要求似乎是: 通过按键约定, 用户能够把全部 128 个 ASCII 字符代码作为输入送入网络。字符代码不同的其他站点, 可能需要 Telnet 进程把这些代码提供给网络。
ii) 用户应当能够转义 (escape) 回本地系统, 或者从服务方进程转义到服务方系统。
iii) 逐行 (line-at-a-time) 系统的 Telnet 应当能够与逐字符 (character-at-a-time) 系统和逐行系统协同工作, 逐字符系统的 Telnet 也应当能够与逐行系统和逐字符系统协同工作。
2B. 回显控制
我们使用回显控制 (echo control) 这一术语, 而不用半双工 (half duplex) 或全双工 (full duplex), 因为就网络传输而言, Telnet 连接实际上是全双工的。需要考虑三种终端情况。
- 情况 1 - 逐字符, 服务方站点回显
- 情况 2 - 逐字符, 用户方站点回显
- 情况 3 - 逐行, 用户方站点回显
一些服务方站点也许能够以全部三种情况运行, 因此需要某项约定来设定模式。严格来说, 敲击哪些键会回显哪些字符与服方站点无关, 尽管人们会希望尽量减少呈现在用户面前的打字稿差异。
2C. 格式控制字符
水平制表符 (HT)、垂直制表符 (VT)、换页符 (FF)、换行符 (LF) 和回车符 (CR) 这些格式控制字符, 在上文的情况 2 和情况 3 中需要以一致的方式处理。对于上文的情况 1, 情形则比较简单。
2D. 网络报文边界
NCP 到 NCP 协议在制定时的目标是: 让网络报文边界 (network message boundaries) 对用户进程不可见。如果这一目标能够保持, 那当然好, 但对某些逐行系统来说可能难以做到。
2E. 一项实现约定
如果我们做如下假设, 解决上述问题的约定将最容易建立: 服务方站点从 Telnet 进程接收到的字符流, 被送入服务方监视器中与"直接"连接的终端字符输入相同的入口点, 而服务方进程的输出被送入监视器中常规字符输出的入口点。服务方 NCP 在获得常规监视器字符输出的位置接收其输入。换言之, 服务方进程将从服务方监视器的字符缓冲区取得输入, 并把输出发送到这些缓冲区, 而不是直接从 NCP 缓冲区取得输入或向 NCP 缓冲区输出。
另一方面, Telnet 进程将直接与其本地 NCP 相互收发字符流。
还存在两端用户进程都直接与 NCP 通信的情形。因此, 我们建议: 在 NCP 与用户进程之间, 两种连接模式 (用户进程-监视器-NCP, 或用户进程-NCP) 都可供使用。这些模式将由用户进程在程序控制下设定。在登录过程期间直至服务方进程作出改变之前, 初始的网络约定是从监视器取得字符并把字符发送给监视器。服务方 NCP 同样与监视器通信。该方案如图 1 所示。
这种灵活性的动机, 从下文的讨论中可以看得更清楚。