usb的数据包要求接收方返回一个ACK，这个ACK要driver发送吗？-CSDN论坛

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

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

⋅请问：Remoting中，订阅事件的时候为啥要出System.Reflection.TargetInvocationException 附代码 ⋅Remoting中，订阅事件的时候出System.Reflection.TargetInvocationException ⋅usb的数据包要求接收方返回一个ACK，这个ACK要driver发送吗？ 更多帖子 关注空间博客 小静 本版专家分：0 结帖率 50%: 0 2001-07-19 17:37:17 回复次数1

引用・举报・楼主

如果要，格式是怎样的？

问题点数：0分

CSDN今日推荐

⋅真是天上掉馅饼，用Dragon Ball和WinCE做个东东出来，大家说说做什么好 ⋅真是天上掉馅饼，用Dragon Ball和WinCE做个东东出来，大家说说做什么好 ⋅高手救命哦,谁做过x86的汇编实现两个双精度浮点数的相加? 更多帖子 关注空间博客 emailcdh 本版专家分：0: 0 2001-07-21 23:46:46

引用・举报・ #1 得分：0

不用driver来发送这个ACK，硬件会完成这个工作。我们一般用的和开发的driver只起个分发作用。不负责这些细节问题。

收藏帖子

注册

其他相关推荐

TCP发送端收到ACK后对传输队列的4次扫描: TCP如果收到ACK后，不管是顺序ACK还是重复ACK(可能带有SACK选项)，都可能对传输队列进行4次扫描，它们先后顺序分别是：1.第一遍扫面，分别做以下事情：1.1.标记被SACK的数据包1.2.标记哪些已经重传的包可能丢失1.3.更新网络乱序度reordering整个故事如下图所示：如果UNA向前推进了，我们就不多说了，如果没有推进UNA，而且有SACK标记(请注意，FACK并不是一种特殊的

TCP连接建立系列 — 客户端接收SYNACK和发送ACK: 主要内容：客户端接收SYNACK、发送ACK，完成连接的建立。内核版本：3.15.2 我的博客：http://blog.csdn.net/zhangskd 客户端主动建立连接时，发送SYN段后，连接的状态变为SYN_SENT。此时如果收到SYNACK段，处理函数为tcp_rcv_state_process()。

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

Linux 内核网络协议栈 ------ tcp_ack 函数处理接收到的ACK包之后: 注意 tcp_ack 是来处理接收到的ACK的，那么到底怎么去做呢？看下面：先还上把tcp_sock的结构放在这里，下面一些数据的分析需要用到： struct tcp_sock { /* inet_connection_sock has to be the first member of tcp_sock */ struct inet_conn

17-TCP 协议（迟到的 ACK —— Windows ）: 1. 引言我们知道，TCP 协议中，需要对接收到 TCP 段进行确认。有两种方式可以减少 TCP 报文段. 一种是累积确认，另一种是捎带确认。累积确认有时候，发送方发送速度非常快，接收方一下下接收到了好几个 tcp 段，可以通过累积确认的方式，一次确认好几个 tcp 段，这样减少报文段的传输。捎带确认有时候，双方互相发送数据，当接收到对方的 tcp 段后，先不着急确认，而是等待一会儿，连同数

TCP重发机制: TCP协议是一个可靠的协议。它通过重新发送(retransmission)来实现TCP片段传输的可靠性。简单的说，TCP会不断重复发送TCP片段，直到片段被正确接收。 TCP片段丢失 TCP头部的checksum 接收方(receiver)可以通过校验TCP片段头部中checksum区域来检验TCP片段是否出错。我们已经接触过了IP协议详解的checksum算法

TCP的ACK确认系列 — 发送状态转换机: 主要内容：TCP的ACK发送方式，以及ACK发送状态转换机的实现。内核版本：3.15.2 我的博客：http://blog.csdn.net/zhangskd 概述 TCP采用两种方式来发送ACK：快速确认和延迟确认。在快速确认模式中，本端接收到数据包后，会立即发送ACK给对端。在延迟确认模式中，本端接收到数据包后，不会立即发送ACK给对端，而是等待一段时间，如果在此

流量整形，延迟以及ACK丢失对TCP发送时序的影响: TCP是一个连续不断的涓涓细流或者滚滚长江，但这只是理想情况！经过诸多中间网络设备，最终一个TCP流到达接收端的时候，将可能不再保持一个流的形式，而变成了一阵阵的突发...这些突发产生的ACK反过来反馈到发送端，进而对发送端的发送时序产生影响，也就是说对发送端的数据流进行整形，这真是一个典型的涡轮增压反馈系统，根本不是通常认为的那样不可控或者说另一个极端，仅仅是端到端！想驾驭它其实不是那么难，如果

四-网络性能排查之TCP重传与重复ACK: TCP错误恢复功能： TCP的错误恢复功能是定位，诊断及修复网络延时的最佳工具。延时可以在单程也可以往返方向测量。高延时是网络管理员的头号大敌。本节我们讨论TCP高延时是如何导致序列号和确认号乱序的。 TCP重传：主机报文重传是TCP最基本的错误恢复功能，它的目的是防止报文丢失。报文丢失的可能因素有很多种，包括应用故障，路由设备过载，或暂时的服务宕机。报文级别速度是很高

TCP的接收缓冲区满了，收到数据后会向发送方发送ACK吗？该怎么解决: TCP的接收缓冲区满了，收到数据后会向发送方发送ACK吗？ TCP的发送缓冲区中的数据，如果收不到接收方的ACK就不会删除，导致发送缓冲区溢出。如果接收方的缓冲区满了，收到数据后会不会向发送方发ACK呢？如果不发ACK，那么就没有接收缓冲区溢出的概念了，只要控制住发送方，就不会丢包；如果发ACK，那发送方就没办法控制是否继续发送了，接收缓冲区就会造成溢出，导致丢包。事实是怎样的呢？我这样理解正确

关闭

关闭