Re: [lwip-devel] MSG_MORE flag for send

[Jonathan Larmour]

Simon Goldschmidt wrote:
> Am 27.10.2007 um 16:45 schrieb Jonathan Larmour:
>
> > Simon Goldschmidt wrote:
> >
> > > Interesting patch (this functionality is required by the TCP RFCs  
> > > by  the way),
> >
> >
> > Are you sure about that? We already only set PSH on the last  segment 
> > of enqueued data from a single 'write', so isn't that all  that is 
> > required? It seems more to me that this is an extension to  give the 
> > user more control over when to send a PSH, rather than it  being at 
> > the end of every 'write'.
>
> Sorry, seems I remembered it wrong, it's a MAY in RFC 1122 (page  107), 
> not a MUST.

I think you meant page 82 (specifically 4.2.2.2) but yeah I see it there 
as MAY.

> > Certainly, adding an extra param is not a requirement; this could  be 
> > done with a separate API message to set a flag in the pcb, e.g.  in 
> > tcp.h:
>
>
> But that would set the push flag for every segment.

To be clear, I meant the new TF_DELAY_PSH I proposed in the PCB flags, not 
the PSH flag in a segment. (Too many "flags" around I think :-)). Without 
TF_DELAY_PSH set, the current behaviour would be preserved.

> I'd rather let  
> netconn_write put the flag into the message (flags are supported in  
> socket API, why not in netconn API?). Then netconn layer can set the  
> flag, call TCP and set it back again.

That would work too.

> > #define TF_DELAY_PSH (u8_t)0x80U
> >
> > And then in tcp_enqueue:
> >    if (seg != NULL && seglen > 0 && seg->tcphdr != NULL &&
> >        0 == (pcb->flags & TF_DELAY_PSH) ) {
> >      TCPH_SET_FLAG(seg->tcphdr, TCP_PSH);
> >    }
> >
> > New equivalent functions can be provided in the higher APIs. The  
> > advantage there being that they are left out if unused (if using a  
> > linker with dead function garbage collection).
> >
> > Rather than there being a specific API message to set this flag  
> > (which would take space that couldn't be removed without an  
> > lwipopts.h define), it may be better to have one to get/set any PCB  
> > flag, which has more generic purpose.
>
>
> That might be a good idea, much like get/setsockopt.

Yep, like them, with room for expansion in the future. Probably best not 
to restrict to PCB flags even.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine