Lines Matching full:sent

77 segment is sent in its own IP packet. The IP packets are sent out on
127 produced one or more reply packets which should be sent out. If so,
149 this checksum is made over all bytes in every packet being sent and
282 application may be able to regenerate sent data and lets the
284 packet contents after they have been sent by the device driver, and
290 sent. From the application's standpoint, performing a retransmission
291 is not different from how the data originally was sent. Therefore the
327 the connection has sent new data. The uip_appdata pointer point to the
337 When sending data, uIP adjusts the length of the data sent by the
341 all data sent from the application does not arrive at the receiver,
343 data that actually will be sent by the stack.
347 sent and the length of the data. If the application needs RAM space
348 for producing the actual data that should be sent, the packet buffer
354 sent.
362 been sent by the device driver, uIP requires that the
370 data that was previously sent. From the application's standpoint,
372 originally was sent. Therefor, the application can be written in such
477 been established, the application replies to all data sent to it by
502 the remote end has sent it data, it responds with an "ok". If the
516 listens to a port for incoming connections and responds to data sent
531 the network. But once the remote host has sent an acknowledgment
534 application can be in either of two states: either in the WELCOME-SENT
535 state where the "Welcome!" has been sent but not acknowledged, or in
539 the "Welcome!" message and sets it's state to WELCOME-SENT. When the
546 the WELCOME-SENT state, it sends a "Welcome!"  message since it
663 When the connection has been established, an HTTP request is sent to
664 the server. Since this is the only data that is sent, the application
732 sent and the size of the data that is left to send. When a remote host
734 determine which file to send. The first chunk of data is sent using
736 actually sent, even though s->dataleft may be larger than the MSS. 
739 been acknowledged, new data can be sent. If there is no more data to
798 for the connection. Since it may be the case that data should be sent
805 develop an application state machine, this message is sent in two
883 there is no message to be sent out.
889 " message with the connection. This message will later be sent out by
892 The acked() function is called whenever data that previously was sent
895 the length of the previously sent data (obtained from "uip_conn->len")
901 7 byte "world!\n" message to be sent. If the application was in the
905 data that is to be sent. It is called by the event handler function
910 that is to be sent, and to call the uip_send() function to actually
912 calls uip_send() with the appropriate arguments if data is to be sent,
913 after checking if data should be sent out or not as indicated by the
997 packet acknowledges previously sent data, the connection state is
1012 data. Multiple data segments are sent in succession without waiting
1017 does not implement it. Also, uIP does not buffer sent packets and a
1018 sliding window implementation that does not buffer sent packets will have
1051 been sent by the device driver, uIP requires that the
1057 sent. From the application's standpoint, performing a retransmission
1058 is not different from how the data originally was sent. Therefore the
1142 reducing the number of pure acknowledgment packets sent. A TCP
1145 time-frame, an acknowledgment is sent. The time-frame can be as high
1152 sent. This means that the maximum possible throughput is severely
1167 severe. Small amounts of data sent by such a system will not span more