硬件和 Web 组件之间使用哪种实时通信协议？
我不完全确定如何在标题中表达我的问题，所以如果它令人困惑，我深表歉意。
我想构建一个系统，作为我家的信息仪表板。它将由许多硬件和软件组件组成，最终形成一个简单、干净的网站，并实时显示许多模拟传感器，如温度、风速和风向等。
我有一个好主意我要对硬件以及显示信息做什么；我的问题与硬件和网络服务器之间的通信有关。
我希望硬件以相当快的速度发送消息，所以我认为 HTTP POST 不够。我也不太关心收到 100% 的消息，但收到尽可能多的消息绝对是一个优势。数据将来自硬件，填充某种数据库（可能是 Redis）。
到目前为止，我已经研究了一些事情，但我不确定我是否朝着正确的方向前进。我研究过面向消息的中间件，例如 RabbitMQ 但我不相信我需要开销。我还研究了 Redis Pub/Sub 这似乎是一个更合适的解决方案，因为我想要Web 应用程序来绘制最近 5 分钟的数据，但即便如此我也不确定。我可以只向自定义侦听器发送 UDP 数据包吗？
我非常确定硬件将分为两个阶段（一个 uC 为小型嵌入式 Linux 机器提供数据），因此您甚至可以将其比作桌面软件尽快向 Web 服务器发送消息。
我正在冒险进入一个我完全不了解的领域，因此非常感谢任何指导。
I wasn't entirely sure how to word my question in the title so apologies if it's confusing.
I'd like to build a system that would function as a sort of information dashboard for my home. It would consist of a number of hardware and software components that would ultimately result in a simple, clean website with real-time displays of a number of analog sensors such as temperature, wind speed and direction, etc.
I've got a good idea of what I'm going to do for the hardware, as well as for displaying the information; my question has to do with the communication between the hardware and web server.
I'd like the hardware to fire messages at a fairly fast rate so I don't think HTTP POST will suffice. I'm also not extremely concerned with receiving 100% of the messages but receiving as many as possible is definitely a plus. The data will be coming from the hardware, populating some sort of database (likely Redis).
So far, I've researched a couple of things but I'm not sure I'm heading in the right direction. I've looked in to message-oriented middleware such as RabbitMQ but I'm not convinced I need the overhead. I've also looked into Redis Pub/Sub which seems like a more appropriate solution since I'd like the web app to chart out say the last 5 minutes of data but even then I'm not certain. Can I just fire UDP packets to a custom-built listener?
I'm pretty certain the hardware will be two stages (a uC feeding a small embedded linux machine) so you might even liken this to desktop software firing messages to a web server as quickly as possible.
I'm venturing into an area that I know absolutely nothing about so any guidance is much appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
要在数据采集器和收集器之间进行通信，您可以考虑使用行业标准 Modbus TCP 协议。 （在前世，我为可编程控制器编写了网络代码。）
我确信大多数微控制器都有可用的库，尽管它们可能不是开源的，
但我怀疑是否存在 JS 版本的 Modbus，因此您需要自己编写服务器端库。我记得 Modbus 并不是特别复杂，特别是如果您不使用它的一些深奥功能的话。当然，写这篇文章让我思考如何写这样的东西，你瞧，它是 < a href="https://github.com/TooTallNate/node-modbus-stack" rel="nofollow">已经为nodejs完成了！ （我喜欢 Nodejs 社区的众多原因之一！）所以这就是简单的答案......现在，我的黑客帽子牢牢就位......
你提到你的硬件将为一台或多台“小型嵌入式 Linux 机器（ s）”。
您是否考虑过在每个数据收集器上运行nodejs？如果nodejs的可执行文件的大小是问题，我确信它的大部分开箱即用功能可以被删除或移动到模块中。
我意识到我所推荐的并不是一项小任务——将 Nodejs/V8 的大小和复杂性的应用程序移植到新平台肯定具有挑战性——但我强烈怀疑 NodeJS 的事件驱动设计将是一个很好的匹配数据采集、离散制造、过程控制和其他制造应用。
To communicate between your data acquirers and collectors, you might consider the industry standard Modbus TCP protocol. (In a previous life, I wrote network code for programmable controllers.)
I'm sure there are libraries available for most microcontrollers, though they might not be open-source,
but I doubt a JS version of Modbus exists so you'd need to write the server-side lib yourself. As I recall Modbus isn't particularly complex, especially if you don't use some its more esoteric features.Of course, writing this got me thinking how I'd write such a thing and lo and behold, it's already been done for nodejs! (One of the many reasons I love the nodejs community!)So thats the easy answer...now, with my hacker-hat firmly in place...
You mention that your HW will feed one or more "small embedded Linux machine(s)".
Have you considered running nodejs on each data collector? If the size of nodejs' executable is the issue, I'm sure there are large parts of its out-of-the-box functionality that could be removed or moved into modules.
I realize what I'm recommending is not a small undertaking--porting an application the size and complexity of nodejs/V8 to a new platform is certainly challenging--but I strongly suspect nodejs' event-driven design would be an excellent match for data acquisition, discrete manufacturing, process control, and other manufacturing applications.
就像提到的其他发帖人一样，您不会遇到 http post 问题。 Node 的 http 实现是为高并发而构建的。
就个人而言，我认为我会选择：
Socket.io 可能是Node.js 的最佳开箱即用实时传输 <==> 如果您想要持久性
，如果您的数据适合该模型（它可能确实如此），那么 Redis 也不错（而且您还可以获得免费的发布/订阅）。
如果那是你的包的话，你没有理由不能使用基于 reglar tcp 的连接（网络模块）。除非你希望数据不可靠，否则我不会去udp。那是面向有损流媒体的。
我真的怀疑您是否有足够的消息来担心专用消息队列。 Rabbitmq 引入了队列持久性等功能，专为实现令人难以置信的高吞吐量而构建。可能比你所追求的要高几个数量级。
您可能会查看像 Zeromq 这样的库，其中有节点绑定： https://github.com/JustinTulloss/ Zeromq.node。它就像rabbitmq中的主题/其他类型的交换，但没有中央消息队列节点（人们称之为无代理）。这样，您就可以直接与您的 Linux/硬件节点对话，但仍然获得消息队列之类的接口——您在“通道”上发布硬件更新，并且您的服务器节点会侦听此类更新。
Like the other poster mentioned, your're not going to have issues with http post. Node's http implementation is built for high concurrency.
Personally, I think I'd go with:
Socket.io is probably the best out of the box real time transport for node.js <==> browser
If you want persistence, redis isn't bad (plus you get the free pub/sub) if your data fits into that model, which it probably does.
There's no reason you couldn't use a reglar tcp based connection also (net module) if thats your bag. Unless you want the data to be unreliable, I wouldn't go to udp. Thats more lossy streaming media oriented.
I really doubt that you're going to have enough messages to worry about a dedicated message queue. Rabbitmq introduces features like queue persistence and is built for incredibly high throughput. Probably orders of magnitude more than what you're after.
You might look at a library like zeromq for which there are node bindings: https://github.com/JustinTulloss/zeromq.node. Its like a topic/other type of exchange in rabbitmq, but without a central message queue node (one calls this brokerless). That way you can just talk directly to your linux/hardware nodes, but still get the message queue like interface -- you publish your hardware updates on a 'channel' and your server nodes listens for such updates.
http post 出了什么问题？如果您使用 Node.js 作为 Web 服务器，它应该足够快。您已经在节点中编码了表示层，因此您需要使用的工具少了一个，在这种情况下它是完美的选择。保持简单并坚持使用节点。
What's wrong with http post? If you are using node.js as your web server it should be plenty fast enough. You are already coding the presentation layer in node so that's one less tool you will have to use, and in this case it's a perfect fit. Keep it simple and stick with node.