CANoe自带的TCP/IP协议中TCP发送时的一个特殊处理(我一定是第一个发现的)

本文探讨了在CANoe软件中使用TCP/IP协议栈进行以太网通信时,当发送数据未被ACK确认而触发重传的情况。在重传过程中,CANoe的TCP协议栈会将未确认的原始数据与发送队列中的新数据一起发送,这是一个特殊处理,并非标准TCP协议的行为。文章提供了相关的CAPL代码示例。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

我们知道,CANoe软件中配置以太网通道后,添加的仿真节点可以作为一个主机或者一个应用来实现以太网通信。但不管是作为主机还是应用,仿真节点都需要配置TCP/IP协议栈。

TCP/IP Stack

有了TCP/IP协议栈,设置了网卡信息后(IP地址、MAC地址等),仿真节点就可以通过编写CAPL代码的方式发送和接收报文。

在使用TCP协议发送数据时,一般有No Delay和Delay(Nagle算法)两种。对于采用Nagle算法的方式,如果发送的数据(小段)不被接收方响应(ACK)确认,会怎么样?

只要稍微了解TCP协议的人肯定知道,会按照重传定时器的timeout重传。如果此时发送队列恰好有数据要发送呢?

发送数据段
上图中,发送方发送TCP数据段12345,接收方一直不回复。于是发送方重传:

重传数据段

发现TCP重传的tcp报文中,数据是12345abcdeABCDE,其中12345是重传队列的,而abcdeABCDE是发送队列

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

汽车通信技术

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值