创建一个网站以与嵌入式设备通信
我目前正在开发一个项目，尝试通过面向互联网的网站控制嵌入式设备。这个想法是，用户可以访问网站并告诉该设备执行某种操作。网站上的操作将被转换为一系列 CLI 命令，然后发送到设备。未来通信可能是双向的，但现在我专注于服务器到设备。
Web 服务器是使用 Python (Django) 的 LAMP 堆栈，我尝试与之通信的设备是运行 eLinux 的 Beagle Board。任何时候都只有一台设备与服务器进行通信。
我在服务器和设备端编写了所有功能部分，但在弄清楚如何编写通信层时遇到了一些麻烦。我的一大问题是该设备将是移动的，并且每隔几天就会移动位置。因此，我无法保证设备有静态 IP 地址。我的网络编程知识非常少，所以我不知道从哪里开始。
有人对我如何开始发展这种沟通有任何想法/资源吗？
谢谢！
I'm currently working on a project where I'm trying to control an embedded device through an Internet facing website. The idea is is that a user can go to a website and tell this device to preform some kind of action. An action on the website would be translated into a series of CLI commands and then sent to the device. Communication could potentially go both ways in the future, but right now I'm focusing on server-to-device.
The web server is a LAMP stack using Python (Django) and the device I'm trying to communicate with is a Beagle Board running eLinux. There would be only one device existing at any time communicating to the server.
I have all the functional parts written on the server and device side, but I'm having a bit of trouble figuring out how to write the communication layer. One of my big issues is that the device will be mobile and will be moving locations every few days. So, I can't guarantee a static IP address for the device. My networking programming knowledge is pretty minimal so I don't have that great an idea on where to start.
Does anyone have any ideas/resources on how I can start developing this kind of communication?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您只需使用 DynDNS 等提供商注册动态主机名，然后让设备在该网站上更新其 IP，以便动态主机名始终指向设备 IP - Linux 上有大量的客户端、脚本等可以做到这一点。
You can simply register a dynamic host name using a provider like DynDNS and have the device update it's IP on that website so the dynamic hostname always points to the device IP - there are plenty of clients, scripts etc. available for Linux that do just that.
如果服务器是静态的，您始终可以让设备与服务器建立连接以报告其 IP 地址。
您可以编写 一个简单的 UDP 服务器，供设备监听传入通信，然后用 python 编写一个客户端供您的 Web 服务器调用。
If the server is going to be static, you could always get the device to establish a connection to the server to report it's IP address.
You could write a simple UDP server for the device to listen for incoming communications and then write a client in python for your web server to call.
我的正常行为模式（当然，因为它可能必须通过 NAT 等）是让设备设置一个反向 SSH 隧道，该隧道只是“打电话回家”：http://www.howtoforge.com/reverse-ssh-tunneling
请注意，SSH 连接有时会中断，所以我设置了一个在服务器上设置心跳方法，如果客户端（Beagle Board）错过了一定数量的心跳，则让它破坏隧道并发送消息。创建一个新的。
My normal mode of conduct (certainly as it could have to go through NATs and the like) is to have the device set up a reverse SSH tunnel that just 'calls home': http://www.howtoforge.com/reverse-ssh-tunneling
Mind you, SSH connections break from time to time, so I'd set a heartbeat method on the server, and if the client (Beagle Board) misses a set amount of heartbeats, let it destroy the tunnel & create a new one.
您的设备可以是该网站的客户端。
您的网站有两个界面。
面向人们的 HTML 界面。
设备的非 HTML 界面。作为网站的客户端，设备将需要 HTTP 客户端库来向网站发送请求。该请求将包括设备的 IP 地址，以及 HTTP 请求中隐藏的所有常见内容。 （请求中发送了一堆标准标头）
一旦设备发出初始请求，您的网站就可以保存设备的当前状态，并通过其他协议与其进行通信（如果您愿意的话）。
（我猜测“我在服务器和设备端编写了所有功能部分”意味着您有一些其他协议来控制设备，并且该协议不是基于 HTTP 的。）
从长远来看，这可能是最简单的运行以使设备轮询网站以获取命令或更新或其他内容。这样，设备就是一个仅使用 HTTP 的纯 Web 客户端，而您的网站是一个仅使用 HTTP 的纯 Web 服务器。那么您就不需要更专业的第二个协议。仅使用 HTTP 意味着您可以使用 SSL 来确保安全通信。
如果您的设备使用 HTTP 来获取命令和更新，您需要为可以轻松编码到 HTTP 请求和响应中的数据制定可用的表示形式。选项包括 XML、JSON 和 YAML。您始终可以发明自己的数据格式；但是，您可能会更乐意调试 JSON 等标准化格式。
在 Django 中构建这两个接口非常简单。您只需拥有一些供人们使用的 URL 和一些供您的设备使用的 URL。您将为返回 HTML 页面的人员提供查看功能，并为您的设备提供返回 JSON 或 XML 消息的查看功能。
Your device can be a client of the web site.
Your web site has two interfaces.
HTML interface to people.
A non-HTML interface to the device. As a client of a web site, the device will need an HTTP client-side library to send a request to the web site. This request will include the device's IP address, plus all the usual malarky buried in an HTTP request. (There are a bunch of standard headers that are sent in a request)
Once the device has made it's initial request, then your web site can save the device's current status and communicate with it through another protocol if you want to do that.
(I'm guessing that "I have all the functional parts written on the server and device side" means you have some other protocol for controlling the device, and this protocol isn't based on HTTP.)
It might be simplest in the long run to have the device poll the web site for commands or updates or things. That way the device is a pure web client using only HTTP, and your web site is a pure web server, using only HTTP. Then you don't need your more specialized second protocol. Using only HTTP means you can use SSL to assure a secure communication.
If your device uses HTTP to get commands and updates, you'll need to work out a usable representation for data that can easily be encoded into HTTP requests and responses. Choices include XML, JSON and YAML. You can always invent your own data format; however, you'll probably be happier debugging a standardized format like JSON.
Building these two interfaces in Django is pretty trivial. You'll simply have some URL's which are for people and some which are for your device. You'll have view functions for people that return HTML pages, and view functions for your device that return JSON or XML messages.