2

そのため、httpサーバーからhttpサーバーを介してクライアントに大量のデータをストリーミングしている可能性があります。したがって、httpチャンキング+tcpフロー制御が思い浮かびます。通常、このような中間者であるためには、中間者はダウンストリームの非同期ソケットから読み取り、アップストリームに書き込もうとします。書き込みが非同期の場合は、コールバックが必要になります。書き込みコールバックが呼び出されるまで、ダウンストリームソケットから再度読み取ることはありません。これにより、NICバッファーがいっぱいになると、tcpフロー制御が自動的に有効になります（少なくとも、これは以前に正しく発生していました）。

だから私は本当に2つの質問があると思います

  1. どのバージョンのプレイフレームワークにも書き込みコールバックがあるので、書き込みが正式に送信されたことがわかり、処理を再開できます。
  2. hasDataを呼び出すJavahttpクライアントを知っている人はいますか？通常のhasHeaded（Headers h）、hasStatus（HttpStatus）、hasChunk（HttpChunkチャンク）を呼び出す停止するまで、readnextチャンクを呼び出す必要があります

＃2が理想的ですが、近いものなら何でもいいでしょう。

また、私が何か間違っている場合は、遠慮なく訂正してください。

ありがとう、ディーン

4

1 に答える 1

1

さらに情報を追加する必要があります。覚えていれば更新します（メールで通知を受け取ったら、コメントを投稿するだけで通知できます）。

調べてみましたが、それほど手間はかかりません。nettyにはhttpクラスがあり、変更したものを追加するためにplayをコピーして変更する必要があります。また、writeChunk（chunk、callback）を持つようにplayを変更する必要があるため、書き込み時に呼び出すコールバックがnettyに渡されます。完了です。

ダウンストリームでは、channelmanagerを移植しました（私がpre-nettyとpre-minaを作成し、パイプラインとそのすべての複雑さはありませんが、データを聞くためにリスナーを登録することを除いて、代わりにjavaのソケットのように見えます）。この新しいチャネルマネージャーは、ByteBufferを持つDataChunkを提供し続け、Datachunk.setProcessedを呼び出すまで、実際にはそのソケットからの読み取りを停止して、tcpフロー制御を開始できるようにします。

nettyのパーサーを活用する予定です。netty、grizzly、minaはすべて、パーサーをフレームワークに緊密に結び付けるという間違いを犯します：（：（....パーサーがフレームワークに結び付けられていないと思われる場合の最初のこと....まあ。とは言うものの、3つすべてが、パーサーを活用する方法についていくつかの良いアドバイスを提供したので、その部分を書き直す必要はありません。 channelmanagerの修正。

それがすべて機能し、その下に異なるnioライブラリを持つことができるasync-http-clientに接続されると、データのチャンクを簡単に受け入れることができ、最終的にwriteChunk（newChunk、callback）を実行すると、コールバックを渡すことができます。 DataChunk.setProcessedを呼び出して、ダウンストリームが再び続行できるようにします。これは、ストリームを集約する場合、または何かを送信するがニックをいっぱいにする本当に厄介なクライアントに直面して堅牢になりたい場合に非常に便利です。

実際、これはWebサーバーに対する新しい種類の攻撃である可能性があり、多くのWebサーバーでは、サーバーにまったく影響を与えないことを除いて機能します;）。クライアントを書き込み、ソケットから読み取らずに、NICをいっぱいにしてサーバーへの書き込みを続けることができます...最終的には、tcpフロー制御が開始されると、多くのサーバーが書き込みでハングします。いつかtomcatや古いplayframeworkなどで試してみてください。

于 2012-12-20T03:46:08.740 に答える