Handling long streams of data, or handling header and body efficiently?

[jamamp (James Linnell)]

@lukasa

This should make it fairly clear how to stop NIO from reading from the socket: you stop calling Channel.read . But for most users this might be surprising: after all, they have never called Channel.read . They didn't even know it existed!

This is because NIO has a channel option called autoRead which is turned on by default for all NIO channels. This option will automatically call Channel.read if a read sequence completes and no read() call was already made. This means that in practice Channels are constantly having read called on them, but they call it on themselves .

So, there are two main ways of achieving my second goal, of "Only read data off the socket when it's requested":

1. Turn on .autoRead at the beginning of the connection (for most protocols at least), turn it off when the body is encountered, and turn it back on when the code wishes to process the incoming body.
2. Disregard .autoRead by overriding _ChannelOutboundHandler.read and only allowing the ChannelHandlerContext.read to be performed when needed (beginning of connection, when we want to read the body)
   1. A call to .read() seems to incur a new channelRead according to the documentation, which seems expected.

@lukasa

To do that, it implements ChannelOutboundHandler.read . If it's happy to accept more data, it allows the read call straight through. But if it's waiting for the response .end , it will instead just mark that the read call happened, and do nothing. Later, once it has seen the response .end it was waiting for , it will start letting through read() calls and will trigger a read() if it dropped any earlier on.

In this example, it looks like it uses this mechanism for something slightly different. This is across entire requests, by preventing another entire request from being read before the current one has finished writing its response. My example, on the other hand, is within a single request, preventing the body from being read until the header is processed.

@lukasa

Secondly, even if you exert backpressure you still need buffers. ChannelPipeline s are still pipelines, and just because we stopped reading from the socket doesn't mean you'll immediately have no further data delivered to you. In the most straightforward case, stopping read calls will still potentially allow as many as maxMessagePerRead more chunks of data to come your way! Backpressure works in combination with buffers in NIO-land, not instead of them.

This makes sense. But I think that if the .read() calls are managed carefully, the buffers are more-or-less a constant size, and not as vulnerable to DoS.

Time to write a simple proof of concept. Thanks a lot for your help!!