停等协议c语言,停等协议ARQ

停等协议ARQ

(2011-04-07 21:15:40)

标签：

停等协议

arq

杂谈

为了深入理解数据链路层的协议，我们先从一种假想的、完全理想化的数据传输过程开始讨论。

如果链路是理想的传输信道，所传送的任何数据既不会出差错也不会丢失，那么数据链路层协议是根本不需要的。但是，这可能吗？不可能。所以我们需要数据链路层协议。

如果不管发送方以多快的速率发送数据，接收方总是来得及收下，并及时上交主机，那么数据链路层协议也是不需要的。但是，这可能吗？不可能。所以我们还是需要数据链路层协议。

这就是说，传输数据的信道是不可靠的(即不能保证所传的数据不产生差错)，并且还需要对数据的发送端进行流量控制。

看看最简单的停止等待协议。

收方在收到一个正确的数据帧后，向发方发送一个确认帧ACK(表示“我收到啦”)。当发方收到确认帧后才能发送一个新的数据帧。这样就实现了收方对发方的流量控制。假如数据帧在传输过程中出现了差错。由于通常都在数据帧中加上了循环冗余校验CRC，所以收方很容易校验出收到的数据帧是否有差错。当发现差错时，收方就向发方发送一个否认帧NAK(表示“嘿，哥们儿，你搞错了”)，以表示发方应当重发出错的那个数据帧。

有时，链路上的干扰很严重，或由于其他一些原因，收方收不到发方发来的数据帧。这种情况称为帧丢失。发生帧丢失时，收方当然不会向发方发送任何应答帧。如果发方要等收到收方的应答信息后再发送下一个数据帧，那么就将永远等下去。要解决这个问题，可在收方发送完一个数据帧时，就启动一个超时定时器。若到了超时定时器所设置的重发时间仍收不到收方的任何应答帧，则发方就重传前面所发送的这一数据帧。

然而现在问题并没有完全解决。当出现数据帧丢失时，超时重发的确是一个好办法。但是若丢失的是应答帧，则超时重发将使收方收到两个同样的数据帧。由于收方现在无法识别重复的数据帧，因而在收方收到的数据中出现了另一种差错，称为重复帧。要解决这个问题，必须使每一个数据帧带上不同的发送序号。若收方收到序号相同的数据帧，就表明出现了重复帧。这时应当丢弃这重复帧。但应注意，此时收方还必须向发方发送一个确认帧，因为收方已经知道发方还没有收到上一次发过去的确认帧。

我们知道，任何一个编号系统的序号所占用的比特数一定是有限的。因此，经过一段时间，发送序号就会重复。序号占用的比特数越少，数据传输的额外开销就越少。对于停等协议，由于每发送一个数据帧就停止等待，因此用一个比特来编号就够了。就是说序号轮流使用0和1。

由于发方对出错的数据帧进行重复是自动进行的，所以这种差错控制体制常简称为ARQ(Automatic Repeat

reQuest)，直译是自动重复请求，意思是自动请求重发。

停止等待协议ARQ比较简单，但信道利用率不高。为了克服这一缺点，就产生了另外两种协议，即连续ARQ和选择重传ARQ。

连续ARQ的要点就是在发送完一个数据帧后，不是停下来等待应答帧，而是可以连续再发送若干个数据帧。如果这时收到了收方发来的确认帧，那么还可以接着发送数据帧。由于减少了等待时间，整个通信的吞吐量就提高了。但是，收方只按序接收数据帧，如果收到有差错的某帧之后接着又收到了正确的几个数据帧，都必须将它们全部丢弃；而发方在重传时，又必须把原来已正确传送过的数据帧进行重传(仅因为这些数据帧之前有一个数据帧出了错)。这种做法又使传送效率降低。由此可见，若传输信道的传输质量很差因而误码率较大时，连续ARQ不一定优于停止等待协议。

为了进一步提高信道的利用率，可设法只重传出现差错的数据帧或者是定时器超时的数据帧。但这时必须加大收方的缓冲区，以便先收下发送序号不连续但仍处在缓冲区中的那些数据帧。等到所缺序号的数据帧收到后再一并送交主机。这就是选择重传ARQ协议。使用选择重传ARQ协议可以避免重复传送那些本来已经正确到达收方的数据帧。但我们付出的代价是在接收端要设置具有相当容量的缓冲空间，这在许多情况下是不够经济的。正因为如此，选择重传ARQ协议在目前就远没有连续ARQ协议使用得那么广泛。

分享：

喜欢

0

赠金笔

加载中，请稍候......

评论加载中，请稍候...

发评论

登录名： 密码： 找回密码 注册记住登录状态

昵   称：

评论并转载此博文

发评论

以上网友发言只代表其个人观点，不代表新浪网的观点或立场。