UDT的整體結構

UDT Socket是UDT中的核心，同時它也是一座橋梁，它將UDT的使用者應用程序與內部實現部分對于數據結構的管理、網絡數據的傳輸連接起來。

應用程序通過它將數據放進發送緩沖待發送，或者借由它來獲取從網絡接收數據。而與網絡進行交互的部分，則從它那里拿到要發送的數據進行發送，或者在收到packet時將packet dispatch給它。

UDT的數據接收部分框架：

UDT的數據發送部分框架：

UDT的一些問題

1. 接口的合理性。

分析了UDT的這許多code，給人的感覺就是，socket接口設計的似乎并不是特別的合理。socket的兩種類型，即用于進行數據傳輸的socket和服務器端用于接受連接的socket，兩者之間的差別非常的明顯。它們所能提供的操作，它們的狀態轉換過程都很不一樣，服務器端用于接受連接的socket支持listen和accept操作，而用于進行數據收發的socket則不支持；同樣用于進行數據收發的socket支持send和recv，服務器端用于接受連接的socket則不支持。但當前的socket接口統一用一個socket來表示。也就是有多種其實毫不相干的職責都被堆在一個socket結構上了。

socket接口這樣的設計所帶來的問題就是使用起來比較容易混淆，對用戶的友好度比較低。即在執行某個操作之后才能通過返回值檢測出來，而不能在調用函數時，就通過編譯error之類的提前報出來。而實現起來呢，則不得不增添許多額外的狀態檢查，大大增加了實現的復雜度。

2. 有些地方存在大段大段的重復code。

比如CUDTUnited::updateMux()函數，CUDTUnited的兩個bind()函數之間，CUDT::sendmsg()和CUDT::send()中等待發送緩沖區有空間部分的code，CUDT中兩個connect()函數中初始化CUDT的操作等等。

3. 在CUDT中竟然用了m_bOpened，m_bListening等8個bool變量來表示UDT Socket的狀態，這使得狀態管理的復雜度大為增加。

4. Code中還是有一些歷史遺留問題，比如DelayWarning/CongestionWarning消息，定時器中對于NAK消息的發送等，這些機制被移除掉，但是又被移除的不是很徹底。

5. 消息類型這種本應該定義為enum或者類似的東西的常量，卻是magic number滿天飛。

在github上建了一個repo，https://github.com/hanpfei/hudt，目前基本上還是原始的UDT code，后面有機會了希望能有人一起改善現有UDT的一些問題。

Done。

總結

以上是生活随笔為你收集整理的oracle udt 解析,UDT协议实现分析总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。