一个较复杂的问题是如何从主机崩溃中进行恢复。尤其是当服务器崩溃并很快重新启动后，客户端希望能够继续进行崩溃前的操作。为了说明其困难程度，我们假设客户端主机正在使用一个简单的停-等协议向远端的文件服务器主机发送一个长文件。服务器端的传输层只是简单地将收到的TPDU依次传给用户。在传送到1/2时，服务器崩溃了。当它重新启动后，它所有的登记表均被初始化，因此它不能确定其发生崩溃前的情况。 　　为了能恢复崩溃前的状态，服务器可以以广播方式向所有其他的主机发送一个TPDU，说明自己刚才发生崩溃并要求其客户主机通知所有接通的连接所处的状态。每个客户主机可能处于两种状态之一：有一个未被确认的TPDU--S1状态，或没有未被确认的TPDU--S0状态。根据这种状态信息，客户主机必须决定是否要重发最近的TPDU。 　　乍一看似乎很明显：客户端在得知远端服务器崩溃而自己有一个未被确认的TPDU时（即处于状态S1）才应该重发。然而，再仔细考虑一下便会发现这种简单的方法存在的困难。例如，考虑下面这种情况，远端服务器的传输实体只发送一个确认，当确认发生后，又对应用进程执行-个写操作。向输出流写一个TPDU和发送一个确认是两个不同而又不可分的事件，二者不能同时进行。如果在确认发出后而在写操作执行前崩溃发生了，此时客户端将收到这个确认。当崩溃恢复声明到达时它处于状态S0。客户端将因此不再重发，因为它错以为那个TPDU已经到达服务器端。客户端的这种决定会导致丢失一个TPDU。 　　在这点上读者可能会认为：这个问题很容易解决。唯一需要做的是重新编写传输实体的（协议）程序，让其先进行写操作，然后再发送确认。再试试看，设想已经完成了写操作但在确认发出前系统发生了崩溃。此时客户端将处于状态S1并因此重传数据，从而会导致在服务器应用进程的输出流上出现-个未经检测的重复的TPDU。