SocketChannel not flushable

Networking & Multiplayer
#1

The delays caused by Nagle’s algorithm can be quite dramatic (up to 300ms - destroys any request-response performance) and I see no way to finetune that. Disabling it [socket().setTcpNoDelay(false)] will cause lots of tiny packets to be sent over the line. Back in the old days we had OutputStreams that we could flush, allowing to combine the advantages of Nagle’s algorithm and controlling when the socket just had to send its data, regardless of the contents of the socket-buffers and the time elapsed after the last write.

To get the same behaviour in NIO, we have to setTcpNoDelay(true) and start combining our own packets, before we call channel.write(ByteBuffer[]). Not that it is so difficult to do our own combining, but why can’t we use a convenient flush() that makes us have the best of both worlds?

The FileChannel has force() to explicitly tell the OS to physicly the apply operation, so why doesn’t SocketChannel expose a similair feature?

#2

IMHO, it’s not just “not … so difficult”, it should be trivial. If your code cannot let you do that with one line of code extra or changing a variable value, then you’ve got architectural problems you need to resolve anyway.

#3

I already have that code, it’s working, that’s not the point.

I said it was for convenience - having Nagle’s algorithm running in the background is as efficient as it gets when you’re streaming