Re: [lwip-devel] MSG_MORE flag for send

[Frédéric BERNON]

> > > > 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.

What RFC reference do you use? rfc.net site is pretty good, since you can 
give links like http://rfc.net/rfc1122.html#p82 , and even like 
http://rfc.net/rfc1122.html#s4.2.2.2, but this last don't work : (

> > > 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).

Without adding a new parameter, since the existing "copy" parameter seems to 
be forwarded from sockets.c to tcp_out.c (in tcp_enqueue), why don't use it? 
We can rename it apiflags - or something else - (since flags is usein 
tcp_enqueue like "tcp flags"). I don't have study all case, but msg_more is 
an option "per 'write' call", like the "copy" option.

> > > 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
>
>
> _______________________________________________
> lwip-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-devel