Analysis and summary of implementation of UDT protocol

The overall structure of the UDT

The UDT socket is the core of the UDT, and it is also a bridge that connects the user application of the UDT with the internal implementation part to the management of the data structure, and the transmission of the network.

The application either puts the data in the send buffer to be sent, or borrows it to receive data from the network. The part that interacts with the network sends the data to be sent from it, or packet dispatch to it when the packet is received.

data receiving part of the UDT framework:

data transmission part of the UDT framework:

some problems with UDTs

1. The rationality of the interface.

analysis of this many of the UDT code, the feeling is that the socket interface design does not seem to be particularly reasonable. The difference between the two types of sockets, the socket used for data transfer and the socket used by the server to accept the connection, is very obvious. They can provide the operation, their state conversion process is very different, the server side for the socket to accept the connection listen and accept operation, and the socket for data transmission is not supported, the same for data transmission socket support send and recv, server-side sockets that are used to accept connections are not supported. But the current socket interface is represented by a single socket. That is, there are a lot of irrelevant responsibilities are piled up on a socket structure.

The problem with the socket interface design is that it is easy to confuse and less user friendly. That is, after an operation can be detected by the return value, but not when the function is called by compiling the error, such as the early reporting. To achieve this, you have to add a lot of additional state checks, greatly increasing the complexity of the implementation.

2. In some places there is a large segment of duplicate code.

For example, the Cudtunited::updatemux () function, between the two bind () functions of cudtunited, cudt::sendmsg () and Cudt::send () wait for the send buffer to have a space portion of code, Cudt in the two connect () functions initialize the Cudt operation and so on.

3. In Cudt, 8 bool variables, such as m_bopened,m_blistening, were used to represent the state of the UDT sockets, which greatly increased the complexity of state management.

4. There are still some legacy issues in code, such as delaywarning/congestionwarning messages, the sending of NAK messages in timers, and so on, which are removed but not completely removed.

5. Message types This constant, which should be defined as an enum or something like this, is a magic number flying in the fly.

Done .

Analysis and summary of implementation of UDT protocol