Lines Matching +full:multi +full:- +full:segment
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
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
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
77 segment is sent in its own IP packet. The IP packets are sent out on
98 option in any segment" and an example of the second kind is "There
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
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
205 receiver window, which means that only a single TCP segment will be in
224 simultaneous connections. A device that will be sending large e-mails
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
269 be achieved even in low-end systems.
286 the retransmission. When uIP decides that a segment should be
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
364 retransmission. When uIP decides that a segment should be
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")
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
1013 for an acknowledgment for each segment.
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
1020 only a single TCP segment per connection to be unacknowledged at any
1028 \subsubsection rttest Round-Trip Time Estimation
1030 TCP continuously estimates the current Round-Trip Time (RTT) of every
1032 retransmission time-out.
1053 retransmission. When uIP decides that a segment should be
1071 segment, the sender of the segment indicates its available buffer
1088 Since uIP only handles one in-flight TCP segment per connection,
1094 TCP's urgent data mechanism provides an application-to-application
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
1144 other received segment. If no segment is received within a specific
1145 time-frame, an acknowledgment is sent. The time-frame can be as high
1149 segment will interact poorly with the delayed acknowledgment
1150 algorithm. Because the receiver only receives a single segment at a
1156 be $p = s / (t + t_d)$ where $s$ is the segment size and $t_d$ is the
1158 500 ms. With a segment size of 1000 bytes, a round-trip time of 40 ms
1168 than a single TCP segment, and would therefore not be affected by the