Lines Matching full:application

17 \sa \ref apps "Application programs"
23 \sa \ref uipappfunc "uIP functions called from application programs"
61 for any specific application.
68 addresses, to application level protocols such as SMTP that is used to
71 application". Lower layer protocols are often implemented in hardware
96 communication between the application and the networking stack. An
100 application." A TCP/IP implementation that violates requirements of
108 removed certain mechanisms in the interface between the application
126 or the application for which the incoming packet was intended may have
191 application. Because the data in the buffer will be overwritten by the
192 next incoming packet, the application will either have to act
195 packets before the application has processed the data. Packets that
196 arrive when the application is processing the data must be queued,
201 bytes to a separate buffer during application processing. If the
210 application sends dynamic data, it may use the parts of the global
212 buffer. To send the data, the application passes a pointer to the data
215 produced, the device driver sends the headers and the application data
217 retransmissions. Instead, the application will have to reproduce the
232 \section api Application Program Interface (API)
235 The Application Program Interface (API) defines the way the
236 application program interacts with the TCP/IP stack. The most commonly
257 The "raw" uIP API uses an event driven interface where the application is
258 invoked in response to certain events. An application running on top
260 response to certain events. uIP calls the application when data is
263 has to be retransmitted. The application is also periodically polled
264 for new data. The application program provides only one callback
265 function; it is up to the application to deal with mapping different
267 application is able to act on incoming data and connection requests as
272 from the application when doing retransmissions. Other TCP/IP stacks
276 retransmission without notifying the application. With this approach,
278 acknowledgment even if the application might be able to quickly
282 application may be able to regenerate sent data and lets the
283 application take part in retransmissions. uIP does not keep track of
285 uIP requires that the application takes an active part in performing
287 retransmitted, it calls the application with a flag set indicating
288 that a retransmission is required. The application checks the
290 sent. From the application's standpoint, performing a retransmission
292 application can be written in such a way that the same code is used
295 carried out by the application, it is the responsibility of the stack
297 the application does not necessarily increase because it takes an
300 \subsubsection appevents Application Events
302 The application must be implemented as a C function, UIP_APPCALL(),
312 When the application is called by uIP, the global variable uip_conn is
320 application might decide to act as an HTTP server if the value of
330 overwritten after the application function returns, and the
331 application will therefor have to either act directly on the incoming
338 application according to the available buffer space and the current
341 all data sent from the application does not arrive at the receiver,
342 and the application may use the uip_mss() function to see how much
345 The application sends data by using the uIP function uip_send(). The
347 sent and the length of the data. If the application needs RAM space
351 The application can send only one chunk of data at a time on a
353 per application invocation; only the data from the last call will be
363 application takes an active part in performing the
365 retransmitted, the application function is called with the
369 The application must check the uip_rexmit() flag and produce the same
370 data that was previously sent. From the application's standpoint,
372 originally was sent. Therefor, the application can be written in such
375 the actual retransmission operation is carried out by the application,
377 should be made. Thus the complexity of the application does not
383 The application closes the current connection by calling the
384 uip_close() during an application call. This will cause the connection
386 application might want to abort the connection and does so by calling
390 uip_closed() is true. The application may then do any necessary
398 aborted. uIP reports this by calling the application function. The
399 application can use the two test functions uip_aborted() and
404 When a connection is idle, uIP polls the application every time the
405 periodic timer fires. The application uses the test function
409 application periodically know that a connection is idle, which allows
410 the application to close connections that have been idle for too
411 long. The other purpose is to let the application send new data that
412 has been produced. The application can only send data when invoked by
421 the application function. The test function uip_connected() is true if
422 the application was invoked because a new connection was created.
424 The application can check the lport field in the uip_conn structure to
473 \subsection example1 A Very Simple Application
475 This first example shows a very simple application. The application
477 been established, the application replies to all data sent to it by
480 The implementation of this application is shown below. The application
482 callback function is called example1_app(). For this application, the
499 register a listening port. The actual application function
501 to determine why it was called. If the application was called because
503 application function was called because data was lost in the network
505 example actually shows a complete uIP application. It is not required
506 for an application to deal with all types of events such as
509 \subsection example2 A More Advanced Application
512 and shows how the application state field in the uip_conn structure is
515 This application is similar to the first application in that it
517 to it with a single "ok". The big difference is that this application
522 the application is implemented. The reason for the increase in
524 application must know what data to retransmit. If the "Welcome!"
525 message was lost, the application must retransmit the welcome and if
526 one of the "ok" messages is lost, the application must send a new
529 The application knows that as long as the "Welcome!" message has not
532 back, the application can be sure that the welcome has been received
534 application can be in either of two states: either in the WELCOME-SENT
538 When a remote host connects to the application, the application sends
540 welcome message is acknowledged, the application moves to the
541 WELCOME-ACKED state. If the application receives any new data from the
544 If the application is requested to retransmit the last message, it
545 looks at in which state the application is. If the application is in
548 the application is in the WELCOME-ACKED state, it knows that the last
551 The implementation of this application is seen below. This
552 configuration settings for the application is follows after its
596 The configuration for the application:
608 how the two examples above can be combined into one application.
630 This example shows a simple application that connects to a host, sends
664 the server. Since this is the only data that is sent, the application
669 When the application receives new data from the remote host, it sends
675 If the device's queue is full, the application stops the data from the
676 remote host by calling the uIP function uip_stop(). The application
678 uip_restart() is called. The application polling event is used to
684 This example shows a very simple file server application that listens
686 send. If the files are properly formatted, this simple application can
731 The application state consists of a pointer to the data that should be
733 connects to the application, the local port number is used to
738 The application is driven by incoming acknowledgments. When data has
742 \subsection example6 Structured Application Program Design
749 that calls seven application handler functions that process new data,
797 connection is established, such as intializing the application state
801 The following very simple application serves as an example of how the
802 application handler functions might look. This application simply
805 develop an application state machine, this message is sent in two
868 The application state consists of a "state" variable, a "textptr"
871 that the application is waiting for data to arrive from the network,
872 "STATE_HELLO", in which the application is sending the "Hello" part of
873 the message, or "STATE_WORLD", in which the application is sending the
876 The application does not handle errors or connection closing events,
899 if so changes application state. If the application was in the
901 7 byte "world!\n" message to be sent. If the application was in the
917 affect the application state; this should only be done in the acked()
995 data that is to be delivered to the application, the application is
996 invoked by the means of the application function call. If the incoming
998 updated and the application is informed, allowing it to send out new
1019 to be supported by a complex application layer. Instead, uIP allows
1052 application takes an active part in performing the
1054 retransmitted, it calls the application with a flag set indicating
1055 that a retransmission is required. The application checks the
1057 sent. From the application's standpoint, performing a retransmission
1059 application can be written in such a way that the same code is used
1062 carried out by the application, it is the responsibility of the stack
1064 the application does not necessarily increase because it takes an
1075 In uIP, the application cannot send more data than the receiving host
1076 can buffer. And application cannot send more data than the amount of
1094 TCP's urgent data mechanism provides an application-to-application
1095 notification mechanism, which can be used by an application to mark
1097 stream. It is up to the receiving application to interpret the meaning
1125 data between the TCP/IP stack and the application program. With an
1134 application. Thus an estimate of the CPU overhead of our TCP/IP