2

タイトルでの質問の言い方がよくわからなかったので、紛らわしかったら申し訳ありません。

自宅の情報ダッシュボードのようなシステムを構築したいと考えています。それは、温度、風速、風向などの多数のアナログ センサーをリアルタイムで表示する、シンプルでクリーンな Web サイトを最終的にもたらす多数のハードウェアおよびソフトウェア コンポーネントで構成されます。

ハードウェアと情報の表示をどうするかについては、よくわかっています。私の質問は、ハードウェアと Web サーバー間の通信に関するものです。

ハードウェアがかなり速い速度でメッセージを送信するようにしたいので、HTTP POST では十分ではないと思います。また、メッセージを 100% 受信できるかどうかはあまり気にしていませんが、できるだけ多くのメッセージを受信できることは間違いなくプラスです。データはハードウェアから取得され、ある種のデータベース (おそらく Redis) に入力されます。

これまでのところ、いくつかのことを調査しましたが、正しい方向に向かっているかどうかはわかりません。RabbitMQなどのメッセージ指向のミドルウェアを調べましたが、オーバーヘッドが必要かどうかはわかりません。また、Web アプリで最後の 5 分間のデータをグラフ化する必要があるため、より適切なソリューションのように思われるRedis Pub/Subも調べましたが、それでも確信が持てません。カスタムビルドのリスナーに UDP パケットを送信することはできますか?

ハードウェアは 2 段階 (uC が小さな組み込み Linux マシンに供給する) になると確信しているので、これをデスクトップ ソフトウェアが Web サーバーにできるだけ早くメッセージを送信することにたとえることもできます。

私はまったく何も知らない分野に足を踏み入れているので、どんなガイダンスも大歓迎です。

4

3 に答える 3

1

データ取得者と収集者の間で通信するには、業界標準のModbus TCPプロトコルを検討してください。（前世ではシーケンサのネットワークコードを書いていました。）

オープンソースではないかもしれませんが、ほとんどのマイクロコントローラで利用できるライブラリがあると確信しています。しかし、Modbus の JS バージョンが存在するとは思えないため、サーバー側の lib を自分で作成する必要があります。特に難解な機能を使用しない場合は特に、Modbus はそれほど複雑ではありません。もちろん、これを書いていると、私はそのようなことをどのように書くかを考えさせられました。そして、見よ、それは nodejs のためにすでに行われています! (私が nodejs コミュニティを愛する多くの理由の 1 つです!)

それは簡単な答えです...今、私のハッカー帽子をしっかりと固定しています...

あなたのハードウェアは、1 つ以上の「小さな組み込み Linux マシン」に供給すると述べています。

各データコレクターで nodejs を実行することを検討しましたか? nodejs の実行可能ファイルのサイズが問題である場合、すぐに使用できる機能の大部分が削除またはモジュールに移動できると確信しています。

私が推奨していることは小さな仕事ではないことを理解しています.nodejs/V8のサイズと複雑さのアプリケーションを新しいプラットフォームに移植することは確かに困難です.しかし、nodejsのイベント駆動型設計は、データ取得、ディスクリート製造、プロセス制御、およびその他の製造アプリケーション。

于 2011-06-01T18:29:16.403 に答える
0

言及された他のポスターのように、あなたはhttp投稿で問題を抱えることはないでしょう。ノードのhttp実装は、高い同時実行性のために構築されています。

個人的に、私は一緒に行くと思います：

  1. ハードウェアデバイス出力->
  2. Linuxボックスは、中央サーバー（node.js）に直接http投稿を起動します->
  3. 変更を取得し、すぐにsocket.io（ブラウザーのリアルタイムトランスポート）を介してWebクライアントに公開します。https://github.com/LearnBoost/Socket.IO/

Socket.ioは、node.js<==>ブラウザの箱から出してすぐに使えるリアルタイムトランスポートとしておそらく最適です。

永続性が必要な場合、データがそのモデルに適合する場合、redisは悪くありません（さらに、無料のpub / subを取得します）。

それがあなたのバッグであるならば、あなたが通常のtcpベースの接続（ネットモジュール）も使うことができなかった理由はありません。データの信頼性を低くしたい場合を除いて、私はudpに行きません。それは、より損失の多いストリーミングメディア指向です。

専用のメッセージキューについて心配するのに十分なメッセージがあるかどうかは本当に疑わしいです。Rabbitmqは、キューの永続性などの機能を導入し、信じられないほど高いスループットを実現するように構築されています。おそらくあなたが求めているものよりも桁違いに多いでしょう。

ノードバインディングがあるzeromqのようなライブラリを見るかもしれません：https ：//github.com/JustinTulloss/zeromq.node 。これは、rabbitmqのトピック/他のタイプの交換に似ていますが、中央のメッセージキューノードがありません（これをブローカーレスと呼びます）。そうすれば、Linux /ハードウェアノードと直接通信できますが、インターフェイスのようなメッセージキューを取得できます。ハードウェアの更新を「チャネル」で公開し、サーバーノードがそのような更新をリッスンします。

于 2011-06-01T05:55:39.090 に答える
0

http投稿の何が問題になっていますか？node.js を Web サーバーとして使用している場合、十分に高速である必要があります。ノードでプレゼンテーション層をすでにコーディングしているため、使用する必要があるツールが 1 つ少なくなり、この場合は完全に適合します。シンプルに保ち、ノードに固執します。

于 2011-06-01T04:03:17.237 に答える