David, this is another great write-up that I think would benefit all by being in the Wiki! This is a good explanation here of something that I eventually needed to learn about when sending large data blocks.
Bill >-----Original Message----- >From: [email protected] >[mailto:[email protected]] On >Behalf Of David Empson >Sent: Sunday, November 08, 2009 5:58 PM >To: Chris Strahm; Mailing list for lwIP users >Subject: Re: [lwip-users] TCP_WRITE_FLAG_MORE > >"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 _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
