Differences
This shows you the differences between two versions of the page.
mr-udp [2014/10/27 23:07] mroriz [Architecture and Implementation Details] |
mr-udp [2017/07/21 03:08] |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | {{template>: | ||
- | | name=MR-UDP | ||
- | | version= 2.0 | ||
- | | accountable=Marcos Roriz | ||
- | | depdency= | ||
- | }} | ||
- | ====== MR-UDP ====== | ||
- | MR-UDP is an extended and optimized version of Reliable UDP (R-UDP) that is used to communicate with mobile nodes. It extends R-UDP protocol with mobility-tolerating features, such as the ability to handle intermittent connectivity, | ||
- | |||
- | ===== Usage ===== | ||
- | <WRAP center round important 80%> | ||
- | In general, there are few cases for using MR-UDP directly. In almost all instances, you should use [[ClientLib]] a higher-level wrapper library that makes MR-UDP easier to use and interacts better with the rest of ContextNet components.</ | ||
- | |||
- | MR-UDP is implemented in Java, and enhances a publically available Reliable UDP implementation named Simple R-UDP. The programming interface provides ReliableClientSocket and ReliableServerSocket classes, which extend the conventional Java Socket’s programming interface, with the well-known Socket, ServerSocket, | ||
- | |||
- | Since MR-UDP implements the well-known Java Socket API its usage is similar to Java RAW Socket. To create a client, please create a new '' | ||
- | <file java HelloClient.java> | ||
- | public class HelloClient { | ||
- | |||
- | public static void main(String[] args) throws Exception { | ||
- | String host = " | ||
- | int port = 5500; | ||
- | |||
- | ReliableSocket clientSocket = new ReliableSocket(host, | ||
- | ReliableSocketOutputStream outputStream = (ReliableSocketOutputStream) clientSocket.getOutputStream(); | ||
- | PrintWriter outputBuffer = new PrintWriter(outputStream); | ||
- | |||
- | outputBuffer.println(" | ||
- | outputBuffer.flush(); | ||
- | Thread.sleep(10*1000); | ||
- | clientSocket.close(); | ||
- | } | ||
- | } | ||
- | </ | ||
- | |||
- | Developers can also configure the protocol parameters. To do so, developers needs to extend the '' | ||
- | | ||
- | * MAX_SEGMENT_SIZE (Default: 256 bytes); | ||
- | The maximum number of octets that can be received by the peer sending the SYN segment. | ||
- | |||
- | * MAX_OUTSTANDING_SEGS (Default: 3 segments); | ||
- | The maximum number of segments that should be sent without getting an acknowledgment. | ||
- | | ||
- | * MAX_RETRANS (Default: 10 retransmissions); | ||
- | The maximum number of times consecutive retransmission(s) will be attempted before the connection is considered broken. | ||
- | |||
- | |||
- | ===== Architecture and Implementation Details ===== | ||
- | In general, MR-UDP architecture follows closely the R-UDP architecture. However, the implementation has diverged drastically from R-UDP. In 2.0, we did major modifications in internals parts, specifically on networking, threading and scheduler, while not breaking the protocol interfaces. All UDP '' | ||
- | |||
- | In addition, we switched from blocking network primitives (Java IO) to non-blocking (Java NIO). Originally, when a connection was created MR-UDP (and R-UDP) it started a background receive and send thread. This premise became troublesome to scale for the server part (our Gateway) when we need to handle a large number of connections. By using Java NIO we can simplify our code to use only one thread to handle the networking. The Java NIO Select primitive enables us to monitor the connections using a single thread, as illustrated below. | ||
- | |||
- | {{:: | ||
- | **Java NIO ** | ||
- | |||
- | When a connection received something it will trigger the select handler, which will process the receiving data. When sending a message, the connection will queue the message in the scheduler thread pool. This enable us to control the sending in an entire part. Not only these change simplified the codebase, the code is isolated and simpler, but also enabled the server to scale to a higher number of connections. | ||
- | |||
- | The MR-UDP protocol can be summarized in a state machine for receiving and sending (displayed bellow) messages. The ReliableSocketServer starts on the receiver thread state. It receives a port and a connection profile, as a result it starts a clean connection hash table and start a listening UDP socket on the specified port. When it receives a '' | ||
- | |||
- | Using the receiving segment, the server extract the client address, UUID, and connection parameters. In addition, the server will send a '' | ||
- | |||
- | Finally, when the sever receives data, i.e., '' | ||
- | |||
- | {{:: | ||
- | ** Receiver FSM ** | ||
- | |||
- | ---- | ||
- | |||
- | The client state machine is similar to the server automata. | ||
- | {{:: | ||
- | ** Sender FSM ** | ||
- | ===== References ===== | ||
- | MR-UDP: Yet another Reliable User Datagram Protocol, now for Mobile Nodes | ||
- | L.D. Silva, M. Endler, M. Roriz, MR-UDP: Yet another Reliable User Datagram Protocol, now for Mobile Nodes, | ||
- | |||
- | Link: http:// |