技术论坛

 • 产品分类
 • 咱工程师的故事
 • 培训与认证答疑专区
 • 服务合作伙伴专区

 TCP通讯过程中硬件连接突然断开

返回主题列表
作者 主题
X没有昵称X
侠客

经验值:656
发帖数:68
精华帖:2
楼主    2024-03-27 10:43:43
主题：TCP通讯过程中硬件连接突然断开 精华帖 

最近看了赵欣大佬的通信原理探秘又结合在工作中遇到的问题，关注到了通讯中的KeepAlive定时器的设置，所以做了如下实验。

硬件：

1513PLC  TCP客户端

PC   TCP服务器

前提条件：禁用PLC侧KeepAlive


程序：

测试流程：

  1. 打开PC端网络调试助手，设置为TCP服务器，打开链接；

  2. PC端打开WireShack软件，开启数据捕捉；

  3. 博途中打开Trace，设置观察数据；

  4. 博途在线 设置"TestDB".TCPtoPC.SedLEN为1000，即发送的数据长度为1000，置位"TestDB".TCPtoPC.CONNT，等待链接建立后，置位"TestDB".UDPtoPC.SedREQ开启发送；

  5. 发送过程中，拔掉PLC与PC链接的网线；

  6. 等待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秒重连？

学习的姿态是谦卑的
您收到0封站内信：
×
×
信息提示
很抱歉！您所访问的页面不存在，或网址发生了变化，请稍后再试。