SB 是一種非常可靠的網(wǎng)絡介質(zhì)，不會發(fā)生沖突。這意味著幾乎沒有數(shù)據(jù)包丟失或損壞。因此，互操作性測試從未在數(shù)據(jù)包丟失時檢測到 cornercases。
    然而，對于新興的無線 USB 連接，情況有所不同。由于無線介質(zhì)中存在沖突的可能性，因此在將應用程序從有線 USB 遷移到無線 USB 時必須小心。
    本文解決了有線和無線 USB 中都可能發(fā)生的問題。但是因為在無線介質(zhì)中丟失數(shù)據(jù)包的機會要大得多，所以問題更可能發(fā)生在無線 USB中而不是有線 USB中。問題是“丟失一個數(shù)據(jù)包的危險”。
    當開發(fā)人員忽視這個問題時，即使丟失一個數(shù)據(jù)包也會導致嚴重的問題。本文旨在幫助無線 USB 開發(fā)人員了解問題并為實施解決方案提供一些線索。

    它首先對問題進行了詳細描述，然后分析了為什么它在無線 USB 中成為問題，而在有線 USB 中不是問題。文末會給出解決這個問題的一些線索。

    圖 1：當設備需要向主機發(fā)送完整的數(shù)據(jù)緩沖區(qū)，而主機為一個數(shù)據(jù)包發(fā)送的握手丟失時，可能會出現(xiàn)實現(xiàn)問題。
    當它發(fā)生時當設備需要向主機發(fā)送完整的數(shù)據(jù)緩沖區(qū)并且主機為傳輸中的一個數(shù)據(jù)包（或突發(fā)中的幾個數(shù)據(jù)包）發(fā)送的握手被破壞或在空中丟失時，就會出現(xiàn)這個特殊問題。
    由于主機必須發(fā)送握手的短次數(shù)，因此設備端可能看不到那些包含數(shù)據(jù)包中一個批量（或突發(fā)中的幾個數(shù)據(jù)包）的握手的微調(diào)度管理命令 (MMC)。
    在這種情況下，設備必須將那部分數(shù)據(jù)保存在緩沖區(qū)中，直到它看到握手（如果有的話）以保持數(shù)據(jù)完整性。這種情況將導致實施中出現(xiàn)問題，如上圖 1 所示。
    在這種情況下，設備將不會引發(fā)任何中斷或任何事件來向更高層軟件指示數(shù)據(jù)已被主機正確接收。事實上，它不應該，因為設備認為本次傳輸?shù)囊徊糠謹?shù)據(jù)沒有成功傳輸?shù)街鳈C端，主機可以再次輪詢數(shù)據(jù)。
    如果更高層協(xié)議的狀態(tài)機（例如類驅(qū)動程序）需要這種顯式的握手/中斷才能進入下一階段，那么整個狀態(tài)機將被卡住。這將導致死鎖情況，并且整個設備實現(xiàn)將無法處理這種情況。

    請記住，丟失一個數(shù)據(jù)包的問題在無線 USB 中并不常見，在有線 USB 中也可能發(fā)生。設計師在設計有線 USB 時也必須注意這一點。不同之處在于，無線媒體的可靠性遠低于有線媒體。

    圖 2：顯示了一些軌跡以說明當設備未看到 IN 的握手時發(fā)生的大容量存儲問題。
    與數(shù)據(jù)包幾乎從不丟失的有線 USB 相比，數(shù)據(jù)包會經(jīng)常丟失。萬一設計人員忽視了這個問題，在有線系統(tǒng)中發(fā)現(xiàn)的可能性非常低，但在無線 USB 中卻相當高。讓我們舉一個實際的例子。在大容量存儲設備實現(xiàn)的情況下，以下序列總是發(fā)生多次：
    CBW—BULKOUT—31 字節(jié)數(shù)據(jù)階段—BULK IN或 BULK OUT—數(shù)據(jù)包大小的多個事務CSW – IN—13 字節(jié)特別是對于大容量存儲，當設備未看到 IN – 13 字節(jié)的握手時，可能會出現(xiàn)此問題。上面的圖 2中顯示了一些軌跡 來說明這個問題。

    在下面的圖 3中，無線 USB 數(shù)據(jù)包 291 是來自主機的 MMC，其中包括一個 WdtCTA，用作對先前 In 數(shù)據(jù)包（無線 USB 數(shù)據(jù)包 288）的確認。只有當設備收到此 MMC 時，它才能聲明特定的數(shù)據(jù)包已被主機接收。在這種特殊情況下，設備在接收到嵌入在數(shù)據(jù)包 291 中的確認之前，無法聲稱 CSW 數(shù)據(jù)包已成功傳送到主機。但是如果此數(shù)據(jù)包在空中丟失怎么辦？從這個特定的主機實現(xiàn)中，我們可以看到它只會發(fā)送帶有確認的 MMC。在無線世界中，丟失此數(shù)據(jù)包的可能性不容忽視。

    圖 3：在無線世界中，丟失數(shù)據(jù)包 291 的可能性——來自主機的 MMC，其中包括一個 WdtCTA，用作對先前 In 數(shù)據(jù)包的確認——不可忽略。
    在一些為大容量存儲編寫的傳統(tǒng) USB 類驅(qū)動程序中，類驅(qū)動程序內(nèi)部的狀態(tài)機只有在收到狀態(tài)完成事件時才會被觸發(fā)（在大多數(shù)情況下，它是來自設備控制器的中斷或來自較低級別堆棧的事件）。
    更具體地說，在大容量存儲狀態(tài)機中，類驅(qū)動程序總是期望在 IN 管道上完成接收 CSW 的 13 個字節(jié)，然后再進行進一步的操作，例如，將狀態(tài)機移至 CBW 階段，并對設備控制器進行編程以在出管。
    如果 CSW 的 ACK 被破壞，雖然它實際上被無線 USB 主機接收到，但主機端和設備端的類驅(qū)動程序狀態(tài)機之間將存在不匹配。主機會將類狀態(tài)機移至 CBW 階段，如果發(fā)現(xiàn)特定的 OUT 管道處于活動狀態(tài)，則隨時準備發(fā)送 CBW。
    但不幸的是，OUT 管道使能操作通常是由設備類狀態(tài)機的 CBW 階段的一些軟件操作觸發(fā)的。這意味著在總線上不會有任何用于 EPxOUT 的 DN_EPRdy 被發(fā)送出去以指示管道處于活動狀態(tài)。同時，設備類狀態(tài)機將保持在 CSW 階段，等待 CSW 完成（設備無法知道 CSW 數(shù)據(jù)包已被主機接收，除非已從設備安排進一步傳輸）。由于這種不匹配，產(chǎn)生了死鎖。
    設備端管理設備端的類驅(qū)動程序需要仔細管理這種情況，考慮到“丟包”的情況。大容量存儲中此問題的典型解決方案是更改狀態(tài)機，以便 CBW 的 OUT 管道將在設備類狀態(tài)機的 CSW 階段內(nèi)激活，因此設備端不會阻塞下一個 CBW 的總線活動。該解決方案適用于解決大容量存儲類和其他情況下 CSW 丟失的 ACK。
    在無線 USB 世界 - 甚至是有線 USB 世界 - 設備端的任何類驅(qū)動程序定義了一個協(xié)議，該協(xié)議在 IN 端點傳輸完成后將數(shù)據(jù)包發(fā)送到 OUT 端點必須注意它在編程后啟用 OUT 數(shù)據(jù)包的接收。在轉(zhuǎn)移。它必須等到看到 IN 傳輸完成中斷后才能啟用 OUT 數(shù)據(jù)的接收。