Protocol-Independent頻外資料

資料流程通訊端抽象概念包括頻外 (OOB) 資料的概念。 許多通訊協定允許以某種方式將傳入資料的某些部分標示為特殊，而且這些特殊資料區塊可以傳遞給使用者超出一般順序。 範例包括 X.25 和其他 OSI 通訊協定中的加速資料，以及 BSD UNIX 使用 TCP 的緊急資料。 下一節會以與通訊協定無關的方式描述 OOB 資料處理。 討論使用 TCP 緊急資料實作的 OOB 資料，會遵循與通訊協定無關的說明。 在每個討論中， 使用 recv 也表示 recvfrom、 WSARecv和 WSARecvFrom，以及 WSAAsyncSelect 的參考也適用于 WSAEventSelect。

通訊協定獨立 OOB 資料

OOB 資料是與每對連線資料流程通訊端相關聯的邏輯獨立傳輸通道。 OOB 資料可能會獨立于一般資料外傳送給使用者。 抽象概念定義 OOB 資料設備必須一次支援至少一個 OOB 資料區塊的可靠傳遞。 此資料區塊可以包含至少一個位元組的資料，而且至少一個 OOB 資料區塊可以隨時擱置傳送給使用者。 對於支援頻內訊號 (的通訊協定，例如 TCP，緊急資料會依序傳遞與一般資料) ，系統通常會從一般資料流程擷取 OOB 資料，並將它個別儲存 (讓正常資料流程) 。 這可讓使用者依序選擇接收 OOB 資料，以及依序接收它，而不需要緩衝處理所有資料。 可以查看頻外 (OOB) 資料。

使用者可以判斷是否有任何 OOB 資料正在等候使用 ioctlsocket 或 WSAIoctl 函式搭配 SIOCATMARK IOCTL 讀取。 對於 OOB 資料區塊在一般資料流程中位置概念有意義的通訊協定，例如 TCP，Windows Sockets 服務提供者會維護概念標記，指出 OOB 資料在一般資料流程中最後一個位元組的位置。 這不需要實作支援SIOCATMARK的ioctlsocket或WSAIoctl函式。 需要 OOB 資料存在或不存在。

對於 OOB 資料區塊在一般資料流程中位置概念有意義的通訊協定，應用程式可能會在一般資料流程中處理頻外資料內嵌。 使用 setsockopt 函式設定通訊端選項SO_OOBINLINE即可達成此目的。 對於 OOB 資料區塊真正與一般資料流程無關的其他通訊協定，嘗試設定SO_OOBINLINE會導致錯誤。 應用程式可以使用 ioctlsocket 或 WSAIoctl 函式搭配 SIOCATMARK IOCTL 來判斷標記前面是否有任何未讀取的 OOB 資料。 例如，它可以使用這項資訊來重新同步處理其對等，方法是確保適當時會捨棄資料流程中標記的所有資料。

停用SO_OOBINLINE (預設設定) ：

• 如果應用程式向 WSAAsyncSelect註冊通知，Windows Sockets 會通知應用程式FD_OOB事件，其方式與FD_READ用來通知一般資料是否存在的方式完全相同。 也就是說，當 OOB 資料抵達且先前未排入佇列的 OOB 資料時，就會張貼FD_OOB。 當使用 MSG_OOB 旗標讀取資料時，也會張貼FD_OOB，而某些 OOB 資料在讀取作業傳回後仍會排入佇列。 FD_READ訊息不會針對 OOB 資料張貼。
• 如果 OOB 資料已排入通訊端上的佇列，Windows Sockets 會從 select 傳回適當的 exceptfds 通訊端集。
• 應用程式可以使用 MSG_OOB 呼叫 recv ，隨時讀取緊急資料區塊。 OOB 資料的區塊會跳躍佇列。
• 應用程式可以在不MSG_OOB的情況下呼叫 recv ，以讀取一般資料流程。 OOB 資料區塊不會出現在具有一般資料的資料流程中。 如果在對recv的任何呼叫之後仍保留 OOB 資料，Windows Sockets 會在使用select時通知應用程式FD_OOB或例外狀況。
• 對於 OOB 資料在一般資料流程中具有位置的通訊協定，單一 recv 作業不會跨越該位置。 一個 recv 會在標記之前傳回一般資料，而第二個 recv 則需要開始讀取標記之後的資料。

