如何减少无线 USB 网络应用中的数据包丢失
USB 是一种非常可靠的网络介质，不会发生冲突。这意味着几乎没有数据包丢失或损坏。因此，互操作性测试从未检测到数据包丢失时的特殊情况。
然而，对于新兴的无线 USB 连接来说，情况有所不同。由于无线介质中可能发生冲突，因此将应用程序从有线 USB 迁移到无线 USB 时必须小心。
本文解决了有线和无线 USB 中都可能出现的问题。但由于无线介质中丢失数据包的可能性要大得多，因此该问题在无线 USB中比在有线 USB中更容易发生。问题是“丢失一个数据包的危险”。
当开发人员忽视这一问题时，即使丢失一个数据包也可能会导致严重问题。本文旨在帮助无线 USB 开发人员了解该问题并为实施解决方案提供一些线索。
首先详细描述问题，然后分析为什么它在无线 USB 中成为问题，而在有线 USB 中不是问题。在文章的，将为解决这个问题提供一些线索。
图1：当设备需要向主机发送完整缓冲区的数据并且主机为一个数据包发送的握手丢失时，可能会出现实现问题。
当发生
这种情况时，当设备需要向主机发送完整的数据缓冲区，并且主机为传输中的一个数据包（或突发中的几个数据包）发送的握手在空中被破坏或丢失时，就会出现此特殊问题。
由于主机必须发送少次数的握手，因此设备端可能看不到那些包括一批数据包（或突发中的几个数据包）的握手的微调度管理命令（MMC）。
在这种情况下，设备必须将这部分数据保留在缓冲区中，直到它看到握手（如果有）以保持数据完整性。这种情况会导致实现中出现问题，如上图 1 所示。
在这种情况下，设备不会引发任何中断或任何事件来向高层软件指示主机已正确接收数据。事实上，不应该，因为设备认为本次传输中的一部分数据尚未成功传输到主机端，主机可能会再次轮询数据。
如果高层协议的状态机（例如类驱动程序）需要这种显式的握手/中断才能进入下一个阶段，那么整个状态机将被卡住。这将导致死锁情况，并且整个设备实现将无法处理这种情况。
请记住，丢失一个数据包的问题在无线 USB 中并不常见，在有线 USB 中也可能发生。设计人员在设计有线 USB 设备时也必须注意这一点。不同之处在于，无线介质的可靠性远低于有线介质。
图 2：显示了一些痕迹来说明当设备未检测到 IN 握手时发生的海量存储问题。
与有线 USB 相比，数据包经常丢失，而有线 USB 几乎不会丢失数据包。如果设计者忽略了这个问题，在有线系统中发现这个问题的机会非常低，但在无线 USB 中发现这个问题的机会相当高。让我们举一个实际的例子。在大容量存储设备实现的情况下，以下序列总是发生多次：
CBW—BULKOUT—31 字节
数据级—BULK IN
或 BULK OUT—
数据包大小的多个事务
CSW – IN—13 字节
特别是，对于大容量存储，当设备未检测到 IN – 13 字节的握手时，可能会出现此问题。上面的图 2中显示了一些痕迹 来说明这个问题。
在下面的图3中，无线USB数据包291是来自主机的MMC，其中包括WdtCTA，用作对先前的In数据包（无线USB数据包288）的确认。只有当设备接收到该MMC时，它才能声明特定的数据包。
主机已收到数据包。在这种特殊情况下，设备无法声明 CSW 数据包已成功传送到主机，直到收到数据包 291 中嵌入的确认。但是，如果该数据包在空中丢失怎么办？从这个特定的主机实现中，我们可以看到它只会发送带有确认的 MMC 。在无线世界中，丢失该数据包的可能性不可忽视。
图 3：在无线世界中，丢失数据包 291（来自主机的 MMC，其中包含用作先前输入数据包的确认的 WdtCTA）的可能性不可忽略。
在一些为大容量存储编写的传统 USB 类驱动程序中，类驱动程序内部的状态机仅在收到状态完成事件时才会被触发（在大多数情况下，它是来自设备控制器的中断或来自较低级别堆栈的事件）。
更具体地说，在大容量存储状态机中，类驱动程序总是期望 IN 管道完成接收 13 字节的 CSW，然后再进行进一步的操作，例如，将状态机移至 CBW 阶段并对设备控制器进行编程以在输出管。
如果 CSW 的 ACK 被破坏，尽管它实际上是由无线 USB 主机接收的，但主机端和设备端的类驱动程序状态机之间将会出现不匹配。主机会将类状态机移至 CBW 阶段，并且如果发现特定的 OUT 管道处于活动状态，则随时准备发送 CBW。
但不幸的是，OUT管道使能操作通常是由设备类状态机的CBW阶段中的某些软件操作触发的。这意味着总线上不会发送任何用于 EPxOUT 的 DN_EPRdy 来指示管道处于活动状态。同时，设备类状态机将保持在 CSW 阶段，等待 CSW 完成（设备无法知道主机已接收到 CSW 数据包，除非已从设备安排了进一步的传输）。由于这种不匹配，产生了死锁。
