lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] TCP_WRITE_FLAG_MORE


From: David Empson
Subject: Re: [lwip-users] TCP_WRITE_FLAG_MORE
Date: Mon, 09 Nov 2009 11:57:52 +1300

"Chris Strahm" <address@hidden> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]