-1

I have developed a single Server/multiple Clients udp application, where Server can handle x number of clients at a time. The Server has x number of threads each thread dedicated to one Client.

The code works perfectly fine. Now I want to check my application for all possible scenarios i.e. validate my application. For this purpose, I need to design a test best.

Initial Design: The test bed I initially designed has following functionalities:

  • The Server GUI has a button on it. When the button is clicked, the each thread in the Server reads a text file, picks up few bytes of the text file, and sends those chunks to its respective clients. The thread then picks next chunk of bytes from the text file, sends those chunks to the client and so on until EOF is found.

  • The Client on the other side keep receiving these chunks of bytes, creates a text file, and keeps storing these chunks of bytes in its text file.

  • When EOF from Server is received, the Client starts sending the completely received text file back to the Server over its Socket.

  • When the file is completely received back (echoed), the Server then compares the two text files, the Sent file and the echoed one. If both files are same, the communication process has occurred without any fault and the communication protocol is validated.

The above mentioned validation technique (sending the text file, receiving the echoed file and then comparing both) checks the following things:

  1. The number of bytes sent = number of bytes receieved.
  2. No data is corrupted.
  3. The data is receieved in proper order.

If any of the above mentioned three conditions is not fulfilled, that means that there is some error in communication.

Now I have been asked to make changes to this test bead and add more functionlities to it. Does the procedure that I am using actually can check above mentioned 3 conditions in all scenarios?

Are there some other conditions that must be checked besides above mentioned 3 conditions.

What could be other methods of checking communication protocol except the one I desgined i.e. Sending a text file and getting it echoed and then comparing.

I have to implement more functionlities to his test bed for making validation system more efficient or completely replece the above test bed with some better option.

Please help me with your suggestions.

Thanks in advane :)

4

3 に答える 3

1

最初の 2 つの条件は、UDP によって保証されます。「数バイト」、つまり 65535 バイト未満 (64kiB は実際には「数」バイトではない) を選択すると、単一のデータグラムが送信され、それよりも大きいものは失敗します。ただし、IP フラグメンテーションが発生するため、可能な限り最大のデータグラム サイズを使いたくはありません (1280 バイト未満に抑えることをお勧めします)。

送金した金額とまったく同じ金額を受け取るか、まったく受け取ることができます。多かれ少なかれ受け取ることはありません。UDP は、送信されたデータグラムが到着することを保証しません (IP は到着しないため、保証できません) が、データグラム全体がそのまま到着すること、または何も到着しないことを保証します。間に何もありません。
さらに、データグラム内のデータがそのチェックサムと一致することを保証し (IP/イーサネット/ATM を含む基礎となるプロトコルはさらに独自のチェックサムを行います)、送信されたときと同じバイナリ表現で到着します。つまり、データは順番に (データグラム内で) 到着し、破損することはありません。

もちろん、ビット エラーがチェックサムの 3 層すべてを通過することは理論的には可能ですが、これは非常にまれであり、実際には発生しません。誰かが悪意を持ってパケットを改ざんするのを防ぐ必要がない限り、心配する必要はありません。偶発的に発生する種類のビット エラーは、プロトコルで使用されるチェックサムによって確実に検出されます。
一方、データの悪意のある変更から保護する必要がある場合は、MAC (またはチェックサムを追加してパケット全体を暗号化します。チェックサムを追加するだけでは意味がありません) を追加する必要があります。

複数のデータグラムにまたがるデータが順番に到着するようにするには、シーケンス番号をパケットに追加する必要があります (TCP と同じ方法で)。これにより、おそらくより効率的でエラーが発生しにくいTCP を使用することもできます。UDP を使用する主な理由の 1 つは、通常、順序どおりの配信と信頼性が必要ないか、信頼性は必要だが順序どおりの配信が不要な場合があるためです。
順序どおりの配信は、パケット損失時の TCP の遅延の主な原因です (パケット損失がない場合、TCP は UDP とまったく同じくらい「高速」です)。場所。これは、微調整され、文字通り何十億もの人々のために 40 年間確実に機能してきたプロトコルです。

また、クライアントごとに 1 つのソケットと 1 つのスレッドを使用することは、最善の方法ではない可能性があります。ディスクの読み取り速度は遅くなり、ネットワーク カードの送信速度も速くなりません。UDP もクライアントごとにソケットを必要としません。TCP を使用する場合、クライアントごとに 1 つのソケットを使用する以外に選択肢はありませんが、準備通知システムを使用して多重化すると、パフォーマンスが大幅に向上し、スレッド エラーの可能性が少なくなります。

また、SHA ファミリーの 1 つ (または安全である必要がある場合は MAC) などのチェックサムを送り返すことは、大量のデータをエコー バックするよりも効率的です。チェックサムが一致し、データが誤って一致しない可能性は無視できます。
何百万人もの人々のために何百万行ものコードを管理する全体的なリビジョン管理システム (git など) は、これがファイルを識別するために起こらないという事実に依存しています (まあ、もちろん起こります。それを参照してください）。

于 2013-05-31T07:19:49.663 に答える
1

ここで質問がありますか? なぜ UDP ではなく TCP ではないのですか? 特に、パケットの順序やデータの破損が心配な場合。私によると (私が間違っているかもしれません)、UDP は、データがビデオ ストリームのように時間に敏感な場合にのみ有効です。

第二に、はい、送信されたデータの整合性をチェックする他の方法があります。最も簡単なのは、MD5 および SHA1 チェックサムをチェックすることです。

于 2013-05-31T06:32:41.870 に答える
1

私が実際に使用している手順は、すべてのシナリオで上記の 3 つの条件を確認できますか?

はい

私が設計したものを除いて、通信プロトコルをチェックする他の方法は何でしょうか。つまり、テキストファイルを送信し、それをエコーし​​てから比較します。

ファイルである必要はありませんが、応答を受け取ったときに確認できるものである必要があります。ランダムなデータを生成し、応答が得られるまで保持することができます。

本当にテストしたいものを教えてください。UDP が不正なデータや順不同のデータを提供しないことを確認しようとしている場合は、間違ったプロトコルを使用しています。配置されているネットワーク インフラストラクチャを除いて、UDP 経由で送信した正確な順序で正確なデータを取得するかどうかを確認して、何もテストしていません。

「考えられるすべてのシナリオ」でアプリケーションをテストしたいと言っていますが、それは何の意味もありません。UDP 仕様の一部である動作が存在するかどうかをテストして、存在しないことを確認しようとしていますか? そうですね。あなたがそれを見たことがない場合でも。

于 2013-05-31T06:36:06.260 に答える