啟用SO_OOBINLINE：

• FD_OOB訊息不會針對 OOB 資料張貼。 OOB 資料會被視為一般，以便 選取 和 WSAAsyncSelect 函式，並以 readfds 或分別傳送FD_READ訊息來指出通訊端。
• 應用程式無法呼叫 recv ，並將 MSG_OOB 旗標設定為讀取 OOB 資料區塊。 傳回錯誤碼 WSAEINVAL。
• 應用程式可以在未設定MSG_OOB旗標的情況下呼叫 recv 。 任何 OOB 資料會以正常資料流程內的正確順序傳遞。 OOB 資料永遠不會與一般資料混合。 必須有三個讀取要求，才能超過 OOB 資料。 第一個會傳回 OOB 資料區塊之前的一般資料，第二個會傳回 OOB 資料，第三個會傳回 OOB 資料之後的一般資料。 換句話說，會保留 OOB 資料區塊界限。

當SO_OOBINLINE關閉時， WSAAsyncSelect 常式特別適合處理頻外資料存在通知。

TCP 中的 OOB 資料

重要

下列討論使用 TCP 緊急資料實作的頻外資料 (OOB) ，遵循 Berkeley 軟體發佈中使用的模型。 使用者和實作者應該注意：

 

• 目前有兩個 RFC 793 (引進概念) 衝突的解譯。

• 連線軟體發佈 (BSD) 中 OOB 資料的實作不符合 RFC 1122中指定的主機需求。

  具體而言，BSD 中的 TCP 緊急指標會指向緊急資料位元組之後的位元組，而符合 RFC 標準的 TCP 緊急指標指向緊急資料位元組。 因此，如果應用程式將緊急資料從 BSD 相容實作傳送至與 RFC 1122 相容的實作，接收者會讀取錯誤的緊急資料位元組， (它會讀取資料流程中正確位元組之後的位元組作為緊急資料位元組) 。

  若要將互通性問題降到最低，除非這是與現有服務交互操作的必要專案，否則建議應用程式寫入器不要使用 OOB 資料。 Windows Sockets 供應商很鼓勵記錄其產品實作的 OOB 語意 (BSD 或 RFC 1122) 。

具有適用于緊急) 旗標集之 (TCP 區段的 TCP 區段，表示 TCP 資料流程中是否有單一位元組的 OOB 資料。 OOB 資料區塊的大小為一個位元組。 緊急指標是 TCP 標頭中目前序號的正位移，表示 OOB 資料區塊的位置 (模棱兩可，如上述) 所述。 因此，它可能會指向尚未收到的資料。

如果SO_OOBINLINE停用 (緊急指標所指向之位元組的 TCP 區段到達時，預設) ，則會從資料流程中移除一個位元組) 的 OOB 資料區塊 (。 如果後續 TCP 區段到達時， (設定緊急旗標，而新的緊急指標) ，則目前已排入佇列的 OOB 位元組可能會遺失，因為它會由新的 OOB 資料區塊取代， (如) 中所發生。 不過，它永遠不會在資料流程中取代。

啟用SO_OOBINLINE後，緊急資料會保留在資料流程中。 因此，當新的 TCP 區段送達包含緊急資料時，永遠不會遺失 OOB 資料區塊。 現有的 OOB 資料標記會更新為新的位置。

注意

設定SO_OOBINLINE通訊端選項時，SIOCATMARK IOCTL 一律會傳回 TRUE，而 OOB 資料會以一般資料的形式傳回給使用者。