Alexy wrote:
> > > 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.
But Tony Finch wrote:
> They are exactly the same.
Alexy, Tony just checked in a change to FreeBSD to make TCP_NOPUSH behave the
same as TCP_CORK.
Tony, are people using the TCP_NOPUSH define as a way to detect
the presence of T/TCP support? In that case, perhaps the right
thing to do to achieve source compatibility would be for FreeBSD
to also define TCP_CORK (and give it TCP_NOPUSH as a value, perhaps).
- Dan
Dan Kegel <[email protected]> wrote:
>
>Tony, are people using the TCP_NOPUSH define as a way to detect
>the presence of T/TCP support?
No, MSG_EOF is the right way to do that.
Tony.
--
f.a.n.finch [email protected] [email protected]
FAIR ISLE: WESTERLY VEERING NORTHERLY 4 OR 5. WINTRY SHOWERS. MAINLY GOOD.
In article <[email protected]>,
Tony Finch <[email protected]> wrote:
>Dan Kegel <[email protected]> wrote:
>>
>>Tony, are people using the TCP_NOPUSH define as a way to detect
>>the presence of T/TCP support?
>
>No, MSG_EOF is the right way to do that.
However, I think ank is at least partially correct: TCP_NOPUSH has some
magic behaviour for sockets in listen state, and turns on at least some
T/TCP semantics, if I remember correctly. Tony?
If I remember correctly, may I suggest something: make a new BSD option
called (ehh, just random name ;) TCP_CORK, and make the old BSD
TCP_NOPUSH option be a superset of TCP_CORK that also turns on T/TCP on
listen sockets.
Linux TCP_CORK doesn't have anything to do with T/TCP (not surprisingly,
as T/TCP is considered a broken protocol in Linux and other circles).
And Linux TCP_CORK _is_ used on listen sockets: it makes sockets that
are accepted from the listen socket have the corking semantics. In
contrast, BSD TCP_NOPUSH, I think, has this overloading issue..
Linus