"Chris Strahm" <[email protected]> wrote:
re: lwIP [RAW]
The TCP Push function and how it is used is not clear. Let's say I am
transferring 1MB block of data. There are hundreds of calls to
TCP_WRITE.
Should I be using TCP_WRITE_FLAG_MORE on any of them? What effect will it
have?
The purpose of the PSH mechanism is to tell the TCP/IP stack in the sending
and receiving stations not to wait for any more data and to deliver the data
as soon as possible.
By default, each call to tcp_write() will result in the last segment of data
written having the PSH flag set. This will appear in the corresponding
packet when it is transmitted.
If you set TCP_WRITE_FLAG_MORE, then LWIP will not set the PSH flag on any
segment generated by that call to tcp_write(). You would generally do this
if you are expecting to write more data almost immediately, e.g. if you are
making multiple tcp_write() calls which are gathering data from separate
buffers. By not setting TCP_WRITE_FLAG_MORE on the last call to tcp_write(),
the last segment will have the PSH flag.
If you never set TCP_WRITE_FLAG_MORE, all your tcp_write() calls will result
in a packet with the PSH flag set, though several short writes may be
combined into a single segment, if they are done quickly enough relative to
calls to tcp_output(). You can't assume there will be a one-to-one
relationship between tcp_write() calls and packets with the PSH flag.
If you always set TCP_WRITE_FLAG_MORE, no packets will have the PSH flag
set, and both the transmit and receive sides may delay delivery of data
while waiting for more (e.g. to completely fill a segment).
As far as I can see, LWIP pays no further attention to the PSH flag for
transmit - it is simply passed through to the receiver. This is arguably a
bug, as the absence of PSH in a non-full segment should make LWIP wait for
more data, and its presence should force the opposite behaviour.
Since LWIP transmission is managed by tcp_output(), an application using the
raw API has direct control over when transmission is initiated, so this is
probably not a significant issue. The PSH flag is mainly there for the
benefit of the receiver.
On the receive side, LWIP only pays attention to PSH in the sockets API. It
isn't significant for the raw API due to the manner in which LWIP delivers
receive data to the application. I'm not sure how netconn should deal with
it (if at all).
Summary: given the current LWIP implementation of PSH, the use of
TCP_WRITE_FLAG_MORE is only significant if the receiving station is likely
to pay attention to the PSH flag.
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
