如何減少無線 USB 網(wǎng)絡(luò)應(yīng)用程序中的數(shù)據(jù)包丟失

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

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

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

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

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

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

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