9

すべて単一のサーバー プロセスに接続する必要があるクライアントがあります。クライアントがサーバーを見つけるために UDP 検出を使用しています。ディスカバリーの完了後に TCP/IP 接続を確立できるように、クライアントとサーバーで IP アドレスとポート番号を交換します。このようにして、パケット サイズは小さく保たれます。これは、UDP を使用して次の 2 つの方法のいずれかで実行できることがわかりました。

  1. 各クライアントは、サーバーを探して独自のマルチキャスト メッセージを送信し、サーバーはそれに応答します。クライアントは、サーバーが応答するまで、このマルチキャスト メッセージの送信を定期的に繰り返すことができます (サーバーがダウンしている場合)。
  2. サーバーは、定期的にマルチキャスト メッセージ ビーコンを送信します。クライアントはマルチキャスト グループにサブスクライブし、この方法でサーバーのマルチキャスト メッセージを受信して​​検出を完了します。

1. 多数のクライアントが存在する場合、最初は多数のマルチキャスト メッセージが送信されます (各クライアントから 1 つ)。サーバーのみがサブスクライブし、クライアントからのマルチキャスト メッセージを受信します。サーバーがクライアントに応答すると、クライアントはマルチキャスト メッセージの送信を停止します。すべてのクライアントがサーバーの検出を完了すると、マルチキャスト メッセージはネットワーク上で送信されなくなります。ただし、サーバーがダウンしている場合、各クライアントは、サーバーがバックアップされて応答できるようになるまで、間隔を置いてマルチキャスト メッセージ ビーコンを送信します。

2. では、サーバーのみが定期的にマルチキャスト メッセージ ビーコンを送信します。このメッセージは、マルチキャスト グループに加入しているすべてのクライアントにルーティングされることになります。クライアントがパケットを受信すると、クライアントの UDP リッスン ソケットが閉じられ、マルチキャスト グループに登録されなくなります。ただし、新しいクライアントがそれを検出できるように、サーバーはマルチキャスト ビーコンを送信し続ける必要があります。クライアントが必要な検出を行っているかどうかに関係なく、定期的にビーコンを送信し続けます。

ですから、どちらにもメリットとデメリットがあると思います。#1 は最初は負荷が高くなるように思えますが、最終的には負荷がゼロになります。#2 では、サーバーは永遠にビーコンを送信し続けます。

UDP とマルチキャストは私にとってかなり新しいトピックなので、どちらが好ましいアプローチで、どちらがネットワーク負荷を軽減するかを知りたいと思っています。

4

4 に答える 4

4

過去にオプション＃2を数回使用しました。これは、単純なネットワーク トポロジに適しています。UDP データグラムがイーサネット MTU を超えて大量の断片化が発生した場合、スループットの問題がいくつか見られました。これまでに確認された最大の問題は、マルチキャスト トラフィックをブロックするように多くのルーターが構成されているため、大規模なトポロジではマルチキャスト検出が機能しなくなることです。

Greg がほのめかした問題は、プロトコル スイートを設計する際に考慮することがかなり重要です。単純なネットワーク トポロジを超えるとすぐに、アドレス変換、IP スプーフィング、および検出レイヤーから通信レイヤーへのハンドオフに関連するその他の多くの問題の解決策を見つける必要があります。それらのほとんどは、サーバーがそれ自体を識別する方法と、識別がクライアントが利用できるものであることを保証する方法に特に関係しています。

もう一度やり直すことができれば (このフレーズを何回発声したことか)、法案に適合する標準ベースの検出メカニズムを探し、他のプロトコル スイートの問題の解決を開始します。本当にやりたくないことは、予想外のネットワーク トポロジが原因で展開してから 1 週間後に壊れてしまう、本当に優れた検出スキームを考え出すことです。service discoveryスターティング リストはGoogleで検索してください。私は個人的にDNS-SDを好む傾向がありますが、他にも多くのオプションが利用可能です。

于 2009-07-30T12:02:17.237 に答える
2

(アプリケーションによっては) サーバーよりもはるかに多くのクライアントを使用する可能性が高いため、方法 2 をお勧めします。サーバーにビーコンを送信させることにより、クライアントごとに 1 つのパケットを送信するのではなく、頻繁に 1 つのパケットのみを送信します。

この方法のもう 1 つの利点は、各サーバーへの接続を維持したり維持したりする必要がないため、クライアントが新しいサーバーが利用可能になったとき、または既存のサーバーがネットワークを離れたときを簡単に判断できることです。各サーバーをポーリングして調べます。

于 2009-07-30T04:06:57.783 に答える
2

どちらも同じように実行可能な方法です。

方法 1 の主張は、通常の原則では、クライアントが要求を開始し、サーバーが要求をリッスンして応答するというものです。

方法 2 の議論は、マルチキャストのポイントは、1 つのホストがパケットを送信し、それを多くのクライアント (1 対多) が受信できるようにすることであり、したがって 1 の逆になることを意味します。

OK、これについて考えると、実際には 2 番目のサーバー起動ビーコンに惹かれます。＃1の問題は、クライアントがビーコンをブロードキャストし、サーバーに接続するとしますが、サーバーはオフラインになるか、IPアドレスを変更します.

サーバーがバックアップされて最初のビーコンが送信されると、すべてのクライアントが同時に再接続するように通知され、システム全体がすぐにバックアップされます。#1 では、すべてのクライアントがサーバーがなくなったことを個別に認識する必要があり、サーバーに接続し直すまで、すべてのクライアントが同時にマルチキャストを開始します。1000 台のクライアントと 1 台のサーバーがある場合、ネットワーク負荷は方法 2 の文字通り 1000 倍になります。

これらのメッセージは小さい可能性が高く、一度に 1000 パケットが UDP ネットワークにとっては何の意味もないことはわかっていますが、設計の観点から見ると #2 の方が優れていると感じます。

編集：私はここで人格障害を発症しているように感じますが、なぜ＃1が有利になるかという強力なポイントを考えただけです...何らかの自然な負荷分散または複数のスケーリングを実装したいと思ったことがある場合サーバーの場合、設計 #1 はこれに適しています。そうすれば、すべてのクライアントがビーコンサーバーにジャンプする#2とは対照的に、最初の「利用可能な」サーバーがクライアントのビーコンに応答して接続できます。

于 2009-07-30T04:21:24.623 に答える
1

オプション＃2には、サーバーが可能なすべてのクライアントと多かれ少なかれ直接通信できると想定しているという大きな制限があります。運用システムの正確なネットワーク アーキテクチャによっては、そうではない場合があります。たとえば、すべてのルーター、VPN ソフトウェア、WAN、NAT、および人々がネットワークを接続するその他のあらゆるものが、実際にマルチキャスト ビーコン パケットを処理できることに依存している場合があります。

#1 では、クライアントが UDP パケットをサーバーに送信できると想定しています。特に、クライアントが次に行うことは同じサーバーへの TCP 接続を確立することであることを考えると、これはまったく妥当な予想です。

サーバーがダウンし、クライアントがいつ復旧したかを知りたい場合は、必ず指数バックオフを使用してください。そうしないと、いつかパケット ストームでネットワークがダウンしてしまいます!

于 2009-07-30T04:34:02.840 に答える