CSDN论坛 > 网络与通信 > 网络通信

usb的数据包要求接收方返回一个ACK,这个ACK要driver发送吗? [问题点数:0分]

Bbs1
本版专家分:0
结帖率 50%
CSDN今日推荐
Bbs1
本版专家分:0
匿名用户不能发表回复!
其他相关推荐
TCP:SEQ号与ACK号
三次握手Three-way Handshake 一个虚拟连接的建立是通过三次握手来实现的 1. (B) –> [SYN] –> (A) 假如服务器A和客户机B通讯. 当A要和B通信时,B首先向A发一个SYN (Synchronize) 标记的包,告诉A请求建立连接. 注意: 一个 SYN包就是仅SYN标记设为1的TCP包(参见TCP包头Resources). 认识到这点很重要,只有
TCP连接建立系列 — 客户端接收SYNACK和发送ACK
主要内容:客户端接收SYNACK、发送ACK,完成连接的建立。 内核版本:3.15.2 我的博客:http://blog.csdn.net/zhangskd   客户端主动建立连接时,发送SYN段后,连接的状态变为SYN_SENT。 此时如果收到SYNACK段,处理函数为tcp_rcv_state_process()。
流量整形,延迟以及ACK丢失对TCP发送时序的影响
TCP是一个连续不断的涓涓细流或者滚滚长江,但这只是理想情况!经过诸多中间网络设备,最终一个TCP流到达接收端的时候,将可能不再保持一个流的形式,而变成了一阵阵的突发...这些突发产生的ACK反过来反馈到发送端,进而对发送端的发送时序产生影响,也就是说对发送端的数据流进行整形,这真是一个典型的涡轮增压反馈系统,根本不是通常认为的那样不可控或者说另一个极端,仅仅是端到端!想驾驭它其实不是那么难,如果
USB协议中的返回包含义
三种返回确认信息 ACK 、NAK 、STALL 【ACK 包】 ACK(确认) 表示 主机和设备已经收到数据,没有出现错误。设备必须在Setup 事务的交换包中返回ACK,设备也必须在OUT事务的交换中返回ACK。 主机在IN事务的交换包中返回ACK。 【NAK 包】(NAK包只能从设备发向主机) NAK(未确认) 表示设备正忙或没有数据要返回。如果主机在设备太忙而不能接受数
TCP三次握手第三次握手时ACK丢失怎么办
当Client端收到Server的SYN+ACK应答后,其状态变为ESTABLISHED,并发送ACK包给Server; 如果此时ACK在网络中丢失,那么Server端该TCP连接的状态为SYN_RECV,并且依次等待3秒、6秒、12秒后重新发送SYN+ACK包,以便Client重新发送ACK包。 Server重发SYN+ACK包的次数,可以通过设置/proc/sys/ne
7.4 FIN及其ACK的接收
TCP在收到FIN时,会调用tcp_data_queue函数进行处理: 4300 static void tcp_data_queue(struct sock *sk, struct sk_buff *skb) 4301 { 4302 const struct tcphdr *th = tcp_hdr(skb); 4303 struct tcp_sock *tp = tcp_s
TCP协议RST:RST介绍、什么时候发送RST包
一、RST介绍       RST标示复位、用来异常的关闭连接。            1. 发送RST包关闭连接时,不必等缓冲区的包都发出去,直接就丢弃缓冲区中的包,发送RST。             2. 而接收端收到RST包后,也不必发送ACK包来确认。 二、什么时候发送RST包      1.  建立连接的SYN到达某端口,但是该端口上没有正在 监听的服务。
TCP的接收缓冲区满了,收到数据后会向发送方发送ACK吗?该怎么解决
TCP的接收缓冲区满了,收到数据后会向发送方发送ACK吗? TCP的发送缓冲区中的数据,如果收不到接收方的ACK就不会删除,导致发送缓冲区溢出。如果接收方的缓冲区满了,收到数据后会不会向发送方发ACK呢?如果不发ACK,那么就没有接收缓冲区溢出的概念了,只要控制住发送方,就不会丢包;如果发ACK,那发送方就没办法控制是否继续发送了,接收缓冲区就会造成溢出,导致丢包。事实是怎样的呢?我这样理解正确
四-网络性能排查之TCP重传与重复ACK
TCP错误恢复功能: TCP的错误恢复功能是定位,诊断及修复网络延时的最佳工具。延时可以在单程也可以往返方向测量。高延时是网络管理员的头号大敌。本节我们讨论TCP高延时是如何导致序列号和确认号乱序的。 TCP重传: 主机报文重传是TCP最基本的错误恢复功能,它的目的是防止报文丢失。 报文丢失的可能因素有很多种,包括应用故障,路由设备过载,或暂时的服务宕机。报文级别速度是很高
TCP重发机制
TCP协议是一个可靠的协议。它通过重新发送(retransmission)来实现TCP片段传输的可靠性。简单的说,TCP会不断重复发送TCP片段,直到片段被正确接收。 TCP片段丢失   TCP头部的checksum 接收方(receiver)可以通过校验TCP片段头部中checksum区域来检验TCP片段是否出错。我们已经接触过了IP协议详解的checksum算法
关闭