通信协议原理实验

Github代码地址:https://github.com/laningya/UESTC-WORK/tree/master/Computer_Network/Experiment_1

一、实验室名称:

骨干传输系统实验室

二、实验项目名称:

通信协议原理实验

三、实验原理:

。利用实验所提供的通信软件,在局域网下建立全双工的通信信道用来传输比特流,通信双方可以将要传信息编码成比特流,通过软件传输,在对端进行解码。

四、 实验目的:

1、设计将汉字、英文字符等编/解码方法,并实验
2、设计在bit流基础上成帧的方法,并实验
3、 设计帧校验方法,并在有能力的情况下实现数据校验的算法
4、掌握和设计差错控制协议,在通信双方实现无差错传输
5、掌握和设计流量控制协议,避免浪费和尽量提高效率

五、实验内容:

在误码率为0时,进行信息传输,主要考验帧的定界、信息编码问题、ARQ问题
在误码率为千分之20时,进行信息传输,在上一次基础上要考虑差错控制问题

六、实验器材(设备、元器件):

1、分组实验,每组4~6人。

2、设备:计算机2台。
3、软件:通信模拟实验软件(comexpm.exe)

七、实验步骤:

1、组织实验小组成员进行实验分工。将小组成员及其分工记录在“实验报告”中。
2、根据通信模拟软件提供的传输服务,设计一个带差错控制功能的通信协议,并在“实验报告”中简要描述该协议内容,包括数据的表示方法、传送格式和通信的时序交互图。
3、使用通信模拟软件,设置误码率在0‰和20‰,实现通信过程:采用所设计的通信协议,发送方将一段文字发送给接收方,并解决这个过程中出现差错,尝试利用停等协议提高效率。在“实验记录”中记录本次通信过程:
 发送方:将实验文字表示成在发送窗口要发送的文字内容;点击“发送数据”的次数;点击发送前软件发送窗口中的二进制比特数据;
 接收方:点击“接收数据”的次数;每次点击接收时接收窗口中的二进制比特数据;根据接收内容还原后的文字内容。
4、根据“实验记录”中的记录信息分析所设计的通信协议的正确性、不足及其改进方法或建议,并在“实验报告”中阐述分析的结果以及自己对计算机通信设计问题和设计方法的体会。

1. 实验小组
小组名称 Spender

2. 通信协议的设计内容:
 通信信息的表示方法;
要传送的信息分为两类,一类为字符,另外一类为汉字。字符由ASCII编码,故可用8Bit来进行编码;汉字使用GBK编码,GBK码用两个字节来表示一个汉字;GBK码对汉字进行了分区,用高字节(首字节)代表区号,用低字节代表该汉字在本区内的位置,例如【啊】这个汉字,它的GBK码是0XB0A1,高字节是0XB0表示它的区号,低字节0XA1表示他在0XB0区内的第0XA1个
 通信信息的传送格式;
帧头:10001
标志位:0 或者 1 主要指示这是字符帧还是汉字帧
信息位:编码软件对要传输信息进行编码,并将其中出现的1000自动变换为10000,0111自动变化为01111
校验位:CRC-8循环冗余码
尾部:01110
 通信双方的时序交互图。
停-等协议时序交互


3. 通信过程记录
(1)信道无差错误码时,发送的文字内容:
发送:Home agent 管理在外地的本地用户
点击“发送数据”的次数 2 。
第1次点击时发送窗口中的二进制比特数据:
10001001001000001101111101101101011001010010000000110000010110011110110010101101111001111010000010000000001101101110
第2次点击时发送窗口中的二进制比特数据:
10001111011110010111100111110110111100000001101101011010100111100001011001101111011000010110101111000010010110101101111110101100001111011000010110101111000001111101001111010011111011110110101110001110
接收:将因特网中的 AS 分为 area.
点击“接收数据”的次数 4 。
第1次点击时接收窗口中的二进制比特数据:
0101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101011000111010101111011111011111100101101001011011000011001100111111000011001101111010000011010110110000100101101010100000001110010101010101
CRC检验正确
1010101110111101 –将
1111001011010010 –因
1101100011001100 –特
1111100011001101 –网
1101000011010110 –中
1100010010110101 –的
第2次点击时接收窗口中的二进制比特数据:
010101010101010101010101010101010101010101010101010101010101010101010101011000100010000000100000010101001100100000000000011011100101010101010101010101
00100000 –‘空格’
01000001 –A
01010011 –S
00100000 –‘空格’
第3次点击时接收窗口中的二进制比特数据:
0101010101010101010101010101100011110101101011011111010101011001111000110000011101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101
1101011010110111 –分
1010101011001110 –为
第4次点击时接收窗口中的二进制比特数据:
0101010101010001000100000001100000101111001001100101011000001001011110010110000111010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101
00100000 –‘空格’
01100001 –a
01110010 –r
01100101 –e
01100001 –a
00101110 –.
(2)信道有差错误码时,发送/接收的文字内容:
发送:Shared Tree 的形成仅基于多播组
点击“发送”的次数 5 。
第1次点击时发送窗口中的二进制比特数据:
100010010100110110100000110000010111100100110010101100100000100000001010100001111001001100101011001010010000001100101001110
第2次点击时发送窗口中的二进制比特数据:
100010010100110110100000110000010111100100110010101100100000100000001010100001111001001100101011001010010000001100101001110

