|
1 <html> |
|
2 <head> |
|
3 <title> DTN2 Manual: UDP Convergence Layer </title> |
|
4 <link rel="stylesheet" type="text/css" href="manual.css" /> |
|
5 </head> |
|
6 <body> |
|
7 <h1>UDP Convergence Layer |
|
8 </h1> |
|
9 |
|
10 <p> |
|
11 The UDP Convergence Layer connects DTN nodes via a UDP channel. |
|
12 A UDP channel is unreliable, but the the DTN protocols overcome |
|
13 this and attempt to achieve reliable delivery of bundles |
|
14 over the unreliable UDP channel. |
|
15 |
|
16 <p> |
|
17 A UDP datagram is limited in size to 65507 bytes. The UDP convergence |
|
18 layer adds a header of variable size (but almost always less than 1000 bytes) |
|
19 to every datagram. |
|
20 Because bundles are sent inside of a single UDP datagram, that |
|
21 means that bundles which exceed about 64000 bytes cannot be |
|
22 transmitted or received with the UDP convergence layer. |
|
23 |
|
24 <p> |
|
25 Because the underlying datalink protocol (often Ethernet) rarely |
|
26 supports the full size of the maximum UDP datagram, is will be broken |
|
27 into fragments and reassembled at the far end. This process, like the |
|
28 UDP protocol itself, has no provisions for retransmissions. As a |
|
29 result, over a sufficiently lossy link UDP datgrams large enough |
|
30 to trigger IP fragmentation may end up with a successful transmission |
|
31 rate of 0. As a result, the practical upper limit for the size of bundles |
|
32 sent via the UDP Convergence Layer is nearer to 2 to 3 times the |
|
33 Maximum Transmission Unit (MTU) of the underlying medium. For |
|
34 Ethernet, the MTU is 1500 bytes. |
|
35 |
|
36 <h2> Interfaces and Links </h2> |
|
37 |
|
38 <p> Each UDP link needs to be configured on both sides. On one side, |
|
39 it is configured as a passive listener (called an <b>interface</b> |
|
40 by dtnd), and on the other side as an active session initiator (called |
|
41 a <b>link</b>). |
|
42 |
|
43 <h3>Passive Listener</h3> |
|
44 |
|
45 <p> The <tt>interface add</tt> command creates the passive |
|
46 listener side of the session. |
|
47 |
|
48 <h3> Active Initiator</h3> |
|
49 |
|
50 <p> The <tt>link add</tt> command creates an object in the system that |
|
51 is capable of sending bundles outbound to other DTN nodes. |
|
52 Depending on the state of the link, as managed by the various options |
|
53 to the <tt>link</tt> command, it may or may not actually be |
|
54 in use to forward bundles at a given time. |
|
55 |
|
56 <h2>Options</h2> |
|
57 |
|
58 <p>These options can appear after the <tt>link add</tt> command, |
|
59 or after the <tt>interface add</tt> command. |
|
60 |
|
61 <p> |
|
62 <table> |
|
63 |
|
64 <tr><th>Name<th>Type<th>Default<th>Comment |
|
65 |
|
66 <tr> |
|
67 <td>local_addr<td>IP address or a DNS hostname<td>0.0.0.0 |
|
68 (interface), -1 (link) |
|
69 <td>In the case of an interface, this is the IP address that the |
|
70 server will listen on. In the case of a link, the default |
|
71 ensures that the operating system choses the appropriate source |
|
72 address for the connection before it is initiated. |
|
73 |
|
74 <tr> |
|
75 <td>local_port<td>IP port number<td>4556 (interface), 0 (link) |
|
76 <td>In the case of an interface, this is the UDP port that the |
|
77 server will listen on. In the case of a link, changing this |
|
78 setting from the default of 0 instructs the operating system to |
|
79 use the given port. In general, it is better to allow the OS to |
|
80 choose the source port itself. |
|
81 |
|
82 <tr> |
|
83 <td>remote_addr<td>IP address or a DNS hostname<td><i>No default.</i> |
|
84 <td>The IP address to which this link will send datagrams. |
|
85 |
|
86 <tr> |
|
87 <td>remote_port<td>IP port number<td><i>No default.</i> |
|
88 <td>The UDP port to which this link will send datagrams. |
|
89 |
|
90 </table> |
|
91 |
|
92 </body> |
|
93 </html> |
|
94 |