3-5 6个模拟的DLL协议之1-3在线视频

各位好

让我们一起来

由浅入深地学习六个协议吧

从而了解数据链路层的主要的工作

它的有些工作原理和概念

是网络通信的基础

其运行机理在网络层和传输层

也会用到

首先

一起来看一下最简单的三个协议

协议1

无限制的单工协议

协议2

单工停-等协议

协议3

有噪声信道的单工协议

这三个协议的共同点是

数据的传输

在某个时刻是单向的

即单工

在正式的学习协议工作之前

我们先来看几个假设

第一

物理层 数据链路层和网络层

在工程中它可能有不同的存在形式

但是我们在这个协议里面

我们把这三层

作为独立的处理进程

二 机器A希望向B发送的

是一个可靠的

面向连接的长数据流

第三

我们假设机器不会崩溃

即使崩溃我们不会处理

因崩溃而产生的错误

四 从网络层拿到的数据

是纯的数据

也就是说这个数据

是作为纯数据装载到

帧的载荷里面的

三个协议包括后面的三个协议

共同使用的数据类型

调用的函数

都定义在图3-9的protocol.h的

这个头文件里面了

数据链路层与网络层 物理层

之间的数据传送接口

专门定义了四个

第一个是from_network_layer

第二个是to_physical_layer

从这个名称你就可以看到

它分别代表了是从网络层去取数据

和处理好数据之后

向物理层去发数据

还有两个接口是from_physical_layer

这个是从物理层去拿数据

to_network_layer

这个是拿到了数据之后呢

处理完了

向它的上层网络层去提交这个数据

还有一个函数呢叫做wait_for_event

这个函数是在等待某个事件的发生

这些事件呢有可能是帧到达的事件

校验和没有通过发错的事件

还有就是定时器超时的事件

都会让wait_for_event

产生一个结果输出

在这个协议的程序里边呢

还用到了对定时器的这个管理

主要是定时器的起和停

也就是说

start和stop

那么这个定时器呢

我们主要会用到两个定时器

一个呢是重传定时器

一个是捎带确认定时器

数据链路层处理的基本协议单元

是帧

在程序里边

还定义了帧的结构

专门用来存放帧的信息

比如说包括帧的类型

帧的序列号

帧的确认号

在这个结构里面

我们看到一个非常重要的信息

是packet info

那这个呢

实际上是直接从网络层拿到的

分组或者包

它直接作为帧的载荷

定义在帧的结构里面

我们先来看协议1的工作情况

协议1呢

它做了这样的假设

数据是单向传送的

从发方到收方

第二收发双方的网络层

都处于就绪的状态

也就是说随时待命

随时可以有数据拿出来

或者说随时可以去接收数据

第三

处理的时间呢

可以忽略不计

也就是说所有对帧的处理呢

我们可以认为它是瞬间完成的

不考虑它的时间

第四

可用的缓存空间

非常的大

也就是说假设接收方

它具有的空间是无穷大的

任何时候

它都可以接收任何数量的数据

假设接收方的空间是无限的

第五个假设是

数据链路层之间的信道

永远都不会损坏或者丢失帧

也就是说假设这个通道是完美通道

不会有任何的错误

那么从刚才的这五点假设

我们已经看到了

协议1它面对的这个通信环境

实际上是一个乌托邦的环境

是不太可能存在的

所以协议1呢

我们也把它叫做乌托邦的协议

让我们来看一下

程序是怎么来实现的协议1吧

协议1呢它是分了发方和收方

也就是说

用了两个函数

一个sender

一个receiver

分别描述了发方和收方

它完成的动作

我们先来看sender

在sender里面首先定义了

一个帧变量S

接着定义了packet的变量

buffer

接着下来呢

就是一个无限的循环

while(true)的一个无限循环

无限循环的第一句话是

from_network_layer

这个函数实际上是从网络层去拿

packet或者包

拿到了包直接放到帧的载荷里面

所以

紧跟着就调用了第二句

s.info=buffer这个语句

这个语句完了之后呢

我们把帧组好了

组好了之后呢

就要把这个帧传给它的下一层

物理层

所以跟着第三句调用了

to_physical_layer

所以我们看到在整个循环里面

