1

Twitterストリーミングエンドポイントがどういうわけか遅い接続の検出をサポートしていることを知りました。

参照：https ：//dev.twitter.com/docs/streaming-apis/parameters#stall_warnings （およびページの下部）

アイデアは、ソケット送信がおそらくデータを1つずつ処理するということです。また、クライアントが1つのパケットを受信したことを認識しているため、キューを維持し、そのサイズを常に把握できます。

クライアントがそれぞれに確認パケットを送信するのは簡単です。ただし、TwitterStreamingAPIの場合はそうではありません。これは一方向の転送です。

私の質問は、彼らはどのようにしてそれを達成したのかということです。非常に低レベルのrawソケットのサポートがなければ、それを行う方法はわかりませんが、ここで何かを忘れている可能性があります。いくつかの低レベルのサポートがあれば、おそらく各パケットのACKを取得できます。それも可能ですか？ACKはどういうわけか追跡できますか？

これがどのように行われたか他のアイデアはありますか？たとえばPythonでこれを行う方法はありますか？または、他の言語の例をいただければ幸いです。

あるいは、私はここで頭を抱えていて、socket.sendを介してまだ処理されていないバイト数を追跡​​するために使用しているだけですか？しかし、それはクライアントの接続の悪い兆候ではありませんか？

4

1 に答える 1

2

私はあなたと同じ方針で考え始めましたが、実装は実際には私たち両方が予想するよりもはるかに簡単だと思います。

TwitterのAPIドキュメントの状態：-

「クライアントのデータの読み取りが遅すぎます。すべてのストリーミング接続は、クライアントに送信されるメッセージのキューによって支えられています。このキューが時間の経過とともに大きくなりすぎると、接続が閉じられます。」-https ://dev.twitter.com/docs/streaming-apis/connecting#Disconnections

上記に基づいて、Twitterには、ツイートをキューにプッシュするスレッドと、メッセージをキューからポップしてhttp応答にデータを書き込むクライアントへの長期間のhttp接続（whileループで開いたまま）があると思います。各ループの反復中。

ここで、whileループ内で何が起こるかを想像し、バッファーの観点から考えると、Twitterはキューからアイテムをポップし、ツイートデータをある種の出力バッファーに書き込みます。そのバッファーはフラッシュされ、TCPバッファーがいっぱいになります。クライアントへの転送用。

クライアントがTCPバッファーからデータをゆっくりと読み取っている場合、サーバーのTCP送信バッファーがいっぱいになります。つまり、サーバーの出力バッファーがフラッシュされると、データをTCPバッファーに書き込めないため、サーバーはブロックされます。つまり、whileループはツイートがキューから頻繁にポップされないため（データがフラッシュされているときにブロックされているため）、ツイートキューがいっぱいになります。

これで、各ループ反復の開始時に、ツイートキューが事前定義されたしきい値に達しているかどうかを確認する必要があります。

于 2013-01-03T17:14:43.297 に答える