ローカルネットワークでのピアツーピア共有ステータスのために、自分の個人的な使用（および場合によっては友人との共有）用のおもちゃのアプリケーションを作成したいと考えています。たとえば、現在の建物の名前で実装したいとします（ネットワークトポロジがおかしく、複数の建物が同じLANを占有しているとしましょう）。アイデアは、アプリケーションを実行する場合、現在の建物を設定でき、ローカルネットワーク上でアプリケーションを実行している他のすべてのユーザーの建物を確認できるということです。
問題は、これを実装するために使用するのに最適なトランスポート/ネットワーク層テクノロジーは何ですか？
私の最初の傾向はUDPマルチキャストを使用することでしたが、UDPマルチキャストについて調査を重ねるほど、怖がります。テクノロジーは素晴らしく、使いやすいように見えますが、アプリケーションが特定のサイト展開に合わせて調整されていない場合、また、怒っているネットワーク管理者からの訪問を得る可能性が最も高いようです。
したがって、これは比較的低帯域幅のアプリケーションであるため、多くの場合「安価」であるかどうかにかかわらず、各クライアントから4〜5分ごとに最大1回の更新が行われ、25〜50クライアント以下になる可能性があります。別の戦略を使用する方法：
- マルチキャスト：239.255 / 16から既知のマルチキャストアドレスを選択し、関心のあるアプリケーションを起動時にグループに参加させる方法を見つけます。
- ブロードキャスト：誰かのステータスが変更されるたびに1つのUDPブロードキャストメッセージを送信します（アプリの起動時に1つの「更新」ブロードキャストが送信され、その後、すべてのクライアントが現在のステータスで要求元のユーザーに直接応答します）。
- ユニキャスト：アプリケーションの開始時にUDPブロードキャストを送信して関心をアナウンスし、クライアントのステータスが変更されると、アナウンスしたすべてのクライアントにUDPパケットを直接送信します。これにより、トラフィックが最大になりますが、不要なブロードキャストパケットで他のシステムを煩わせる可能性は低くなります。また、アプリがクラッシュしたときに（不要なトラフィックを生成するという点で）潜在的な問題が発生します。
マルチキャストは間違いなくこの仕事に最適なテクノロジーですが、これは単なる「おもちゃのアプリケーション」であり、専門的なネットワーク管理者の展開と構成を目的としたビジネスクリティカルなサービスではないため、関連する煩わしさを回避する価値があるかどうか疑問に思います。