データ ストリームとして "command arg0 arg1 argn\n" という単純なネットワーク プロトコルが与えられた場合、そのようなサーバーに改行を送信せずに連続してデータを送信すると、単純なサーバーがメモリ不足エラーでエラーが発生しましたか?
ネットワークプロトコルがすでに定義されているuniでJava割り当てを与えられたので興味がありますが、引数の最大量、またはコマンド/引数の最大長については言及されていません。
このプロトコルを順守し、攻撃に対して回復力のあるクライアントとサーバーを作成する予定ですが、最大メッセージサイズの欠如は本当に私を悩ませています.
いいえ、そうではありません。プロトコルが新しい行がデータを処理するのを待っている場合でも、多くのレベルでいくつかのバッファがあります。たとえば、サーバーが十分な速度でデータを読み取っていない場合、TCP 受信バッファーがいっぱいになり、OS が確認応答パケットの返送を停止し始め、write.
それはネットワーク層用です。ただし、サーバーの実装が合計文字列をメモリに保持している場合、それが発生する可能性OutOfMemoryErrorがありますが、適切な実装はそれから保護される可能性があります。
メモリ不足エラーが発生しますか?
潜在的に、はい。
StringBuffer単純なサーバーは、コマンドと引数に分割する前に、行全体を a に読み込もうとする可能性があります。(たとえば、これは何をするかBufferedReader.readLine()、またはScanner.nextLine()する予定です。)StringBufferヒープをいっぱいにするのに十分な大きさになる可能性があります。( a の最大サイズStringBufferは2^31chars ... であり、スペースの使用量は一時的にその 2 倍になる可能性があります。)
サーバーがもう少し慎重であっても、コマンドの処理を開始する前に (通常のコマンドの) すべての引数を取得する必要がある場合、問題が発生する可能性があります。そして、（どういうわけか）それに対処した場合は、コマンド名または単一の引数が~2^31文字長である可能性を考慮してください。
これらの潜在的な DOS 攻撃を打ち負かす唯一の現実的な方法は、要求メッセージの長さに防御的な制限を設けることです。
私は大学でJavaの課題を与えられたので興味があります...
...ええと、ソリューションがサービス拒否攻撃に対して回復力があるという書面による要件がない限り、おそらく考えすぎです。これは演習であることを忘れないでください...実際の生産強度システムを構築するための要件ではありません.
実際のシステムを作成している場合は、この問題について「クライアント」と話し合い、対処方法を考えます。たとえば、プロトコル仕様を変更して、メッセージの長さ制限を含めます。