发布时间 : 星期日 文章计算机网络第四版习题答案(中文版)更新完毕开始阅读7df7400e6c85ec3a87c2c5cf
6-5 Why does the maximum packet lifetime, T, have to be large enough to ensure that not only the packet but also its acknowledgements have vanished? 答：首先看三次握手过程是如何解决延迟的重复到达的分组所引起的问题的。 正常情况下，当主机1 发出连接请求时，主机1 选择一个序号x，并向主机2 发送一个包含该序号的请求TPDU；接着，主机2 回应一个接受连接的TPDU，确认x，并声明自己所选用的初始序列号y；最后，主机1 在其发送的第一个数据TPDU 中确认主机2 所选择的初始序列号。
当出现延迟的重复的控制TPDU 时，一个TPDU 是来自于一个已经释放的连接的延迟重复的连接请求（ CONNECTION REQUEST），该TPDU 在主机1 毫不知情的情况下到达主机2。
主机2 通过向主机1 发送一个接受连接的TPDU（CONNECTION ACCEPTED）来响应该TPDU，而该接受连接的TPDU 的真正目的是证实主机1 确实试图建立一个新的连接。在这一点上，关键在于主机2 建议使用y 作为从主机2 到主机1 交通的初始序列号，从而说明已经不存在包含序列号为y 的TPDU，也不存在对y 的应答分组。当第二个延迟的TPDU 到达主机2 时，z 被确认而不是y 被确认的事实告诉主机2 这是一个旧的重复的TPDU，因此废止该连接过程。在这里。三次握手协议是成功的。
最坏的情况是延迟的“连接请求”和对“连接被接收”的确认应答都在网络上存活。可以设想，当第2 个重复分组到达时，如果在网上还存在一个老的对序列号为y 的分组的确认应答，显然会破坏三次握手协议的正常工作，故障性的产生一条没有人真正需要的连接，从而导致灾难性的后果。
6-6 Imagine that a two-way handshake rather than a three-way handshake were used to set up connections. In other words, the third message was not required. Are deadlocks now possible? Give an example or show that none exist. 答：我们知道，3 次握手完成两个重要功能，既要双方做好发送数据的准备工作（双方都知道彼此已准备好），也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送与确认。 现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子。考虑计算机A和B 之间的通信。假定B 给A 发送一个连接请求分组，A 收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A 认为连接已经成功的建立了，可以开始发送数据分组。
可是，B 在A 的应答分组在传输中被丢失的情况下，将不知道A 是否已经准备好，不知道A 建议什么样的序列号用于A 到B 的交通，也不知道A 是否同意A 所建议的用于B 到A交通的初始序列号，B 甚至怀疑A 是否收到自己的连接请求分组。在这种情况下，B 认为连接还未建立成功，将忽略A 发来的任何数据分组，只等待接收连接确认应答分组。而A在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
6-7 Imagine a generalized n-army problem, in which the agreement of any two of the blue armies is sufficient for victory. Does a protocol exist that allows blue to win? 答：（a）参见教材。
（b）不存在。对于多于两支部队的情况，问题在实质上是同样的。
第 29 页 共 40 页
6-8 Consider the problem of recovering from host crashes (i.e., Fig. 6-18). If the interval between writing and sending an acknowledgement, or vice versa, can be made relatively small, what are the two best sender-receiver strategies for minimizing the chance of a protocol failure?
答：在解答本题前，让我们先考察主机从崩溃恢复所带来的问题。我们总是希望，在服务器崩溃随后又很快重新引导的情况下，客户机能够继续工作。为了说明这一问题的难度，我们假定一个客户主机发送一个长文件给另一个服务器主机，并且使用简单的停-等协议。在服务器上的传输层只是简单的把接收到的TPDU 一个一个的递交给传输用户。假定在文件传输的过程中，服务器崩溃了。当服务器恢复的时候，它的表被重新初始化，因此再也不知道崩溃前文件传送到什么地方了。
在试图恢复先前状态的过程中，服务器可能发送一个广播到所有其他主机，宣布自己刚刚发生了一次崩溃，请求客户告知所有打开的连接的状态。此时。每个客户机都可能处于二中选一的状态：有一个悬而未决的TPDU 的S1 状态，或者没有未确认应到的TPDU 的S0 状态。
可以想到的一种解决方案是基于这一状态信息，客户机决定是否要重复发最近的一个TPDU。
乍看起来，这一解决方案似乎能解决问题，可是深入仔细的分析一下，困难仍然很大。作为示例，假定服务器的传输层实体先发送ACK，在ACK 被发出之后，再执行把收到的TPDU写到应用进程的操作。把TPDU 写到输出设备和发送ACK 是两个不同的事件，不能同时进行。如果服务器主机的崩溃刚好发生在应答被发送之后，并且是在写操作之前，那么客户机将接收到确认应答，当崩溃恢复到达时会处于状态S0。因此，客户机不会重传TPDU，错误的认为服务器成功的接收到并存放好了它最后一次发送的TPDU。实际的情况并非如此，从而结果是丢失了最后一个TPDU。
到此，你也许认为：“这个问题容易解决，只要你重新编写程序，让传输实体先执行写操作然后再发送ACK就可以了。”可是，写操作尽管成功了，但崩溃可能发生在发送出ACK之前。此时客户机将会处于状态S1，因而重新发送，导致对服务器的应用进程的输出中产生未检测到的重复TPDU。
如图6-18 所示，服务器可以选择两种方式中的一种：先确认应答，或者先执行写操作。客户机可以选择4 种方式中的一种：总是重传最后一个TPDU，永不重传最后一个TPDU，仅在S0 状态时重传，或者仅在S1 状态时重传。这样就存在8 种可能的组合，但可以看出，对于每一种组合，都有一些事件会使协议的运行失败。 在服务器方可能发生3 种事件：发送一个ACK（A），对输出进程的写操作（W）和系统崩溃（C）。3 种事件可能以6 种不同的次序发生：AC（W），AWC，C（AW），C（WA），WAC和WC（A），这里的圆括号表示，在系统崩溃C 后，A 和W 事件就不可能了。图6-18 示出了客户机和服务器的策略的所有8 种组合，以及对于每一种组合的有效事件序列。值得注意的是，对于每一种策略都存在某些事件会引起协议失败。例如，如果客户机选择总是重发送，AWC 事件将产生检测不出来的收到重复分组的错误。尽管对于C（AW）和C（WA）该协议都工作的很好。
本题的答案。如果AW 或WA 间隔时间很短，事件AC（W）和W（CA）就不太可能发生。此时最好发送方策略是，如果崩溃恢复时处于状态S1，应该重传最后一个TPDU，接收方采用顺序AW 或WA 则无关紧要。
第 30 页 共 40 页
6-9 Are deadlocks possible with the transport entity described in the text (Fig. 6-20)? Figure 6-20. An example transport entity.
第 31 页 共 40 页
第 32 页 共 40 页