UDT協議實現分析總結

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。