5

Twisted Conch SSH サーバーがあり、典型的なシナリオは次のとおりです。

OpenSSH クライアント経由の git >>--- WAN1 --->> Twisted conch svr >>--- WAN2 -->> Git サーバー

「git push」が WAN2 経由でプロキシできるよりも WAN1 経由でデータを高速に送信する場合があるため、クライアントに速度を落とすように指示する必要があります (TCP パケット損失によって TCP ウィンドウ サイズが調整される前に) 回避する必要があります。 Twisted サーバーでのバッファリングが多すぎます。SSH の RFC を読むと、adj ウィンドウを介して確認しないことで達成されます。これにより、openssh によってバックアップされたパイプへの syscall 書き込みで git push がブロックされます。

メソッド def ssh_CHANNEL_DATA(self, packet) の conch/ssh/connection.py:L216 を見ると、localWindowSize を 0 に設定することでこれを達成できます。また、230 の述語がまだ渡される必要があるため、飛行中のデータは引き続き着陸します (localWindowLeft を与えます)。 . これが正しいアプローチなのか、それとも Twisted SSH Conch を使用したフロー制御に関して盲目的に明らかな何かを見逃しているのでしょうか? *

注: (チャネル) で stopWriting と startWriting のメソッド プレースホルダーが存在することを認めます。これをオーバーライドできるので、送信の反対側の「git pull」を制御するフックがありますが、反対側に興味があります。また、IPush/IPull プロデューサーはこのレベルでは適用できないようです。また、コンチを解体せずにこれらのより高い抽象化を結び付ける方法がわかりませんか?

4

1 に答える 1

3

Twistedを使ったことがなく、Conchもまったく知りませんが、誰も答えてくれないので、試してみます。

一般的な原則として、ネットワークの途中でバッファリングすることはほとんどありません。（「bufferbloat」に関するJim Gettysのメモは啓発的です。）したがって、賢明な質問をしていることは明らかです。

クライアントからデータが到着すると、Conchがコード内の関数を呼び出すと思います。データをバックエンドサーバーに配信できるようになるまで、その呼び出しから戻ってこないだけで十分ですか？カーネルは引き続きインバウンドソケットとアウトバウンドソケットの両方でデータをバッファリングするため、状態がダウンストリームクライアントにすぐに通知されることはありませんが、定常状態に落ち着くと予想されます。

もちろん、別の方法として、SSHとは異なるレイヤーでこのルーターをトンネリングすることもできます。下位層でトンネリングしてエンドツーエンドのTCP接続が1つある場合、TCPスタックは適切なウィンドウサイズを判断する必要があります。

上位層でトンネリングする場合git push、中間サーバーにを実行し、post-receiveフックを使用してオブジェクトを残りの部分にプッシュすると、最大のバッファリング（すべてディスクにスプールされます）とクライアントへの応答時間が短縮されます。総待ち時間は長くなりますが。実装がはるかに簡単であるという明確な利点があります。

于 2012-11-07T17:12:41.167 に答える