6

LAN上のすべての人に連絡して、現在IPを使用してサービスを実行しているデバイスを見つけようとしています。サービスを実行しているすべてのデバイスは、オンラインになったときに他のどのデバイスが接続されているかを認識します。私は基本的なネットワークの経験（tcp / udp）を持っていますが、より複雑な通信パッケージについてはあまり行っていません。私はこれまでに調査/試行したことを投稿し、将来の潜在的な解決策に関する試行錯誤の時間を制限するために専門家の回答を得たいと思いました。

要件：

  • 現在Javaを使用していますが、言語間の通信が必要です。
  • 許容可能な時間枠（最大数秒）で、できれば確実に実行する必要があります。
  • 複数のパッケージ/テクノロジーの複雑さが増すのを避けるために、ブロードキャストとその後の通信の両方に同様のテクニックを使用したいと思います。
  • 現在、既知のIPにハートビートを送信して、まだ接続されていることを警告することを計画していますが、後でLANに継続的にブロードキャストしたい場合があります。
  • このサービスにクロスランゲージRPC通信を使用することに興味がありますが、この手法では必ずしもそれを使用する必要はありません。
  • 後の通信（非ブロードキャスト）は信頼できるものでなければなりません。

研究と試みられたもの：

  • UDP-言語間のコミュニケーション、信頼できる配信の欠如を心配しており、以下のような1つのソリューションを使用するのではなく、別のコミュニケーション方法を追加します。別のより完全な解決策が見つかった場合は、それを避けたいと思います。

  • Apache Thrift-現在、私はすべての潜在的なIPを反復処理し、それぞれに接続しようとしました。接続を試行するたびにタイムアウトが長くなるため、これは遅すぎます（openと呼んだ場合）。放送オプションはまだ見つかりません。

  • ZeroMQ-基本的なzeromqでほとんどテストを行いませんでしたが、私は過去にそのラッパーのみを使用しました。pub / sub機能はこのシナリオに役立つようですが、LAN内のすべてのIPをサブスクライブすることを心配しています。また、まだサービスが実行されていないIPをサブスクライブしようとするとどうなるか心配しました。

これらの推奨事項のいずれかが、私の要件を考慮して他の推奨事項よりもうまく機能するように見えますか？よりうまく機能する可能性のあるテクノロジーに関する他の提案はありますか？

ありがとう。

4

3 に答える 3

8

指定するのは、基本的に2つの別々の問題です。発見/監視およびサービスプロバイダー。これらの2つの問題はやや直交しているため、これを実装するために2つの異なるアプローチを使用します。

発見/監視

各デバイスが、事前定義されたポートのUDPを介してLAN上で（小さな）ハートビート/状態メッセージを継続的にブロードキャストできるようにします。このハートビートには、デバイスのIP /ポート（送信者）と、このデバイスが提供するサービスへのアドレス（URL）などの他の興味深いデータが含まれている必要があります。帯域幅の使用率を抑える必要がある場合は、コンパクトなメッセージ形式を選択してください。たとえば、プロトコルバッファ（多くの言語で利用可能）や読みやすさのためのJSONなどです。これらのメッセージは定期的に、たとえば5秒ごとに公開されるものとします。

次に、各デバイスにブロードキャストアドレスで着信メッセージをリッスンさせ、すべての既知のデバイスのメモリ内マップ[送信者、最終記録時刻+その他のデータ]を保持させます。マップを毎秒繰り返し、xハートビート間隔（たとえば3 x 5秒）の間無音であった送信者を削除します。このようにして、各ノードは他のすべての応答ノードについて認識します。

IPについて知る必要はなく、追加のディレクトリサーバーも必要なく、すべての可能なIPアドレスを繰り返す必要もありません。また、UDPを介したデータの送受信はTCPを介した場合よりもはるかに簡単であり、接続は必要ありません。また、生成されるオーバーヘッドが少なくなり、帯域幅の使用率が低くなります。

サービスプロバイダー

ここで、ある種の要求/応答が必要だと思います。このために、JSONを話すHTTP経由の単純なRESTベースのAPIを選択します。ペイロードがかなり大きい場合は、プロトコルバッファのJSONペイロードを切り替えますが、ほとんどの場合、JSONはおそらく問題なく機能します。

全体として、これにより、堅実で、パフォーマンスが高く、信頼性が高く、クロスプラットフォームでシンプルなソリューションが得られます。

于 2013-01-12T20:39:59.420 に答える
4

ZeroMQガイド（第8章）のZyreプロジェクトをご覧ください。これは、段階的に開発された、かなり完全なローカルネットワーク検出およびメッセージングフレームワークです。あなたは間違いなくUDPブロードキャストとディスカバリーを再利用することができます、おそらく残りも同様です。完全なJava実装もあります、https：//github.com/zeromq/zyre。

于 2013-01-13T00:20:54.727 に答える
1

クロスプラットフォーム（少なくともクライアントの場合）が可能なJMSを使用します。データのエンコード方法を決定する必要があります。具体的なアイデアがない限り、XMLまたはJSonを使用します。これらは読みやすく、確認しやすいためです。

ZeroMQを使用して、パフォーマンスを向上させ、アクセスレベルを下げることができます。あなたがこれを必要としていることを知らない限り、私はあなたが必要としないのではないかと思います。

JMSの高レベルの機能を利用できる場合があります。

ところで：これらのサービスは暗黙的にサービス検出を行います。IPアドレスやサービスが稼働しているかどうかを知る必要はありません（監視を除く）。それらの設計は、これらの詳細を知る必要から保護したいことを前提としています。

于 2013-01-12T17:53:21.670 に答える