实际上它就是不断地从

上层网络层去拿数据

组帧

然后送给它的下一层物理层

无限循环不断地做这个事情

这个事情我们已经知道了

它就是封装的一个环节

那么发送方一直不断地封装发走

封装发走

不断地做这个事情

接下来我们来看一下接收方呢

接收方也用了一个无限循环

只要帧到达

就开始收帧

我们看一下无限循环里面

它调用的第一个函数是wait_for_event

wait_for_event 这个函数

就是来等待一个事件的到来

一个事件的到来

就会触发它去输出

那么这个时候呢

在协议1里边

我们的事件只有帧到达的这个事件

所以一旦帧到达

我们做什么呢

我们紧跟着就调用from_physical_layer

那么这个函数呢

就是要从物理层去拿比特流

拿回来之后呢

我们要把它分割成帧

然后再根据帧头帧尾的信息

对它进行处理

最重要的是要提取出帧里边的信息

载荷里边的最重要的信息

就是packet

就是包分组

提取出这个分组之后

我们要把它送给上一层

所以紧跟着就调用to_network_layer

这个函数

把它送给上一层

那么这个循环

做的主要动作

实际上是解封装的一个环节

不断地从物理层收帧

收完了之后处理

处理完了之后呢提取出载荷

packet

把它送给上一层

事实上协议1的假设条件太完美了

它是不现实的

现实的通信工程里头

不会有这么完美的这个环境的

所以呢

我们在以后的协议里边

要逐步地取消这些假设

取消这些限制

协议2首先就取消了接收方

允许无限量的接收的这个假设

取消了这个假设之后呢

它就面临着一个问题

就是接收方

有可能被大量拥入的数据所淹没

那么我们的协议2

必须要解决这个问题

解决的办法也很简单

就是接收方

它收到一个数据

如果它有处理能力的话

它会回发一个哑帧给发方

只要发送方收到了哑帧

它就知道接收方已经做好了

这个接收数据的准备

所以它可以再次的发下一帧的数据

实际上这个时候我们看到

数据的流向已经是双向的了

除了从发方向接收方流数据之外

接收方向发送方也发了一个

非常短的哑帧

所以这一个协议

严格地讲应该叫半双工的协议

我们来看一下

协议2的程序

在协议1的程序里边

增加了刚才讲到的反馈机制

在发送方的那个循环里面

加上了一个函数

这个函数叫wait_for_event

这个时候的wait_for_event

它是想等一个事件

等什么事件呢

就是等哑帧的到来

它每一次组好帧

发给物理层之后

它都要等到哑帧到来之后

它再进入下一次的循环

也就是去发送下一个帧

而接收方呢

也加上了一个语句

就是to_physical_layer

就是当它从物理层收帧

处理完了之后

发给网络层

然后呢它不着急进入下一个循环

而是向对方发送一个哑帧

就是调用to_physical_layer去发送

协议3继续取消了完美信道的

这个假设

也就是说

信道不再是不发生错误

而是有错误

有错误就是有噪声

那么有错误可能就会引起

以下这些问题

比如说接收方它可能会

收到这个帧

但是发现这个帧通不过校验

发生了错误

那么它怎么来通知发送方呢

又怎么来恢复这个正确的帧呢

那么在协议3里面

采用了一个机制

就是对正确帧的确认

任何时候

只要它收到的这个帧通过了校验

是正确的

它才向发方去做一个确认

那么只有发送方收到了确认之后

它才会去发下一帧

这个时候有可能发生

一些异常的情况

比如说

发送方发出去的数据帧在路上丢了

或者是说接收方

发出去的确认帧在路上丢了

这个都可能导致发送方

它不知道不了解这个情况

它会一直在这儿等

一直在这儿等确认帧的到达

如果没有到达

它的这个循环就无法进入下一次

那么为了解决这个问题

我们的发送方

在发送帧的同时

启动一个定时器

它希望在定时器超期之前

能够收到对方的确认

如果说超期了

还没有收到对方的确认

那它有可能就是说数据帧丢了

或者确认帧丢了

这个时候它怎么办呢

发送方就做了一个动作

重传

重新来发送之前发过的那个数据帧

以恢复出让接收方

恢复出那个正确的帧来

