1. 害处
引入标记是为了迁就发送主机, 因为它能让消息正文从字边界开始, 然而它并不适合字长不同的接收主机。此外, 它还给消息引入了无用的比特。让我们用我们的 Sigma 7 这台 32 位机器为例来说明这一点。
1.1 计算上的低效
假设我们从一台 18 位机器收到一条消息 (图 1.1), 它用 8 位 ASCII 字符编码, 而这些字符最终将成为网络上的标准。例如, 为了把这条消息转换成我们内部的 EBCDIC 代码,
0 17 0 31
-------------------------- ------------------------------
| leader | | leader |
-------------------------- ------------------------------
| | 0 0 0 1| | 0 0 0 1 | |
-------------------------- ----------- |
| | | |
| | | |
| | | |
| message | | message |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
图 1.1
我们首先必须把整条消息移位。我们必须检测前导之后第一个 1, 并据此判定必须把消息左移 4 位。每个双字大约需要 12 微秒, 对于一条完整的常规消息就是 1.5 毫秒。这并不算大, 但它仍然约等于把消息转换成内部代码所需时间的三分之一。
1.2 传输上的低效
更重要的是向消息添加不必要的比特所造成的低效, 尤其是当最终使用的是单字符消息时。图 1.2 给出了 Sigma 7 发送一个 1 字符正文的例子, 结果是为了承载 8 比特信息却传输了 112 比特, 从而得到 0.07 的效率因子。取消标记将
-----------------------------------
Sigma 7 | leader |
-----------------------------------
Message |00000000000000000000000000000001 |
-----------------------------------
| text | 000000000000000000000000 |
-----------------------------------
16 bits of padding | 1000000000000000 |
added by sending IMP --------------------
图 1.2
把这一效率提高到 0.10。对于 32 比特的正文 (某些控制命令的长度), 它会把效率从 0.28 提高到 0.4。对于单分组消息, 效率仍会提高 3%。