http分块、tcp流控制和playframework相结合

因此，我们可能将大量数据从http服务器通过http服务器流式传输到客户端。因此，http分块+tcp流控制就出现在脑海中。通常情况下，中间人是这样的，中间的人会从下游的异步插座读取，并试图写上游，如果写是异步的，我们需要回调。在调用写回调之前，我们不会再次从下游套接字读取数据，这将导致tcp流控制在nic缓冲区填满后自动生效（至少我以前见过这种情况）

所以我想我有两个问题

playframework是否有任何版本都有写回调，以便我们知道何时正式发送了写，以便我们可以再次继续处理

有人知道java http客户机调用hasData，我必须调用read next chunk，直到我停止调用典型的Hashheaded（Headers h）、hasStatus（HttpStatus）、HashChunk（HttpChunk chunk）为止

嗯#2将是理想的，但任何接近的都会很好

此外，如果我在任何一点上错了，请随时纠正我

谢谢，

---

Dean

我应该添加更多信息，如果我记得的话，我会更新这些信息（当我通过电子邮件收到通知时，你可以通过发表评论来提醒我）

我们进行了调查，结果并不是太多的工作。netty中有一个http类，我们必须复制和修改play以添加我们修改的类，我们必须修改play以拥有writeChunk（块，回调），因此回调将被赋予netty，以便在写入完成时调用

在下游，我们移植了channelmanager（我写的一些东西是pre-netty和pre-mina，没有管道和所有那些复杂的东西，但是看起来就像java的套接字，除了注册监听器以听到数据传入）。这个新的channelmanager只是不断地给您提供具有ByteBuffer的DataChunk，在您调用DataChunk.setProcessed之前，我们实际上停止从允许tcp流控制启动的套接字读取数据

我们计划利用netty的解析器。尽管netty、grizzly和mina都犯了一个错误，将解析器与框架绑得太紧：（：（..当它认为解析器的第一件事是不要将它与框架绑定在一起…哦，好吧。也就是说，所有3个都给了我一些很好的建议，我可以如何利用他们的解析器，这样我就不必重写那部分了…正确地执行tcp流已经是一个巨大的痛苦，我花了整整两天的时间在channelmanager上进行测试中断/修复

一旦这一切就绪并连接到异步http客户机，该客户机下可以有不同的nio库，那么我就可以很容易地接受一块数据，当我最终写入chunk（newChunk，callback）时，我可以传入一个调用DataChunk.setProcessed的回调，以允许下游再次继续。如果您聚合流，或者您只是想在面对一个非常讨厌的客户端时保持健壮，该客户端向您发送了一些东西，但却使其nic满了，这将非常有用

---

事实上，这可能是对Web服务器的一种新的攻击，它在许多Web服务器上都可以工作，但不会影响我们的服务器；）。您可以编写一个客户端来写入，然后不从套接字读取，让nic充满并继续向服务器写入…最终，随着tcp流控制的启动，许多服务器将挂起写入…有一天我应该在tomcat和旧playframework等上尝试。

+1问这个问题。您取得了任何进展吗？事实上是。我刚刚完成了一个在mina和netta之前完成的sourceforge项目的移植，以便在我将其连接到异步http客户端（看起来不太糟糕）的时候，我发现了如何进行黑客攻击，以便writeChunk接受回调。channelmanager2给我们一个DataChunk，并停止读取，直到我们调用DataChunk.setProcessed（因此，如果我们调用它的速度不够快，tcp流控制就会起作用；）。我们将在调用playframeworks writeChunk方法的回调中调用setProcessed，我已经看到了如何修改play以使其工作。因此，现在我将重复使用netty解析器，因为测试它在没有本文中netty nio内容的情况下工作，并且使用channelmanager，netty解析和异步http客户端应该能够拥有流控制。。。。希望异步http客户端接受我的请求。