If you look into the TCP protocol specification, you see that
there is talk about "PUSH" call in addition to data copying.
It is the BBN socket API prototype that became known as BSD socket
API that does not have this PUSH as separate entity, but does
act as implicite PUSH at the end of the write() (and writev() )
> We obviously have "nonagle" already, but there are actually two kinds of
> "nonagle", and the normal nonagle that everybody already supports is
> actually exactly the wrong kind of nonagle for this kind of thing.
>
> You really want three cases:
....
> - "new" nonagle. This is actually a much more useful form of nonagle, I
> wonder why nobody does it. It always coalesces into a full packet until
> it times out.
>
> You can think of this as "nagle with a packet in flight constantly".
>
> The only thing with the new nagle is that you want some kind of software
> interface for the final push. Obviously closing the socket would do it,
> but you want to do a push even without closing the socket.
setsockopt(fd, SOL_SOCKET, SO_NAGLEMODE, ...)
and getsockopt() too..
And applying fsync(2) for explicite outbound PUSH ?
(or fdatasync(2) for that matter..)
(The fsync(2) has everywhere been defined as disk-only
operation, which has no functionality in e.g. sockets)
> In short, it just sounds extremely silly to try to fight nagle with the
> wrong kinds of interfaces when we can _control_ nagle instead. Nagle is
> just a heuristic - it's not something that is fundamentally important to
> TCP (the _effects_ of nagle, ie trying to make big packets, is obviously
> fairly fundamental to any high bandwidth). It needs to be the _default_
> heuristic, because it works reasonably without any user intervention, but
> there is nothing to say that it has to be the only choice.
>
> Linus
Right,
/Matti Aarnio <matti.aarnio@sonera.fi>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu