签到有奖
消息提醒
运维工程师专区
官方商城
扫码分享好友 任选多种周边
最近看了赵欣大佬的通信原理探秘又结合在工作中遇到的问题,关注到了通讯中的KeepAlive定时器的设置,所以做了如下实验。
硬件:
1513PLC TCP客户端
PC TCP服务器
前提条件:禁用PLC侧KeepAlive
程序:
测试流程:
打开PC端网络调试助手,设置为TCP服务器,打开链接;
PC端打开WireShack软件,开启数据捕捉;
博途中打开Trace,设置观察数据;
博途在线 设置"TestDB".TCPtoPC.SedLEN为1000,即发送的数据长度为1000,置位"TestDB".TCPtoPC.CONNT,等待链接建立后,置位"TestDB".UDPtoPC.SedREQ开启发送;
发送过程中,拔掉PLC与PC链接的网线;
等待PLC侧出现Busy后,暂停trace;
WireShack捕获如图
PC端WireShack抓包如图
上图1处为插入网线后PC端接收到的第一条数据,随后PC端TCP服务器主动断开,2秒后PLC侧主动重连。在第一次建立连接到网线断开处,可看出共收到11条数据。
疑问:
1500的StackBuffer共8192个字节,如上,网线断开后共有19-11=8条数据存入了StackBuffer中,若仅计算数据长度,则在这个期间内共有8*1000=8000字节数据存入StackBuffer中,若根据StackBuffer处于OSI参考模型的第4层,数据压入到StackBuffer中时带有TCP头部信息,则每条数据实际长度为1000+20=1020字节,则在这期间共有8*1020=8160字节数据压入到StackBuffer中。虽然两者的结果均可导致第17次发送时,ShadowBuffer中的1000字节数据无法压入StackBuffer中,导致Busy常为1。
另外为何断开网线 重新插入后,PC端接收到的第一条数据长度是1460字节?ShadowBuffer满通讯正常后,发送长度为何不按发送端发送的长度发送,而是以最大长度发送?
又为何服务器端会主动复位连接?
PLC是否是固定在连接异常后2秒重连?
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
帖子链接:https://www.ad.siemens.com.cn/club/bbs/post.aspx?b_id=66&a_id=1883992
你这个问题很好,是不是有可能是数据长度与响应时间不匹配的原因。。
这个还没研究这么细致哦
给你点个赞
这个是带着学习去测试,再去测试中找疑点。确实能学习到很多东西。
有针对性的测试学习,棒。
有机会学习一下
几年前测试硬件的时候发现的KeepAlive就是在TCP通讯空闲时,客户端和服务端会定时发送KeepAlive握手,确认是否处于连接断开状态而已,其他倒没什么,试过如果客户端和服务端没有启动KeepAlive机制,服务端和客户端空闲时就会断开连接
给楼主点赞
我也测试了KeepAlive关闭,但是没有像你说的空闲时会断开连接 不过我是PLC侧关闭了KeepAlive PC侧没操作 但是抓包没发现有KeepAlive握手
谢谢楼主,学习了。有机会试验一把
同一个设备建立连接的通讯指令 有一个就可以了
TSEND TRCV 有一个就可以了
多调用几个服务器就行了
分享
扫码分享好友 任选多种好礼
收藏
有帮助
1. 文件大小:上传文件的大小请限制在2M以内。
2. 文件格式:请不要上传.exe文件,系统支持的格式有:.avi,.wmv,.mp3,.rar,.zip,.doc,.docx,.xls,.xlsx,.ppt,.pptx,.pdf,.wma,.asf,.txt,.7z
欢迎您访问支持中心!
丰富的视频,全方位的文档,大量的网友交流精华……
为了更好的完善这些内容,我们诚邀您在浏览结束后,花20秒左右的时间,完成一个用户在线调查!
感谢您的支持!
密码至少8位,包含大、小写字母,数字和符号至少三种。
允许邮箱和手机接收来自支持中心网站的信息
我已同意《支持中心网站注册协议和隐私政策》
微信登录扫码一键登录
验证码登录
密码登录
二维码失效点击重试
打开微信扫一扫,快速登录/注册
未注册手机验证后自动登录,注册即代表同意《支持中心网站注册协议和隐私政策》
三日内免验证登录
短信登录
登录