blob: f84e0d2eb6a32798a1eea0abd2745ba30bbb54e8 [file] [log] [blame]
Travis Geiselbrecht1d0df692008-09-01 02:26:09 -07001Raw TCP/IP interface for lwIP
2
3Authors: Adam Dunkels, Leon Woestenberg, Christiaan Simons
4
5lwIP provides two Application Program's Interfaces (APIs) for programs
6to use for communication with the TCP/IP code:
7* low-level "core" / "callback" or "raw" API.
8* higher-level "sequential" API.
9
10The sequential API provides a way for ordinary, sequential, programs
11to use the lwIP stack. It is quite similar to the BSD socket API. The
12model of execution is based on the blocking open-read-write-close
13paradigm. Since the TCP/IP stack is event based by nature, the TCP/IP
14code and the application program must reside in different execution
15contexts (threads).
16
17** The remainder of this document discusses the "raw" API. **
18
19The raw TCP/IP interface allows the application program to integrate
20better with the TCP/IP code. Program execution is event based by
21having callback functions being called from within the TCP/IP
22code. The TCP/IP code and the application program both run in the same
23thread. The sequential API has a much higher overhead and is not very
24well suited for small systems since it forces a multithreaded paradigm
25on the application.
26
27The raw TCP/IP interface is not only faster in terms of code execution
28time but is also less memory intensive. The drawback is that program
29development is somewhat harder and application programs written for
30the raw TCP/IP interface are more difficult to understand. Still, this
31is the preferred way of writing applications that should be small in
32code size and memory usage.
33
34Both APIs can be used simultaneously by different application
35programs. In fact, the sequential API is implemented as an application
36program using the raw TCP/IP interface.
37
38--- Callbacks
39
40Program execution is driven by callbacks. Each callback is an ordinary
41C function that is called from within the TCP/IP code. Every callback
42function is passed the current TCP or UDP connection state as an
43argument. Also, in order to be able to keep program specific state,
44the callback functions are called with a program specified argument
45that is independent of the TCP/IP state.
46
47The function for setting the application connection state is:
48
49- void tcp_arg(struct tcp_pcb *pcb, void *arg)
50
51 Specifies the program specific state that should be passed to all
52 other callback functions. The "pcb" argument is the current TCP
53 connection control block, and the "arg" argument is the argument
54 that will be passed to the callbacks.
55
56
57--- TCP connection setup
58
59The functions used for setting up connections is similar to that of
60the sequential API and of the BSD socket API. A new TCP connection
61identifier (i.e., a protocol control block - PCB) is created with the
62tcp_new() function. This PCB can then be either set to listen for new
63incoming connections or be explicitly connected to another host.
64
65- struct tcp_pcb *tcp_new(void)
66
67 Creates a new connection identifier (PCB). If memory is not
68 available for creating the new pcb, NULL is returned.
69
70- err_t tcp_bind(struct tcp_pcb *pcb, struct ip_addr *ipaddr,
71 u16_t port)
72
73 Binds the pcb to a local IP address and port number. The IP address
74 can be specified as IP_ADDR_ANY in order to bind the connection to
75 all local IP addresses.
76
77 If another connection is bound to the same port, the function will
78 return ERR_USE, otherwise ERR_OK is returned.
79
80- struct tcp_pcb *tcp_listen(struct tcp_pcb *pcb)
81
82 Commands a pcb to start listening for incoming connections. When an
83 incoming connection is accepted, the function specified with the
84 tcp_accept() function will be called. The pcb will have to be bound
85 to a local port with the tcp_bind() function.
86
87 The tcp_listen() function returns a new connection identifier, and
88 the one passed as an argument to the function will be
89 deallocated. The reason for this behavior is that less memory is
90 needed for a connection that is listening, so tcp_listen() will
91 reclaim the memory needed for the original connection and allocate a
92 new smaller memory block for the listening connection.
93
94 tcp_listen() may return NULL if no memory was available for the
95 listening connection. If so, the memory associated with the pcb
96 passed as an argument to tcp_listen() will not be deallocated.
97
98- void tcp_accept(struct tcp_pcb *pcb,
99 err_t (* accept)(void *arg, struct tcp_pcb *newpcb,
100 err_t err))
101
102 Specified the callback function that should be called when a new
103 connection arrives on a listening connection.
104
105- err_t tcp_connect(struct tcp_pcb *pcb, struct ip_addr *ipaddr,
106 u16_t port, err_t (* connected)(void *arg,
107 struct tcp_pcb *tpcb,
108 err_t err));
109
110 Sets up the pcb to connect to the remote host and sends the
111 initial SYN segment which opens the connection.
112
113 The tcp_connect() function returns immediately; it does not wait for
114 the connection to be properly setup. Instead, it will call the
115 function specified as the fourth argument (the "connected" argument)
116 when the connection is established. If the connection could not be
117 properly established, either because the other host refused the
118 connection or because the other host didn't answer, the "connected"
119 function will be called with an the "err" argument set accordingly.
120
121 The tcp_connect() function can return ERR_MEM if no memory is
122 available for enqueueing the SYN segment. If the SYN indeed was
123 enqueued successfully, the tcp_connect() function returns ERR_OK.
124
125
126--- Sending TCP data
127
128TCP data is sent by enqueueing the data with a call to
129tcp_write(). When the data is successfully transmitted to the remote
130host, the application will be notified with a call to a specified
131callback function.
132
133- err_t tcp_write(struct tcp_pcb *pcb, void *dataptr, u16_t len,
134 u8_t copy)
135
136 Enqueues the data pointed to by the argument dataptr. The length of
137 the data is passed as the len parameter. The copy argument is either
138 0 or 1 and indicates whether the new memory should be allocated for
139 the data to be copied into. If the argument is 0, no new memory
140 should be allocated and the data should only be referenced by
141 pointer.
142
143 The tcp_write() function will fail and return ERR_MEM if the length
144 of the data exceeds the current send buffer size or if the length of
145 the queue of outgoing segment is larger than the upper limit defined
146 in lwipopts.h. The number of bytes available in the output queue can
147 be retrieved with the tcp_sndbuf() function.
148
149 The proper way to use this function is to call the function with at
150 most tcp_sndbuf() bytes of data. If the function returns ERR_MEM,
151 the application should wait until some of the currently enqueued
152 data has been successfully received by the other host and try again.
153
154- void tcp_sent(struct tcp_pcb *pcb,
155 err_t (* sent)(void *arg, struct tcp_pcb *tpcb,
156 u16_t len))
157
158 Specifies the callback function that should be called when data has
159 successfully been received (i.e., acknowledged) by the remote
160 host. The len argument passed to the callback function gives the
161 amount bytes that was acknowledged by the last acknowledgment.
162
163
164--- Receiving TCP data
165
166TCP data reception is callback based - an application specified
167callback function is called when new data arrives. When the
168application has taken the data, it has to call the tcp_recved()
169function to indicate that TCP can advertise increase the receive
170window.
171
172- void tcp_recv(struct tcp_pcb *pcb,
173 err_t (* recv)(void *arg, struct tcp_pcb *tpcb,
174 struct pbuf *p, err_t err))
175
176 Sets the callback function that will be called when new data
177 arrives. The callback function will be passed a NULL pbuf to
178 indicate that the remote host has closed the connection.
179
180- void tcp_recved(struct tcp_pcb *pcb, u16_t len)
181
182 Must be called when the application has received the data. The len
183 argument indicates the length of the received data.
184
185
186--- Application polling
187
188When a connection is idle (i.e., no data is either transmitted or
189received), lwIP will repeatedly poll the application by calling a
190specified callback function. This can be used either as a watchdog
191timer for killing connections that have stayed idle for too long, or
192as a method of waiting for memory to become available. For instance,
193if a call to tcp_write() has failed because memory wasn't available,
194the application may use the polling functionality to call tcp_write()
195again when the connection has been idle for a while.
196
197- void tcp_poll(struct tcp_pcb *pcb, u8_t interval,
198 err_t (* poll)(void *arg, struct tcp_pcb *tpcb))
199
200 Specifies the polling interval and the callback function that should
201 be called to poll the application. The interval is specified in
202 number of TCP coarse grained timer shots, which typically occurs
203 twice a second. An interval of 10 means that the application would
204 be polled every 5 seconds.
205
206
207--- Closing and aborting connections
208
209- err_t tcp_close(struct tcp_pcb *pcb)
210
211 Closes the connection. The function may return ERR_MEM if no memory
212 was available for closing the connection. If so, the application
213 should wait and try again either by using the acknowledgment
214 callback or the polling functionality. If the close succeeds, the
215 function returns ERR_OK.
216
217 The pcb is deallocated by the TCP code after a call to tcp_close().
218
219- void tcp_abort(struct tcp_pcb *pcb)
220
221 Aborts the connection by sending a RST (reset) segment to the remote
222 host. The pcb is deallocated. This function never fails.
223
224If a connection is aborted because of an error, the application is
225alerted of this event by the err callback. Errors that might abort a
226connection are when there is a shortage of memory. The callback
227function to be called is set using the tcp_err() function.
228
229- void tcp_err(struct tcp_pcb *pcb, void (* err)(void *arg,
230 err_t err))
231
232 The error callback function does not get the pcb passed to it as a
233 parameter since the pcb may already have been deallocated.
234
235
236--- Lower layer TCP interface
237
238TCP provides a simple interface to the lower layers of the
239system. During system initialization, the function tcp_init() has
240to be called before any other TCP function is called. When the system
241is running, the two timer functions tcp_fasttmr() and tcp_slowtmr()
242must be called with regular intervals. The tcp_fasttmr() should be
243called every TCP_FAST_INTERVAL milliseconds (defined in tcp.h) and
244tcp_slowtmr() should be called every TCP_SLOW_INTERVAL milliseconds.
245
246
247--- UDP interface
248
249The UDP interface is similar to that of TCP, but due to the lower
250level of complexity of UDP, the interface is significantly simpler.
251
252- struct udp_pcb *udp_new(void)
253
254 Creates a new UDP pcb which can be used for UDP communication. The
255 pcb is not active until it has either been bound to a local address
256 or connected to a remote address.
257
258- void udp_remove(struct udp_pcb *pcb)
259
260 Removes and deallocates the pcb.
261
262- err_t udp_bind(struct udp_pcb *pcb, struct ip_addr *ipaddr,
263 u16_t port)
264
265 Binds the pcb to a local address. The IP-address argument "ipaddr"
266 can be IP_ADDR_ANY to indicate that it should listen to any local IP
267 address. The function currently always return ERR_OK.
268
269- err_t udp_connect(struct udp_pcb *pcb, struct ip_addr *ipaddr,
270 u16_t port)
271
272 Sets the remote end of the pcb. This function does not generate any
273 network traffic, but only set the remote address of the pcb.
274
275- err_t udp_disconnect(struct udp_pcb *pcb)
276
277 Remove the remote end of the pcb. This function does not generate
278 any network traffic, but only removes the remote address of the pcb.
279
280- err_t udp_send(struct udp_pcb *pcb, struct pbuf *p)
281
282 Sends the pbuf p. The pbuf is not deallocated.
283
284- void udp_recv(struct udp_pcb *pcb,
285 void (* recv)(void *arg, struct udp_pcb *upcb,
286 struct pbuf *p,
287 struct ip_addr *addr,
288 u16_t port),
289 void *recv_arg)
290
291 Specifies a callback function that should be called when a UDP
292 datagram is received.
293
294
295--- System initalization
296
297A truly complete and generic sequence for initializing the lwip stack
298cannot be given because it depends on the build configuration (lwipopts.h)
299and additional initializations for your runtime environment (e.g. timers).
300
301We can give you some idea on how to proceed when using the raw API.
302We assume a configuration using a single Ethernet netif and the
303UDP and TCP transport layers, IPv4 and the DHCP client.
304
305Call these functions in the order of appearance:
306
307- stats_init()
308
309 Clears the structure where runtime statistics are gathered.
310
311- sys_init()
312
313 Not of much use since we set the NO_SYS 1 option in lwipopts.h,
314 to be called for easy configuration changes.
315
316- mem_init()
317
318 Initializes the dynamic memory heap defined by MEM_SIZE.
319
320- memp_init()
321
322 Initializes the memory pools defined by MEMP_NUM_x.
323
324- pbuf_init()
325
326 Initializes the pbuf memory pool defined by PBUF_POOL_SIZE.
327
328- etharp_init()
329
330 Initializes the ARP table and queue.
331 Note: you must call etharp_tmr at a 10 second regular interval
332 after this initialization.
333
334- ip_init()
335
336 Doesn't do much, it should be called to handle future changes.
337
338- udp_init()
339
340 Clears the UDP PCB list.
341
342- tcp_init()
343
344 Clears the TCP PCB list and clears some internal TCP timers.
345 Note: you must call tcp_fasttmr() and tcp_slowtmr() at the
346 predefined regular intervals after this initialization.
347
348- netif_add(struct netif *netif, struct ip_addr *ipaddr,
349 struct ip_addr *netmask, struct ip_addr *gw,
350 void *state, err_t (* init)(struct netif *netif),
351 err_t (* input)(struct pbuf *p, struct netif *netif))
352
353 Adds your network interface to the netif_list. Allocate a struct
354 netif and pass a pointer to this structure as the first argument.
355 Give pointers to cleared ip_addr structures when using DHCP,
356 or fill them with sane numbers otherwise. The state pointer may be NULL.
357
358 The init function pointer must point to a initialization function for
359 your ethernet netif interface. The following code illustrates it's use.
360
361 err_t netif_if_init(struct netif *netif)
362 {
363 u8_t i;
364
365 for(i = 0; i < 6; i++) netif->hwaddr[i] = some_eth_addr[i];
366 init_my_eth_device();
367 return ERR_OK;
368 }
369
370 The input function pointer must point to the lwip ip_input().
371
372- netif_set_default(struct netif *netif)
373
374 Registers the default network interface.
375
376- netif_set_up(struct netif *netif)
377
378 When the netif is fully configured this function must be called.
379
380- dhcp_start(struct netif *netif)
381
382 Creates a new DHCP client for this interface on the first call.
383 Note: you must call dhcp_fine_tmr() and dhcp_coarse_tmr() at
384 the predefined regular intervals after starting the client.
385
386 You can peek in the netif->dhcp struct for the actual DHCP status.