专家大讲堂《PLC通信原理探秘》系列视频:https://www.ad.siemens.com.cn/service/elearning/series/288.html
最新更新:
连载之十四: 【PLC通信原理探秘】大讲堂幕后彩蛋之求助
连载之十五: 【PLC通信原理探秘】大讲堂幕后彩蛋之苦大
连载之十六: 【PLC通信原理探秘】大讲堂幕后彩蛋之愁深
连载之十七: 【PLC通信原理探秘】大讲堂幕后彩蛋之砥砺
连载之十八: 【PLC通信原理探秘】大讲堂幕后彩蛋之前行
在做TCP/IP测试数据发送和接收的过程中,发现当接收的一方的Shadow Buffer满,数据就会被读取到接收数据区,即接收侧的数据DB中,这里也体现了TCP的一个协议特点,即流式传输服务,例如,前面说过,发送侧第一次发送500B,第二次又发送500B,调用接收侧读取,长度预设1000B,会一次性收到1000B,也就是说两次发送的数据在接收端黏在了一起,并没有界限,这与UDP面向消息的传输不同,UDP的报文中包含长度信息,也就是说数据之间存在界限。
此外,在做发送和接收实验的过程中,发现了两个有趣的现象。第一个现象是我把网线断开,在发送端侧报错之前,短时间内,再次使能发送,会发现可以使能多次,而且Done信号也会出现。那么问题又来了,为什么在断开网线的情况下,发送端和接收端已然失去联系,数据还能发送多次?而且还有Done信号?还有这个短时间内是什么时间?第二个现象就是在网线一切完好的条件下,发送端的数据长度等于接收端的数据长度,就是我们经常使用的通信方式,接收端的功能块不使能接收,发送端使能多次发送,多次出现Done信号,直到Busy信号出现,而且这蕴含着数据发送的一些规律,也就是说Done的出现次数和Busy的出现时机,这又与什么相关呢?
通常我们考虑Done信号的时候,通过手册,只能看到数据发送完成出现Done信号,那么什么是数据发送完成,是对方一定要接收到吗?显然这里不是,因为在网线断开的情况下,依然会出现Done信号。既然手册或者在线帮助没有给我清晰的解答,那我需要好好研究一番。
初始的测试并没有给我带来什么可喜的结果,只能看到在网线断开后,手动使能发送数据,在一定数量的Done信号出现后,Busy信号出现,就不能发送了,只能看到这样的现象,但探求不到规律,从哪里入手呢?困惑而生!
于是又仔细的查看了一下相关的手册,手册中提到TCP的数据一致性的数据长度是8K,那就从8K下手,看看到底是什么样子?简单的程序如下,第一条指令就是TSEND的应用,发送长度为8K,第二条指令记录Done的次数,第三条指令记录Busy的次数。
首先,保证通信双方都能够正常收发,然后断开网线,快速使能发送,发现发送两次后,Busy=1。此时,发送不能再继续进行。根据前面的判断,说明此时的Shadow buffer大小为8K,意味着推送到缓冲区的数据为16K,那么除了Shadow buffer,还存在另外一个Buffer同样也是8K,否则Busy不能指示为1。那么这个Buffer又是什么?查看TCP的协议说明,证实该协议是TCP/IP的堆栈buffer,与TCP的滑动窗口Window Size大小8K一致。那么是这样吗?在做一个测试就是收发4K数据,减一半,那么发现同样的情况下,发送3次,Busy=1,这就是说4K数据被推送了3次,前两次的8K把TCP/IP的堆栈Buffer占满,最后一次占满了Shadow Buffer,因为发送是4K,所以Shadow buffer的大小就变为4K。最后,收发1K数据,现象是一致的。
这时,在去仔细的看一看Done的计数情况,断开网线的情况下,第一种收发8K,发送两次,Done=1,Busy=1;第二种收发4K,发送3次,Done=2,Busy=1,这说明Done信号表示的是数据从Shadow buffer中成功地推送到TCP/IP的堆栈Buffer中,则Done+1。这两种情况,都是发送的次数多于Done次数一次,这说明最后一次数据只是从DB中推送到Shadow buffer中,并没有指示Done信号置1,此时Busy=1,那么说明Busy信号表示的是数据把发送侧的所有的缓冲区占满。
通过这个测试和推理,就真正的理解了Done信号和Busy信号的真正含义。此外,这与TCP/IP协议的工作原理是一致的,对于Done,即“Send通常只是将数据复制到主机A的TCP/IP栈中,就返回了”;对于“Busy”,在滑动窗口的作用下,调节发送的速度。那么距离全面理解这两个Buffer,我想只是一步之遥。
----------未完待续----------
连载之二十: 【PLC通信原理探秘】大讲堂幕后彩蛋之之遥
连 载 汇 总: 【PLC通信原理探秘】系列连载故事汇总