| Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
mr-udp [2014/10/27 16:25]
mroriz [Architecture and Implementation Details] |
mr-udp [2014/10/27 23:13]
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 with the connections parameters and waits on this state for a corresponding ''SYN'' reply from the server. When the client this message it sends an ''ACK'' message to finish the handshake. After that, the client transit to the "open" state. |
| | |
| | When an MRUDP application sends a message to the server, the message is divided in a sequence of ''DAT'' segments of size ''MAX_SEGMENT_SIZE''. For each segment, the protocol verify if the unack queue is empty, if it is not, the client cannot send additional segments. If the unack queue is empty the protocol queues the segment in the unack queue and sends to the server in a conventional UDP socket. |
| {{::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 |