| Both sides previous revision
Previous revision
Next revision
|
Previous revision
Next revision
Both sides next revision
|
mr-udp [2014/10/27 16:25]
mroriz [Architecture and Implementation Details] |
mr-udp [2014/10/27 23:07]
mroriz [Architecture and Implementation Details] |
| Using the receiving segment, the server extract the client address, UUID, and connection parameters. In addition, the server will send a ''SYN'' segment to the client. Then, the server transits to the "map connection" state, where it validates the client UUID. If the server already has a client with that UUID it changes the client endpoint to the IP received in the ''SYN'' segment and then transit to the listening state. However, if the server does not have a client with that UUID, it will create and associate a new UDP socket with this combination (client UUID, endpoint) and it will transit back to the negotiation state. When the client respond with an ''ACK'' segment, the server will start listening the receiving thread for this client and go back to the "Receiver Thread" state. | Using the receiving segment, the server extract the client address, UUID, and connection parameters. In addition, the server will send a ''SYN'' segment to the client. Then, the server transits to the "map connection" state, where it validates the client UUID. If the server already has a client with that UUID it changes the client endpoint to the IP received in the ''SYN'' segment and then transit to the listening state. However, if the server does not have a client with that UUID, it will create and associate a new UDP socket with this combination (client UUID, endpoint) and it will transit back to the negotiation state. When the client respond with an ''ACK'' segment, the server will start listening the receiving thread for this client and go back to the "Receiver Thread" state. |
| | |
| Finally, when the sever receives data, i.e., ''DAT'' segments, it checks to see if the package is in order for that connection. If it is, the server trigger the receive routine of the application. However, if it is not, the server send save the package in a buffer (of size MAX_OUT_OF_SEQUENCE) and send an ''ACK'' segment with the latest known sequence number. | Finally, when the sever receives data, i.e., ''DAT'' segments, it checks to see if the package is in order for that connection. If it is, the server trigger the receive routine of the application. However, if it is not, the server send save the package in a buffer (of size ''MAX_OUT_OF_SEQUENCE'') and send an ''ACK'' segment with the latest known sequence number. |
| |
| {{::receiver.png?1200|}} | {{::receiver.png?1200|}} |
| ---- | ---- |
| |
| | The client state machine is similar to the server automata. The primary difference is that the client start in the "negotiate and save" state. In this state, the client start the connection with the server information (address and port) using a given connection profile. It sends a ''SYN'' segment and waits on this state for a corresponding ''SYN'' reply from the server. |
| {{::sender.png?1200|}} | {{::sender.png?1200|}} |
| ** Sender FSM ** | ** Sender FSM ** |
| |
| ===== References ===== | ===== References ===== |
| MR-UDP: Yet another Reliable User Datagram Protocol, now for Mobile Nodes | MR-UDP: Yet another Reliable User Datagram Protocol, now for Mobile Nodes |