Question

So, we may be streaming tons of data from an http server through an http server to a client. So http chunking + tcp flow control comes to mind. Normally to be a man in the middle like this, our man in the middle would read from a downstream asynch socket and try to write upstream and if the write was async, we would need a callback. We would NOT read from the downstream socket again until the write callback is called which would cause tcp flow control to automatically take affect once the nic buffer fills up(at least I have seen this occur before correctly).

So I think I have two questions really

1. Does any version playframework have a write callback so we know when the write has officially been sent through such that we can continue processing again.
2. Does anyone know of a java http client that calls a hasData and I have to invoke a read next chunk until I stop which calls the typical hasHeaded(Headers h), hasStatus(HttpStatus), hasChunk(HttpChunk chunk)

Well #2 would be ideal but anything close would be nice.

Also, if I am wrong on any points, feel free to correct me.

thanks,
Dean

Answer 1

I should add more info and I will update this if I remember(and you can remind me just by posting a comment as I receive notifications via email).

We looked into it and it is not too much work. There is an http class in netty we have to copy and modify play to add the one we modify and we have to modify play to have a writeChunk(chunk, callback) as well so the callback willl be given to netty to call when the write is complete.

Downstream, we ported channelmanager(someething I wrote pre-netty and pre-mina and doesn’t have pipelines and all that complexity but looks just like java’s Sockets instead except you register listeners to hear the data coming in). This new channelmanager just keeps giving you DataChunk that has a ByteBuffer and until you call Datachunk.setProcessed, we actually stop reading from that socket allowing tcp flow control to kick in.

We plan on leveraging netty’s parser. Though netty, grizzly and mina ALL make the mistake of tying their parser too tightly to their framework 🙁 :(….the first thing when It think parser is don’t tie it to the framework….oh well. That said, all 3 gave some good advise on how I might leverage their parsers so I don’t have to rewrite that portion….doing tcp flow correctly was already a big huge pain and took me 2 solid days of test breaking/fixing on channelmanager.

Once that is all in play and wired into async-http-client which can have different nio libraries under it, then I can easily accept a chunk of data and when I finally writeChunk(newChunk, callback), I can pass in a callback that calls the DataChunk.setProcessed to allow downstream to continnue again. This is very useful if you aggregate streams OR if you just want to be robust in the face of one really really nasty client who sends you something but makes his nic fill up.

In fact, this might be a new kind of attack on webservers where on many webservers it works except it would not affect our server at all ;). You can write a client to write and then not read from the socket letting the nic fill up and keep writing to the server…eventually many servers will hang on the write out as tcp flow control kicks in…..I should try that on tomcat and the old playframework and such someday.