第3次点击时发送窗口中的二进制比特数据:
100011110000100101101011110011110110100000110010011011001111111011010111110111111100110111101111101101011010011111100000010110110101001011011001011110100111101011111100111001110
第4次点击时发送窗口中的二进制比特数据:
100011110000100101101011110011110110100000110010011011001111111011010111110111111100110111101111101101011010011111100000010110110101001011011001011110100111101011111100111001110
第5次点击时发送窗口中的二进制比特数据:
100011110000100101101011110011110110100000110010011011001111111011010111110111111100110111101111101101011010011111100000010110110101001011011001011110100111101011111100111001110
接收:一组虚电路组成 virtual path
点击“接收数据”的次数 7 。

第1次点击时接收窗口中的二进制比特数据:
010101010101010101010101010101010101010101010101010001110111101111101001011110100111101011111110100111101000001111001111101101011100111101110101010101010101
CRC检验正确
1011101111010010 –一
1110100111010111 –组
1110100111010000 –虚
1110011110110101 –电
第2次点击时接收窗口中的二进制比特数据:
0101010101010101100011101101111110000010111101001111010111111001001101100110000001001110010101010101010101010101010101010101
CRC检验正确
1011011111000010 –路
1110100111010111 –组
1100100110110011 –成
第3次点击时接收窗口中的二进制比特数据:
0101010101010001000100000001111011001101001011110010011110100001111010111000010011100101010101010101
CRC检验正确
00100000 –‘空格’
01110110 –v
01101001 –i
01110010 –r
01110100 –t
01110101 –u
第4次点击时接收窗口中的二进制比特数据
010101100010010000001011011100001000000010110000001100000101111010000110100001110000101110010101010101010101010101
CRC失败
第5次点击时接收窗口中的二进制比特数据
010101010101010101010101010101010101010101010101010001001000000101101100000100000001111000000110000010111101000011010000111010010111010101010101010101
CRC失败
第6次点击时接收窗口中的二进制比特数据
01010101010101010101010101010101010101010101010100010011000011011011000001000000011110000001100000101011010000110100001110100101110101010101
CRC失败
第7次点击时接收窗口中的二进制比特数据
01010101010110001001100000101101100000100000001111000000110000010111101000011010000111010010111001010101010101010101010101010101010101010101010101
CRC检验正确
01100001 –a
01101100 –l
00100000 –‘空格’
01110000 — p
01100001 –a
01110100 –t
01101000 –h

八、实验数据及结果分析:

已在第七部分体现

九、总结及心得体会:

1、实验总结
1.1
在初始协议设计中,我们在考虑帧的定界问题时,只考虑到在帧的内部出现帧头帧尾要进行字符填充,我们初始选用了10110作为帧头,正是由于考虑问题不全面,我们忽略了前导序列可能造成的帧定界错误问题,例如如果10110前面是101序列,即构成10110110,不难发现,这会造成帧头定界前移,而导致整个帧出错。所以在实验过程中,我们的decode.py脚本无法起到对比特序列中帧头的定位问题,需要人工手动去进行多次鉴定,造成实验效率低下。在实验之后,修改帧头为10001,帧尾为01110,在本地局域网的环境中重新进行了实验,并重新记录了数据
1.2
对于汉字、字符我们采用GBK和ASCII编码,即16Bit、8Bit,如果要传送的数据是字符、汉字交替出现,我们就要一个汉字或一个字符进行成帧,对于这种情况处理,我们的设计,信道利用率不高。
2、本实验小组所设计的通信协议解决了计算机通信中的哪些问题?
我们主要解决在数据链路层,两台计算机进行通信时,帧的定义,包括帧的定界问题(帧头帧尾选取、字符填充),信息的表示问题(GBK、ASCII),差错控制问题(CRC),以及ARQ问题(停-等协议)
3、在实验过程中,是否遇到通信信息丢失或错误的问题?如果有,请描述这些问题;并结合通信模拟软件的功能和使用方法,以及设计的通信协议,讨论问题产生的原因及其解决方案。
当误码率为0时,我们的协议在传送连续的字符、或者连续的汉字时,效率不错,没有出现信息丢失、错误的问题;
当误码率上调至千分之20时,在接收方都出现了数据传输,CRC检验失败,即在传输过程中,数据出现了错误。解决方案:当误码率一定时,要想让帧尽量不出错,我们可以适当缩短帧的长度,即可以减少一个帧一次携带的信息数量。

十、对本实验过程及方法、手段的改进建议:

在实验室的win732位的操作系统中,实验提供的code.exe程序会在某种情况下不能正常进行编码,需重启软件或频繁切换输入法解决问题,此问题在win10 64位中没有出现过,由于实验时间有限,没有准确定位这个问题根源。

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