UDT的整體結(jié)構(gòu)

UDT Socket是UDT中的核心，同時它也是一座橋梁，它將UDT的使用者應(yīng)用程序與內(nèi)部實(shí)現(xiàn)部分對于數(shù)據(jù)結(jié)構(gòu)的管理、網(wǎng)絡(luò)數(shù)據(jù)的傳輸連接起來。

應(yīng)用程序通過它將數(shù)據(jù)放進(jìn)發(fā)送緩沖待發(fā)送，或者借由它來獲取從網(wǎng)絡(luò)接收數(shù)據(jù)。而與網(wǎng)絡(luò)進(jìn)行交互的部分，則從它那里拿到要發(fā)送的數(shù)據(jù)進(jìn)行發(fā)送，或者在收到packet時將packet dispatch給它。

UDT的數(shù)據(jù)接收部分框架：

UDT的數(shù)據(jù)發(fā)送部分框架：

UDT的一些問題

1. 接口的合理性。

分析了UDT的這許多code，給人的感覺就是，socket接口設(shè)計(jì)的似乎并不是特別的合理。socket的兩種類型，即用于進(jìn)行數(shù)據(jù)傳輸?shù)膕ocket和服務(wù)器端用于接受連接的socket，兩者之間的差別非常的明顯。它們所能提供的操作，它們的狀態(tài)轉(zhuǎn)換過程都很不一樣，服務(wù)器端用于接受連接的socket支持listen和accept操作，而用于進(jìn)行數(shù)據(jù)收發(fā)的socket則不支持；同樣用于進(jìn)行數(shù)據(jù)收發(fā)的socket支持send和recv，服務(wù)器端用于接受連接的socket則不支持。但當(dāng)前的socket接口統(tǒng)一用一個socket來表示。也就是有多種其實(shí)毫不相干的職責(zé)都被堆在一個socket結(jié)構(gòu)上了。

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

2. 有些地方存在大段大段的重復(fù)code。

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

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

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

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

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

Done。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。