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满天飞。

Done。