Lines Matching full:it
7 The uIP TCP/IP stack is intended to make it possible to communicate
33 able to run native TCP/IP makes it possible to connect the system
41 RAM requirements of several hundreds of kilobytes have made it
47 set of features needed for a full TCP/IP stack. It can only handle a
54 assumption, it is possible to remove certain TCP/IP mechanisms that
75 TCP provides a reliable byte stream to the upper layer protocols. It
125 will never block, but will return at once. When it returns, the stack
133 the periodic timer should fire, it should invoke the timer handler
150 received it is important that the function that calculates the
155 While uIP includes a generic checksum function, it also leaves it open
185 allocation. Instead, it uses a single global buffer for holding
189 it in the global buffer and calls the TCP/IP stack. If the packet
210 application sends dynamic data, it may use the parts of the global
227 simple Telnet server. It is possible to run the uIP implementation
239 API. Because the socket API uses stop-and-wait semantics, it requires
265 function; it is up to the application to deal with mapping different
271 uIP is different from other TCP/IP stacks in that it requires help
287 retransmitted, it calls the application with a flag set indicating
293 both for sending data and retransmitting data. Also, it is important
295 carried out by the application, it is the responsibility of the stack
297 the application does not necessarily increase because it takes an
340 dictated by the memory configuration. It is therefore possible that
352 connection and it is not possible to call uip_send() more than once
374 retransmitting data. Also, it is important to note that even though
376 it is the responsibility of the stack to know when the retransmission
378 necessarily increase because it takes an active part in doing
406 uip_poll() to check if it is being polled by uIP.
477 been established, the application replies to all data sent to it by
501 to determine why it was called. If the application was called because
502 the remote end has sent it data, it responds with an "ok". If the
504 and has to be retransmitted, it also sends an "ok". Note that this
505 example actually shows a complete uIP application. It is not required
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
530 been acknowledged by the remote host, it might have been dropped in
539 the "Welcome!" message and sets it's state to WELCOME-SENT. When the
542 remote host, it responds by sending an "ok" back.
544 If the application is requested to retransmit the last message, it
546 the WELCOME-SENT state, it sends a "Welcome!" message since it
548 the application is in the WELCOME-ACKED state, it knows that the last
631 an HTTP request for a file and downloads it to a slow device such a
665 knows that if it needs to retransmit any data, it is that request that
666 should be retransmitted. It is therefore possible to combine these two
669 When the application receives new data from the remote host, it sends
670 this data to the device by using the function device_enqueue(). It is
677 can then be sure that it will not receive any new data until
744 When writing larger programs using uIP it is useful to be able to
791 connection has been closed, the closed() function is called to the it
798 for the connection. Since it may be the case that data should be sent
897 accordingly. It then checks if the "textlen" variable now is zero,
900 "STATE_HELLO" state, it switches state to "STATE_WORLD" and sets up a
902 "STATE_WORLD" state, it closes the connection.
905 data that is to be sent. It is called by the event handler function
916 It is important to note that the senddata() function never should
925 the layered approach is a good way to design protocols, it is not
998 updated and the application is informed, allowing it to send out new
1017 does not implement it. Also, uIP does not buffer sent packets and a
1023 It is important to note that even though most TCP implementations use
1024 the sliding window algorithm, it is not required by the TCP
1035 timer. Each time the periodic timer fires, it increments a counter for
1054 retransmitted, it calls the application with a flag set indicating
1060 both for sending data and retransmitting data. Also, it is important
1062 carried out by the application, it is the responsibility of the stack
1064 the application does not necessarily increase because it takes an
1077 bytes it is allowed to send by the receiving host. If the remote host
1097 stream. It is up to the receiving application to interpret the meaning
1102 because it requires an asynchronous notification mechanism in an
1151 time, it will wait as much as 500 ms before an acknowledgment is
1164 It should be noted, however, that since small systems running uIP are