|
1 <html> |
|
2 <head> |
|
3 <title> DTN2 Manual: TCP Convergence Layer </title> |
|
4 <link rel="stylesheet" type="text/css" href="manual.css" /> |
|
5 </head> |
|
6 <body> |
|
7 <h1>TCP Convergence Layer |
|
8 </h1> |
|
9 |
|
10 <p> |
|
11 The TCP Convergence Layer connects DTN nodes via a TCP channel. |
|
12 As with all TCP connections, it is reliable (meaning the underlying |
|
13 layers attempt to deliver all the data sent, in the order it was |
|
14 sent). In the context of a DTN, however, a TCP connection is only |
|
15 reliable while it is up. The DTN components (each endpoint of the |
|
16 TCP connection) are ready and willing to invoke various types of |
|
17 recovery mechanisms if the transfer of a bundle is interrupted |
|
18 by a broken TCP connection. |
|
19 |
|
20 <p> |
|
21 The TCP session between two DTN nodes only moves bundles in one |
|
22 direction. The TCP session itself is two directional, so that |
|
23 the TCP convergence layer on the bundle receiver can send feedback |
|
24 to the sender. In a case where bundles need to move both directions |
|
25 between two nodes, there will be two TCP connections, each one |
|
26 initiated by one of the sides. The side that initiates the connection |
|
27 sends bundles over it. |
|
28 |
|
29 <h2> Interfaces and Links </h2> |
|
30 |
|
31 <p> Each TCP link needs to be configured on both sides. On one side, |
|
32 it is configured as a passive listener (called an <b>interface</b> |
|
33 by dtnd), and on the other side as an active session initiator (called |
|
34 a <b>link</b>). But take note of the <tt>receiver_connect</tt> option, |
|
35 which reverses things. |
|
36 |
|
37 <h3>Passive Listener</h3> |
|
38 |
|
39 <p> The <tt>interface add</tt> command creates the passive |
|
40 listener side of the session. It always takes at least one argument, |
|
41 which is the local address. This is specified with either the IP or |
|
42 Host address families. For more information about address families, |
|
43 see the <a href="configuration.html#interface">interface add</a> |
|
44 documentation. After the local address, you may include optional arguments |
|
45 which are detailed below. |
|
46 |
|
47 <h3> Active Initiator</h3> |
|
48 |
|
49 <p> The <tt>link add</tt> command creates an object in the system that |
|
50 is capable of initiating a connection outbound to other DTN nodes. |
|
51 Depending on the state of the link, as managed by the various options |
|
52 to the <tt>link</tt> command, it may or may not actually be actively |
|
53 opening or maintaining a TCP connection at a given time. |
|
54 |
|
55 <h2>Options</h2> |
|
56 |
|
57 <p>These options can appear after the <tt>link add</tt> command, |
|
58 or after the <tt>interface add</tt> command. |
|
59 |
|
60 <p> |
|
61 <table> |
|
62 |
|
63 <tr><th>Name<th>Type<th>Default<th>Comment |
|
64 |
|
65 <tr> |
|
66 <td>bundle_ack_enabled<td>boolean<td>true |
|
67 <td>Should we send an ACK when we have received the entire bundle? |
|
68 |
|
69 <tr> |
|
70 <td>idle_close_time<td>integer seconds<td>30 |
|
71 <td>Number of seconds after which to close the connection if no data |
|
72 other than keepalives arrives. |
|
73 |
|
74 <tr> |
|
75 <td>keepalive_interval<td>integer seconds<td>2 |
|
76 <td>The number of seconds between keepalives requested for |
|
77 both directions on this link. The actual value of this parameter |
|
78 for a connection will be decided during |
|
79 <a href="#negotiation">parameter negotiation</a>. |
|
80 |
|
81 <tr> |
|
82 <td>local_addr<td>IP address or a DNS hostname<td>0.0.0.0 |
|
83 (interface), -1 (link) |
|
84 <td>In the case of an interface, this is the IP address that the |
|
85 server will listen on. In the case of a link, the default |
|
86 ensures that the operating system choses the appropriate source |
|
87 address for the connection before it is initiated. |
|
88 |
|
89 <tr> |
|
90 <td>local_port<td>IP port number<td>4556 (interface), 0 (link) |
|
91 <td>In the case of an interface, this is the TCP port that the |
|
92 server will listen on. In the case of a link, changing this |
|
93 setting from the default of 0 instructs the operating system to |
|
94 use the given port. In general, it is better to allow the OS to |
|
95 choose the source port itself. |
|
96 |
|
97 <tr> |
|
98 <td>partial_ack_len<td>integer bytes<td>1024 |
|
99 <td>If dtnd has read at least this much data without sending an |
|
100 acknowledgement, send one. |
|
101 |
|
102 <tr> |
|
103 <td>reactive_frag_enabled<td>boolean<td>true |
|
104 <td>If the servers loses the connection while sending, should it |
|
105 fragment the bundle so that when the connection is working again |
|
106 the it can start sending from the last ack, instead of from the |
|
107 beginning? |
|
108 |
|
109 <tr> |
|
110 <td>readbuf_len<td>integer bytes<td>32768 |
|
111 <td>The maximum number of bytes to read from the network |
|
112 before flushing them to the local copy of the bundle. |
|
113 Recall that the local copy of the bundle might be in |
|
114 memory, and not on disk. See <a href="configuration.html#param"> |
|
115 <tt>param set payload_mem_threshold</tt></a> command. |
|
116 |
|
117 <tr> |
|
118 <td>receiver_connect<td>boolean<td>false |
|
119 <td>This option reverses the direction of dataflow, making the |
|
120 initiator receive bundles. (Not yet implemented.) |
|
121 |
|
122 <tr> |
|
123 <td>data_timeout<td>integer miliseconds<td>5000 (5 seconds) |
|
124 <td>Number of milliseconds to wait for an expected |
|
125 response from the other side. |
|
126 |
|
127 <tr> |
|
128 <td>test_fragment_size<td>integer bytes<td>-1 (disabled) |
|
129 <td>Artifically close the connection, simulating a link failure, |
|
130 after this many bytes. This feature is probably only useful while |
|
131 testing the fragmentation system. (No longer implemented.) |
|
132 |
|
133 <tr> |
|
134 <td>writebuf_len<td>integer bytes<td>32768 |
|
135 <td>The maximum number of bytes to read from the on-disk bundle |
|
136 at a time for buffering before it is sent across the connection. |
|
137 |
|
138 </table> |
|
139 |
|
140 <a name="negotiation"/> |
|
141 <h3> Parameter Negotiation </h3> |
|
142 |
|
143 <p> |
|
144 Some parameters take effect solely inside one daemon or the other. |
|
145 Other paramaters are sent across the link at the beginning during |
|
146 a negotiation phase. The following table summarizes which parameters are |
|
147 subject to negotiation, and how the negotiation works. |
|
148 |
|
149 <p> |
|
150 <table> |
|
151 <tr><th>Name<th>Negotiation |
|
152 <tr><td>partial_ack_len<td>Minimum of near side and far side. |
|
153 <tr><td>keepalive_interval<td>Minimum of near side and far side. |
|
154 <tr><td>idle_close_time<td>Minimum of near side and far side. |
|
155 <tr><td>bundle_ack_enabled<td>Logical AND of near and far side. |
|
156 <tr><td>reactive_frag_enabled<td>Logical AND of near and far side. |
|
157 <tr><td>receiver_connect_<td>Logical OR of near and far side. |
|
158 </table> |
|
159 |
|
160 </body> |
|
161 </html> |
|
162 |