1秒あたり10,000メッセージの割合でメッセージを生成できるサーバーがあるとします。しかし、私のクライアントは1秒あたり最大1000件のメッセージしか受信できません。ソケット、メッセージレートリミッタJava
システム1 私のシステムが1ミリ秒で1000のメッセージを送信し、残りの999ミリ秒で何もしない場合。
システム2 私のシステムはmilisecondごとに1つのメッセージを送信し、それゆえ1000ミリ秒（1second）で、それは1000件のメッセージを送信します。
Q1）クライアントが1秒あたり最大500件のメッセージを処理できるシステムはどれですか？
Q2）システム1がクライアントに与える影響は？それはクライアントを圧倒するだろうか？
おかげ
ウィルそれは、クライアントを圧倒：それはあなたのメッセージのサイズ、およびソケットバッファサイズに依存。送信者が送信するメッセージはバッファされます。バッファーがいっぱいになってクライアントが消費できない場合は、送信側が使用している出力ストリームがブロックされます。クライアントがいくつかのメッセージを消費したとき、送信者は自分のOutputStreamがブロック解除されるのと同時に書き込むことができます。
Windowsシステムの典型的なバッファサイズは、8192バイトでしたが、OSのOSと設定によって異なります。
システム1はクライアントを圧倒することはないため、特定の時点でブロックされます。
最適なアプローチは、アプリケーションの設計によって異なります。
例：USB経由でArduinoに書き込む際に同様の問題が発生しました（ソケットクライアントではありませんが、それ以外の場合は同じ問題が発生します）。私の問題では、バッファリングされたメッセージはどこに問題がありますか？それは、顔追跡カメラの位置だったからです。バッファリングされた位置は、Arduinoがそれらを読み込んだときはもはや関係ありませんでしたが、そのようなバッファは待ち行列であるため処理しなければならず、古いものを読み出すだけで最新のものを得ることができます。 Arduinoは、Arduinoのコードに到達するまでには古くなっていたため、生成されるメッセージについて行くことはできませんでした。それは「圧倒」でした。
私はこれを双方向通信で解決しました。 ArduinoはプロデューサーにREADY（メッセージを受け取る）というメッセージを送ります。その後、プロデューサーは1つ（最新）の顔追跡位置を送信します。その後、Arduinoはカメラの位置を変更し、新しいメッセージを要求しました。このようにして、Arduinoのオーバーフローを防止する一種のフロー制御がありました。