关于检测由于通信子系统的问题造成的消息丢失，我又三个建议。第一个可能是它们中功能最强而且最轻易实现的，因为没有新的概念而又能重发知道丢失的消息。
第一个方案：
主机在发送一个消息后，保存一个消息的拷贝，直到：
*返回一个RFNM，这说明一些正常，然后处理下一个消息。
*返回一个INCOMPLETETRANSMISSION，这种情况下重发消息（这可能是一个循环，因此要设置一个重复发送一个消息的最大次数）。
*返回DESTINATIONDEAD，这说明目的主机关机，要求在进一步通信之前必须交换reset命令。
*其它返回表明在网络中或者本地接口报文处理器（IMP）发生错误，这时至少要记录错误，关闭对话。
按照以上步骤，可以防止消息的丢失。
第二个方案：
在主机发送消息时，消息号被包含消息中在主机对主机的头区域中，而且消息按顺序发送（这跟目前网络中的除了有优先级的消息除外的情况一样，因此这个建议要求主机发送任何东西时没有优先级区分），然后接收主机把接收到的消息号跟上次收到的消息号进行比较，这样可以发现消息的丢失。
当交换reset命令时，这对主机间的序号设为0。
每次发送一个消息时，把当前发送消息号添到消息头的指定区域，然后把当前发送消息号＋1（对N取模，假设N=256）。
每收到一个消息，就把这个消息号跟目前的接收消息号相比较：
假如接收的消息是希望接收的，那么该消息可以接受，然后目前的接收消息号＋1（对N取模）。
假如接收的消息不是希望接收的，那说明消息丢失。
当检测到消息丢失需要干什么并不明显，但是至少要记录下来，并且汇报给网络控制中心。消息的丢失对于交互会话可能不大重要，但是对于文件传输却是致命的。因此建议假如消息没有恢复就治理对话。
第三个方案：
可以要求主机与主机之间进行应答。这个应答方案可以用与接口报文处理器之间的应答相类似的方式实现。由于这要大幅修改目前的协议，要制定出一种合理的应答策略还需要进一步的研究，因此在这里我不对它进行具体说明。
上面三个建议中，第一个是最实用，也是最轻易实现的。这几个方案互相没有冲突，可以同时实现并使用。
