Lines Matching +full:ram +full:- +full:up
8 using the TCP/IP protocol suite even on small 8-bit
9 micro-controllers. Despite being small and simple, uIP do not require
10 their peers to have complex, full-size stacks, but can communicate
11 with peers running a similarly light-weight stack. The code size is on
12 the order of a few kilobytes and RAM usage can be configured to be as
18 \sa \ref uipopt "Compile-time configuration options"
19 \sa \ref uipconffunc "Run-time configuration functions"
31 used for web page transfers, e-mail transmissions, file transfers, and
32 peer-to-peer networking over the Internet. For embedded systems, being
35 with full TCP/IP support will be first-class network citizens, thus
40 small 8 or 16-bit systems. Code size of a few hundred kilobytes and
41 RAM requirements of several hundreds of kilobytes have made it
43 of kilobytes of RAM and room for less than 100 kilobytes of
52 embedded device always will communicate with a full-scale TCP/IP
53 implementation running on a workstation-class machine. Under this
58 peer-to-peer services and protocols. uIP is designed to be RFC
59 compliant in order to let the embedded devices to act as first-class
69 transfer e-mail. The uIP is mostly concerned with the TCP and IP
104 within the system and will not affect host-to-host communication.
106 In uIP, all RFC requirements that affect host-to-host communication
110 dynamically configurable type-of-service bits for TCP
120 - Check if a packet has arrived from the network.
121 - Check if a periodic timeout has occurred.
132 round-trip time estimations. When the main control loop infers that
142 be hand-tuned for the particular architecture, but generic C
152 calculation must be fine-tuned for the particular architecture on
161 \subsection longarith 32-bit Arithmetic
163 The TCP protocol uses 32-bit sequence numbers, and a TCP
164 implementation will have to do a number of 32-bit additions as part of
165 the normal protocol processing. Since 32-bit arithmetic is not
167 uIP leaves the 32-bit additions to be implemented by the architecture
168 specific module and does not make use of any 32-bit arithmetic in the
171 While uIP implements a generic 32-bit addition, there is support for
178 In the architectures for which uIP is intended, RAM is the most
179 scarce resource. With only a few kilobytes of RAM available for the
197 either by the network device or by the device driver. Most single-chip
198 Ethernet controllers have on-chip buffers that are large enough to
200 handled by the processor, such as RS-232 ports, can copy incoming
224 simultaneous connections. A device that will be sending large e-mails
226 pages and multiple simultaneous clients, will require more RAM than a
228 with as little as 200 bytes of RAM, but such a configuration will
239 API. Because the socket API uses stop-and-wait semantics, it requires
246 uIP provides two APIs to programmers: protosockets, a BSD socket-like
247 API without the overhead of full multi-threading, and a "raw"
248 event-based API that is nore low-level than protosockets but uses less
262 of the connection, when a new connection has been set up, or when data
265 function; it is up to the application to deal with mapping different
269 be achieved even in low-end systems.
306 to either zero or non-zero. Note that certain events can happen in
318 to inspect the uip_conn->lport (the local TCP port number) to decide
321 uip_conn->lport is equal to 80 and act as a TELNET server if the value
326 If the uIP test function uip_newdata() is non-zero, the remote host of
347 sent and the length of the data. If the application needs RAM space
440 two element 16-bit array used by uIP to represent IP addresses.
450 if(uip_connect(uip_conn->ripaddr, HTONS(8080)) == NULL) {
534 application can be in either of two states: either in the WELCOME-SENT
536 the WELCOME-ACKED state where the "Welcome!" has been acknowledged.
539 the "Welcome!" message and sets it's state to WELCOME-SENT. When the
541 WELCOME-ACKED state. If the application receives any new data from the
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
567 s = (struct example2_state *)uip_conn->appstate;
570 s->state = WELCOME_SENT;
575 if(uip_acked() && s->state == WELCOME_SENT) {
576 s->state = WELCOME_ACKED;
584 switch(s->state) {
617 switch(uip_conn->lport) {
702 s = (struct example5_state)uip_conn->appstate;
705 switch(uip_conn->lport) {
707 s->dataptr = data_port_80;
708 s->dataleft = datalen_port_80;
711 s->dataptr = data_port_81;
712 s->dataleft = datalen_port_81;
715 uip_send(s->dataptr, s->dataleft);
720 if(s->dataleft < uip_mss()) {
724 s->dataptr += uip_conn->len;
725 s->dataleft -= uip_conn->len;
726 uip_send(s->dataptr, s->dataleft);
736 actually sent, even though s->dataleft may be larger than the MSS.
824 struct example6_state *s = (struct example6_state *)uip_conn->appstate;
826 s->state = STATE_WAITING;
827 s->textlen = 0;
831 struct example6_state *s = (struct example6_state *)uip_conn->appstate;
833 if(s->state == STATE_WAITING) {
834 s->state = STATE_HELLO;
835 s->textptr = "Hello ";
836 s->textlen = 6;
841 struct example6_state *s = (struct example6_state *)uip_conn->appstate;
843 s->textlen -= uip_conn->len;
844 s->textptr += uip_conn->len;
845 if(s->textlen == 0) {
846 switch(s->state) {
848 s->state = STATE_WORLD;
849 s->textptr = "world!\n";
850 s->textlen = 7;
860 struct example6_state *s = (struct example6_state *)uip_conn->appstate;
862 if(s->textlen > 0) {
863 uip_send(s->textptr, s->textlen);
895 the length of the previously sent data (obtained from "uip_conn->len")
900 "STATE_HELLO" state, it switches state to "STATE_WORLD" and sets up a
932 \subsection ip IP --- Internet Protocol
948 fragment is aligned on an 8-byte boundary, the bit map requires a
966 as the Microsoft Windows file-sharing SMB protocol. Multicast is
968 RTP. TCP is a point-to-point protocol and does not use broadcast or
971 receiving non-local multicast packets is not currently supported.
973 \subsection icmp ICMP --- Internet Control Message Protocol
983 Echo-Reply message type. The ICMP checksum is adjusted using standard
991 \subsection tcp TCP --- Transmission Control Protocol
1004 uIP, a listening connection is identified by the 16-bit port number
1015 The sliding window algorithm uses a lot of 32-bit operations and
1016 because 32-bit arithmetic is fairly expensive on most 8-bit CPUs, uIP
1028 \subsubsection rttest Round-Trip Time Estimation
1030 TCP continuously estimates the current Round-Trip Time (RTT) of every
1032 retransmission time-out.
1088 Since uIP only handles one in-flight TCP segment per connection,
1094 TCP's urgent data mechanism provides an application-to-application
1097 stream. It is up to the receiving application to interpret the meaning
1109 In TCP/IP implementations for high-end systems, processing time is
1111 packet data and context switching. Operating systems for high-end
1118 with the checksum calculation. Because high-end systems usually have
1145 time-frame, an acknowledgment is sent. The time-frame can be as high
1158 500 ms. With a segment size of 1000 bytes, a round-trip time of 40 ms