实验目的
熟悉各种不同 rdt 协议的运行环境，对照教材理解给出的 rdt 协议源码，理解并掌握不同链路特性对 rdt 协议性能的影响。比较不同 rdt 协议适应的运行环境。
准备阶段
进入Linux操作系统，将实验文件复制到Ubuntu内，观察到文件内包含Makefile文件，于是在命令行内将路径定位到当前文件夹内
打开其中某一个文件夹看到路径如图，使用cd指令切换路径
执行make指令，Makefile在操作系统实验中学到，其实是一个指令的集合，我们打开Makefile文件可以看到
其中包含了对所需的文件的编译过程，所以我们执行指令make，完成对文件的编译
由于之前执行过一次了所以中间过程看不到了，使用ls指令查看路径内的文件，发现文件已经被编译为.o文件
在readme文件中查看此次实验的执行方式和各个参数的意义，可以看到：
在执行中可以使用 ./sim 协议号 时间片 超时时间 丢包率 校验错误率 错误标记
文件夹中包含了几种协议，具体如下：
p2：设置有限的缓冲区buffer和有限的处理速度
p3：不可靠的信道上允许单向的数据流通
p4：双向滑窗协议
p5：go back n协议
p6：重传协议
查看exercise文件，此次实验的大概内容为：
实验过程
1
. 
测试有效负载的变化与校验错误率、丢包率、超时的关系，总结出结论
具体测试过程如下：
可以看到我们设置超时时间比较短，为10，这里发现对于发送方process 1，由于超时时间过短导致了大量的重传，对于接收方process 0，有效负载payloads accepted较少，导致最后的评价参数Payloads Accepted/data pkts sent值较小，后面修改第二个参数超时时间，观察不同的超时时间对Payloads Accepted的影响，整理出表格如下（以协议5 GBN为例）：
| Timeout |
Payloads Accepted |
Total data frames sent |
Efficiency |
| 10 |
7 |
630 |
1% |
| 20 |
137 |
275 |
54% |
| 30 |
194 |
202 |
96% |
| 40 |
189 |
190 |
99% |
| 50 |
188 |
189 |
99% |
| 60 |
199 |
200 |
99% |
| 70 |
196 |
196 |
99% |
可以观察到超时时间过短会导致大量的重传，有效负载减小，另外经过多次测试发现同一条语句每次执行结果会有些许差异，同时在网上看见其他人做的实验，有效负载随着超时时间增长呈单峰形状分布，我这里感觉不是特别明显，但是可以看到最初超时增长时会由于重传减少，有效负载增加。
测试有效负载与丢包率的关系
这里选择了上面测试中表现性能比较好的超时时间60，然后改变参数中的丢包率，观察现象
首先测试丢包率5%，发现Efficiency约为67%，相比于前面0%的丢包率性能确实是有明显的下降的，接下来分别测试丢包率为10%，20%，30%，40%，50%，60%，70%，80%总结出表格如下：
| Pct_Loss % |
Payloads Accepted |
Total data frames sent |
Efficiency |
| 5 |
113 |
163 |
67% |
| 10 |
79 |
168 |
50% |
| 20 |
69 |
151 |
41% |
| 30 |
30 |
141 |
24% |
| 40 |
18 |
130 |
13% |
| 50 |
19 |
138 |
11% |
| 60 |
11 |
130 |
7% |
| 70 |
7 |
126 |
6% |
| 80 |
3 |
122 |
2% |
从测试过程中可以看到， 随着丢包率的增加，有效负载数大体呈现减少的趋势，超时数随之增加，重传数也增加，由于超时的增加导致发送的总数据帧数也会减少，Efficiency总体来说是减少的
测试校验错误率与有效负载的关系
选择了超时时长60，丢包率0%，校验错误率分别为5%，10%，20%，30%，40%，50%，60%，70%进行测试并观察规律，总结出表格如下：
| Pck_cksum |
Payloads Accepted |
Total data frames sent |
Efficiency |
| 5 |
120 |
171 |
70% |
| 10 |
77 |
161 |
54% |
| 20 |
69 |
153 |
40% |
| 30 |
38 |
143 |
27% |
| 40 |
24 |
141 |
19% |
| 50 |
8 |
127 |
8% |
| 60 |
13 |
132 |
7% |
| 70 |
5 |
124 |
5% |
通过数据可以得出，随着校验错误率的增加，有效负载大体上减少，总数据帧数也随之减少，重传数增加，Efficiency减少
2.
比较协议5和协议6在几种参数下表现出的性能，比较两种协议哪种更好
采用相同的参数，这里使用 ./sim protocal 60 0 0 0 运行结果如图：
| Protocal 5 |
Protocal 6 |
|
| Payloads accpted |
188 |
167 |
| Total data frames sent |
189 |
167 |
| Retransmitted |
0 |
0 |
通过比较可以看出来，在重传数这个参数下，协议六明显优于协议五，在Efficiency这个参数下同样是协议六更好一点，但协议六发送的数据帧数量相比来说会少一点
协议5是GBN协议，协议6是选择重传，发生超时时，GBN协议会重传所有窗口范围内序号的数据，而选择重传只重传窗口范围内需要重传的内容，已经确认的内容不需要再次重传，在这里会优于GBN协议
3.
函数pick_event()具有事件的内置优先级。例如，对于协议5，帧到达先于超时。尝试更改这些优先级(通过重新排序pick_event()中的语句)。你能得出什么结论?
首先找到这个函数，位于文件夹内的worker.c中，具体内容如下：
这里以协议5为例，修改case5中语句顺序，完成协议5中事件处理的优先级修改，比如这里修改如下：
原：
修改：
可以看到经过这几种修改，仍然是原来的顺序实现的有效负载更高一点，优先级顺序即：
数据到达、校验和错误、超时，这样可以达到的有效负载最高
4.
研究作为各种参数超时间隔函数的重传帧数?你能确定最佳设置是什么吗?
根据前面所做的实验，可以总结出，当超时时间在50-60范围内，丢包率为0、校验和错误率为0时，重传帧数最少，有效负载可达到较高值，实现较好的设置
5.
目前，模拟器将时间一次推进一个刻度。如果两个进程在远程超时时都被阻塞，则此进程将缓慢进行。当两个进程在时钟上都被阻塞时，请更改模拟器以更快地提前时间。
在sim.c文件中发现，这里随机生成一个数和1做与运算，然后修改tick，也就是题目中说到的每次“advance one tick”，这里看到每次将tick更新为加delta，在common头文件中发现delta定义为10，所以手动将delta进行了几次修改，发现差别不大，在上下浮动的正常范围为内。
然后尝试在common头文件中加入声明一个标记死锁的变量
在sim.c中首先初始这个值为零，如果发生死锁，则修改这个值为1
在worker.c文件中，对于超时检测增加一个判断条件，如果死锁的标记被修改为1，这时说明发生死锁，等同于超时，重新发送消息，解除当前的死锁情况
6.
在目前的模拟器中，包传递本质上是即时的。更改它，以便交付时间随用户可设置的差异而变化。差异如何影响协议性能？
考虑到可以使得交付时间随用户设置而变化，增加一个输入变量，修改delta，就需要在common.h中将delta由原来的常量修改为变量，同时在sim.c中，将delta设为输入的最后一个变量。
经过测试发现并没有什么实质的改变，在正常的浮动范围内有些许变化，大多数情况下并不会随着delta的改变而对实验结果有什么影响，后来仔细思考了一下，delta类似于一个步长，修改步长只会使到达Deadblock的时间有上下很小的浮动，不会是一个真正影响性能的操作，要修改的话应该是修改Deadblock
于是查找到Deadblock的定义如下：
所以如果要修改的话，需要找到这个timeout_interval，通过搜索的方式找到这个值，发现：
是delta*超时时间，所以这个值与delta还是有关系的，可是我们修改了delta并没有发现，说明这里的想法还是出了点问题。
总结
这次实验是要验证rdt协议的一些性质和影响因素，由于这部分是期中考试前学的了，到现在有一点遗忘，所以花了一点时间重新看了一下几种协议，然后在虚拟机上操作其实还是比较麻烦的 ，刚开始的时候虚拟机不能上网，参照了网上的很多方法，才修改正确
过程中前面几题都比较简单，第三题需要修改优先级，刚开始对于几个if语句对应几个优先级判定也不是很清楚，后来才理解到哪条对哪条，三条语句一共六种排列方法，我中间的时候弄的比较乱，大概选择了几种排列然后比较了一下，五六题相对来说更难一点，要阅读源码还要修改源码，感觉自己这里做的比较差，实验做完也没好好地再检查一遍，希望后面可以准备得更充分一点。
