输出是1110111110011111010.
3-6 When bit stuffing is used, is it possible for the loss, insertion, or modification of a single bit to cause an error not detected by the checksum? If not, why not? If so, how? Does the checksum length play a role here?
假设使用了位填充成帧方法，请问，因为丢失一位，插入一位，或者篡改一位而引起的错误是否有可能通过校验和检测出来？如果不能的话，请问为什么？如果能的话，请问校验和长度在这里是如何起作用的？
答：可能。假定原来的正文包含位序列01111110 作为数据。位填充之后，这个序列将变成01111010。如果由于传输错误第二个0 丢失了，收到的位串又变成01111110，被接收方看成是帧尾。然后接收方在该串的前面寻找检验和，并对它进行验证。如果检验和是16 位，那么被错误的看成是检验和的16 位的内容碰巧经验证后仍然正确的概率是1/216。如果这种概率的条件成立了，就会导致不正确的帧被接收。显然，检验和段越长，传输错误不被发现的概率会越低，但该概率永远不等于零。
3-16 Data link protocols almost always put the CRC in a trailer rather than in a header. Why? 数据链路协议几乎总是将CRC放在尾部，而不是头部，为什么？
答：CRC 是在发送期间进行计算的。一旦把最后一位数据送上外出线路，就立即把CRC编码附加在输出流的后面发出。如果把CRC 放在帧的头部，那么就要在发送之前把整个帧先检查一遍来计算CRC。这样每个字节都要处理两遍，第一遍是为了计算检验码，第二遍是为了发送。把CRC 放在尾部就可以把处理时间减半。
3-17 A channel has a bit rate of 4 kbps and a propagation delay of 20 msec. For what range of frame
第 16 页 共 59 页
sizes does stop-and-wait give an efficiency of at least 50 percent?
一个信道的位速率为4kbps，传输延迟为20ms。请问帧的大小在什么范围内，停-等协议才可以获得至少50％的效率？
答：当发送一帧的时间等于信道的传播延迟的2 倍时，信道的利用率为50%。或者说，当发送一帧的时间等于来回路程的传播延迟时，效率将是50%。而在帧长满足发送时间大于延迟的两倍时，效率将会高于50%。
现在发送速率为4Mb/s，发送一位需要0.25。
只有在帧长不小于160kb 时，停等协议的效率才会至少达到50%。
3-18 A 3000-km-long T1 trunk is used to transmit 64-byte frames using protocol 5. If the propagation speed is 6 祍ec/km, how many bits should the sequence numbers be?
一条3000公里长的T1骨干线路被用来传输64字节的帧，两端使用了协议5.如果传输速度为6μs/公里，则序列号应该有多少位？
答；为了有效运行，序列空间（实际上就是发送窗口大小）必须足够的大，以允许发送方在收到第一个确认应答之前可以不断发送。信号在线路上的传播时间为 6×3000=?18000?，即18ms。
在T1 速率，发送64 字节的数据帧需花的时间：64×8÷(1.536×106)?= 0.33。
所以，发送的第一帧从开始发送起，18.33ms 后完全到达接收方。确认应答又花了很少的发送时间（忽略不计）和回程的18ms。这样，加在一起的时间是36.33ms。发送方应该 有足够大的窗口，从而能够连续发送36.33ms。 36. 33/0.33=110
也就是说，为充满线路管道，需要至少110 帧，因此序列号为7 位。
第 17 页 共 59 页
3-19In protocol 3, is it possible that the sender starts the timer when it is already running? If so, how might this occur? If not, why is it impossible?
有可能发生。假设发送方传输率一个帧、很快返回了一个引起误解的确认。主循环将再次被执行，一个帧将在定时器仍在运行的情况下被发送。
3-20 Imagine a sliding window protocol using so many bits for sequence numbers that wraparound never occurs. What relations must hold among the four window edges and the window size, which is constant and the same for both the sender and the receiver.
想象这样一个滑动窗口协议，它的序列号有非常多的位，所以序列号几乎永远不会回转。请问4个窗口边界和窗口大小之间必须满足什么样的关系？这里的窗口大小是固定不变的，并且发送方和接收方的窗口大小相同。
令发送方窗口为(Sl , Su)接收方窗口为(Rl , Ru)，令窗口大小为W。二者必须保持的关系是： 0 ≤ Su ? Sl + 1 ≤ W1 Ru ? Rl + 1 = W Sl ≤ Rl ≤ Su + 1
3-21 If the procedure between in protocol 5 checked for the condition a b c instead of the condition a b < c, would that have any effect on the protocol's correctness or efficiency? Explain your answer. 如果协议5中的between过程检查的条件是a<=b<=c，而不是a<=b 答：改变检查条件后，协议将变得不正确。假定使用3 位序列号，考虑下列协议运行过程： A 站刚发出7 号帧；B 站接收到这个帧，并发出捎带应答ack。A 站收到ack，并发送0~6 号帧。假定所有这些帧都在传输过程中丢失了。B 站超时，重发它的当前帧，此时捎带的确认号是7。考察A 站在r.rack=7 到达时的情况，关键变量是ack_expected=0，r.rack=7， next_frame_to_send_=7。修改后的检查条件将被置成“真”，不会报告已发现的丢失帧错误，而误认为丢失了的帧已被确认。另一方面，如果采用原先的检查条件，就能够报告丢失帧的错误。 第 18 页 共 59 页 所以结论是：为保证协议的正确性，已接收的确认应答号应该小于下一个要发送的序列号。 3-22 In protocol 6, when a data frame arrives, a check is made to see if the sequence number differs from the one expected and no_nak is true. If both conditions hold, a NAK is sent. Otherwise, the auxiliary timer is started. Suppose that the else clause were omitted. Would this change affect the protocol's correctness? 在协议6中，当一个数据帧到达的时候，需要执行一个检查，看它的序列号是否与期望的序列号不同，而且no_nak为真。如果这两个条件都成立，则发送一个NAK，否则的话，启动辅助定时器。假定else字句被省略掉，这种改变会影响协议的正确性吗？ 答：可能导致死锁。假定有一组帧正确到达，并被接收。然后，接收方会向前移动窗口。 现在假定所有的确认帧都丢失了，发送方最终会产生超时事件，并且再次发送第一帧，接收方将发送一个NAK。然后NONAK 被置成伪。假定NAK 也丢失了。那么从这个时候开始，发送方会不断发送已经被接收方接受了的帧。接收方只是忽略这些帧，但由于NONAK 为伪，所以不会再发送NAK，从而产生死锁。如果设置辅助计数器（实现“else”子句），超时后重发NAK，终究会使双方重新获得同步。 3-23 Suppose that the three-statement while loop near the end of protocol 6 were removed from the code. Would this affect the correctness of the protocol or just the performance? Explain your answer. 假设在协议6中接近尾部的内含三条语句的while循环被去掉的话，这样会影响协议的正确性吗？还是仅仅影响协议的性能？请解释答案。 答：删除这一段程序会影响协议的正确性，导致死锁。因为这一段程序负责处理接收到的确认帧，没有这一段程序，发送方会一直保持超时条件，从而使得协议的运行不能向前进展。 3-24 Suppose that the case for checksum errors were removed from the switch statement of protocol 6. How would this change affect the operation of the protocol? 这样将使得NAK的作用失效，于是我们将退回到超时。尽管效率会降低，正确性却不会受到影响。NAK不是必不可少的。 3-25 In protocol 6 the code for frame_arrival has a section used for NAKs. This section is invoked if the 第 19 页 共 59 页 incoming frame is a NAK and another condition is met. Give a scenario where the presence of this other condition is essential. 在协议6中，针对frame_arrival的代码中有一部分被用于NAK。如果收到的帧是一个NAK，并且另一个条件也满足的话，则这部分代码会被调用到。请给出一个场景，在此场景下这另一个条件是非常关键的。 答：这里要求r.rack+1 A 站发送0 号帧给B 站。B 站收到此帧，并发送ACK帧，但ACK丢失了。A 站发生超时，重发0 号帧。但B 站现在期待接收1 号帧，应此发送NAK，否定收到的0 号帧。显然，现在A 站最好不重发0 号帧。由于条件r.rack+1 3-26 Imagine that you are writing the data link layer software for a line used to send data to you, but not from you. The other end uses HDLC, with a 3-bit sequence number and a window size of seven frames. You would like to buffer as many out-of-sequence frames as possible to enhance efficiency, but you are not allowed to modify the software on the sending side. Is it possible to have a receiver window greater than 1, and still guarantee that the protocol will never fail? If so, what is the largest window that can be safely used? 想象你正在编写一个数据链路层软件，它被用在一条专门给你发送数据的线路上，而不是让你往外发送数据。另一端使用了HDLC，3位序列号和一个可容纳7帧的窗口。你希望将乱序的帧尽可能多地缓存起来，以提高效率，但是你又不允许修改发送方的软件。是否有可能让接收方的窗口大于1，并且仍然保证该协议不会失败呢？如果可能的话，能够安全使用的最大窗口是多少？ 答：不可以。最大接收窗口的大小就是1。现在假定该接收窗口值变为2。开始时发送方发送0 至6 号帧，所有7 个帧都被收到，并作了确认，但确认被丢失。现在接收方准备接收7 号和0 号帧，当重发的0 号帧到达接收方时，它将会被缓存保留，接收方确认6 号帧。当7 号帧到来的时候，接收方将把7 号帧和缓存的0 号帧传递给主机，导致协议错误。因此，能够安全使用的最大窗口值为1。 3-28 In protocol 6, MAX_SEQ = 2n - 1. While this condition is obviously desirable to make efficient 第 20 页 共 59 页