但是

又带来了新的问题

就是当我们的定时器

设置的不恰当的时候

比如说

设置的过短

设置的过短就可能导致

确认帧还在路上

定时器就超期了

超期了之后就会引发

发送方的重传

这个时候接收方就会收到两个

重复帧

为了避免把重传的帧当做新帧对待

我们怎么办呢

这个时候呢

我们就给每一个帧

一个独一无二的序号

那么这个序号呢

就可以让我们的接收方来区别

它是一个新帧

还是以前的一个重复帧

同时呢这个序号

还起到了一个作用

就是可以用来重排 重组

刚才讲到的解决错误信道的机制

叫做肯定确认重传

这个技术简称PAR

有的时候也叫做自动重传请求

叫做ARQ

肯定确认重传它的工作机制

主要是这样的

就是发送方每发出一个帧

它都启动一个重传定时器

超期之前

它希望能收到对方的确认

如果能的话

就拆除定时器

表明一切都正常

如果超期了还没有收到对方的确认

这个时候发方重传

重新来设置一个定时器

所以在协议3的程序里边

也做了一些改变

首先在发送方

它做的改变就是启动定时器

什么时候启动呢

就是发出去一帧

任何时候它发出去一帧

它都启动一个定时器

调用start_timer这个函数

同时呢在它收到对方的确认的时候

它会把这个定时器呢拆除

也就是说去调用stop_timer

这个函数来进行拆除

收方它也做了一些改变

在协议2的基础上

增加了两个语句

一个是s.ack

等于1减frame_expected

这个实际上是做一个确认

它对收到的这个帧

做一个确认

那么这个确认帧

再调用to_physical_layer

把它发给对方

那么在这个整个协议3的

收方的程序中

增加了这两个非常重要的语句

刚才讲到的三个协议

都是单工的协议

数据是单向流动的

工作效率是比较低的

我们可以采用一些方法

来提高传输的效率

第一个可以采用的方法

就是全双工

所谓的全双工就是

数据在某一个时刻

不再是从发方流向接收方

而是发方和收方

都没有明确的界限

就是它既是发方又是收方

它们两方可以互相来发数据

第二个手段呢

就是捎带确认

我们的接收方在任何时候

它要对收到的正确帧

进行一个确认的时候

它不必单独组装一个确认帧发过去

而是可以捎带到

自己发给对方的数据里边

相当于搭一个便车

搭一个便车呢

就可以减少信道的利用

提高信道的利用率

那么捎带确认的关键

就是要让我们的确认信息

勾到一个可以搭到的便车

也就是说勾到一个外发的数据帧

如果说是没有办法

等到这个数据

传给对方的数据的话

也就是说没有办法搭到便车的话

你也不能在这儿死等

如果你死等的话

在很多情况下

我们的数据传输

实际上是不对等的

很多情况下就像你自己一样

你上网

你主要的目的是去下载数据

很少想到去上传什么东西

那这个时候

有可能你就等不到便车来搭

如果你在这儿死等

对方就可能会重传数据过来

造成信道的进一步的浪费

怎么办呢

我们

当我们要准备启动一个

捎带确认的时候

我们一定要启动一个

捎带确认的定时器

如果超期了还没有搭到便车

我们就必须要单独发确认帧了

另外呢我们还有一个手段

来提高信道的利用率

就是批量发数据

我们看到刚才协议在工作的时候

是发一个帧

等对方的确认

然后再发下一个帧

那么它是非常严格的停-等协议

那么在停-等的这个过程里面

实际上信道是空闲的

怎么办呢

我们可以让这个空闲的时间

我们不要等

继续发数据

我们在等第一个确认的时候

继续发后续的帧

那么当我们发一批量的数据之后

刚刚好第一帧来了

我们又可以接着往下发

这就是批量数据

也叫管道化的技术

可以改善信道的利用率

我们把今天的内容小结一下

协议1呢处理的是完美的传输环境

所以叫“乌托邦”的协议

协议2做了简单的流控

防止接收方被数据所淹没

协议3呢解决了有噪声

信道带来的错误

引出了肯定确认

这个非常重要的技术

这三个协议呢

都是模拟协议

请大家在学习的时候

关注它里面的技术