Tony Finch wrote:
>
> Tony Finch <[email protected]> wrote:
> >Linus Torvalds <[email protected]> wrote:
> >>
> >>Without proper uncorking (and it really shouldn't be that hard to
> >>add), TCP_NOPUSH simply can't be used in the generic sense.
> >
> >It was easy :-) I've put up a patch for FreeBSD that adds proper
> >uncorking on my homepage <http://apache.org/~fanf/> in the "Stuff"
> >section.
>
> ... and it has been committed to -CURRENT, too.
How very cool.
How close is TCP_NOPUSH to behaving identically to TCP_CORK now?
If it does behave identically, it might be time to standardize
the symbolic name for this option, to make apps more portable
between the two OS's. (It'd be nice to also standardize the
numeric value, in the interest of making the ABI's more compatible, too.)
Here are the definitions in the two OS's at the moment:
FreeBSD: netinet/tcp.h (from
http://minnie.cs.adfa.oz.au/FreeBSD-srctree/newsrc/netinet/tcp.h.html#TCP_NOPUSH )
/*
* User-settable options (used with setsockopt).
*/
#define TCP_NODELAY 0x01 /* don't delay send to coalesce packets */
#define TCP_MAXSEG 0x02 /* set maximum segment size */
#define TCP_NOPUSH 0x04 /* don't push last block of write */
Linux: netinet/tcp.h:
/*
* User-settable options (used with setsockopt).
*/
#define TCP_NODELAY 0x01 /* don't delay send to coalesce packets */
#define TCP_MAXSEG 0x02 /* set maximum segment size */
#define TCP_CORK 0x03 /* control sending of partial frames */
- Dan
Alan Cox wrote:
>
> > How close is TCP_NOPUSH to behaving identically to TCP_CORK now?
> > If it does behave identically, it might be time to standardize
> > the symbolic name for this option, to make apps more portable
> > between the two OS's. (It'd be nice to also standardize the
> > numeric value, in the interest of making the ABI's more compatible, too.)
>
> That one isnt practical because of the way the implementations handle
> boolean options. BSD uses bitmask based option setting for the basic
> options and Linus uses switch statements
OK, well, at least a common symbolic name could be chosen.
- Dan
> How close is TCP_NOPUSH to behaving identically to TCP_CORK now?
> If it does behave identically, it might be time to standardize
> the symbolic name for this option, to make apps more portable
> between the two OS's. (It'd be nice to also standardize the
> numeric value, in the interest of making the ABI's more compatible, too.)
That one isnt practical because of the way the implementations handle
boolean options. BSD uses bitmask based option setting for the basic
options and Linus uses switch statements
Alan Cox <[email protected]> wrote:
>> How close is TCP_NOPUSH to behaving identically to TCP_CORK now?
>> If it does behave identically, it might be time to standardize
>> the symbolic name for this option, to make apps more portable
>> between the two OS's. (It'd be nice to also standardize the
>> numeric value, in the interest of making the ABI's more compatible, too.)
>
>That one isnt practical because of the way the implementations handle
>boolean options. BSD uses bitmask based option setting for the basic
>options and Linus uses switch statements
No, that's only true for some of the socket-level options. For the TCP
options there isn't a direct correspondance between the option number
and the number of the flag in the PCB.
Tony.
--
f.a.n.finch [email protected] [email protected]
"Dead! And yet there he stands!"
Hello!
> > How close is TCP_NOPUSH to behaving identically to TCP_CORK now?
They have not so much of common.
TCP_NOPUSH enables T/TCP and its presense used to mean that
T/TCP is possible on this system. Linux headers cannot
even contain TCP_NOPUSH.
Alexey