Создание веб-сайта для связи со встроенным устройством

Question

В настоящее время я работаю над проектом, где я пытаюсь управлять встроенным устройством через веб-сайт, ориентированный на Интернет. Идея состоит в том, что пользователь может перейти на веб-сайт и сообщить об этом устройству, чтобы выполнить какое-то действие. Действие на веб-сайте будет переведено в последовательность команд CLI, а затем отправлено на устройство. Коммуникация потенциально может идти в обоих направлениях в будущем, но сейчас я сосредоточен на сервере-на-устройстве.

Веб-сервер представляет собой стек LAMP с использованием Python (Django), а устройство, с которым я пытаюсь установить соединение, - это доска Beagle, работающая под управлением eLinux. В любое время будет доступно только одно устройство, сообщающее серверу.

У меня есть все функциональные части, написанные на стороне сервера и устройства, но у меня есть небольшая проблема, связанная с тем, как написать коммуникационный уровень. Одна из моих больших проблем заключается в том, что устройство будет мобильным и будет перемещать места каждые несколько дней. Таким образом, я не могу гарантировать статический IP-адрес устройства. Мои знания в области сетевого программирования довольно минимальны, поэтому у меня нет такой большой идеи о том, с чего начать.

Есть ли у кого-нибудь идеи/ресурсы о том, как я могу начать развивать такое общение?

Спасибо!

Answer 1

Вы можете просто зарегистрировать динамическое имя хоста с помощью поставщика, такого как DynDNS, и обновить его IP-адрес на этом сайте, чтобы динамическое имя хоста всегда указывало на IP-адрес устройства - для Linux доступно множество клиентов, скриптов и т. Д. которые делают именно это.

Answer 2

Если сервер будет статическим, вы всегда можете заставить устройство установить соединение с сервером, чтобы сообщить его IP-адрес.

Вы можете написать a simple UDP server, чтобы устройство могло прослушивать входящие сообщения, а затем write a client in python для вашего веб-сервера.

Answer 3

Мой нормальный режим поведения (конечно же, как она могла бы пройти через NATs и тому подобное), чтобы иметь устройство установить обратный SSH туннель, который просто «звонит домой»: http://www.howtoforge.com/reverse-ssh-tunneling

заметь, SSH соединения время от времени ломаются, поэтому я установил метод heartbeat на сервере, и если клиент (Beagle Board) пропустит определенное количество сердечных сокращений, пусть он уничтожит туннель &, создайте новый.

Answer 4

устройство будет мобильным и будет перемещаться по местоположению каждые несколько дней. Таким образом, я не могу гарантировать статический IP-адрес устройства.

Ваше устройство может быть клиентом веб-сайта.

Ваш веб-сайт имеет два интерфейса.

1. HTML-интерфейс для людей.

2. Интерфейс, не являющийся HTML-интерфейсом к устройству. В качестве клиента веб-сайта устройству потребуется HTTP-клиентская библиотека для отправки запроса на веб-сайт. Этот запрос будет включать в себя IP-адрес устройства, а также весь обычный malarky, похороненный в HTTP-запросе.(Есть куча стандартных заголовков, которые посылаются в запросе)

После того, как устройство сделал это первоначальный запрос, то ваш веб-сайт может сохранить текущее состояние устройства и взаимодействовать с ним через другой протокол, если вы хочу сделать это. (Я предполагаю, что «у меня есть все функциональные части, написанные на стороне сервера и устройства», означает, что у вас есть другой протокол для управления устройством, и этот протокол не основан на HTTP.)

Это может быть быть простейшим в конечном счете, чтобы устройство опросило веб-сайт для команд или обновлений или вещей. Таким образом, устройство является чистым веб-клиентом, использующим только HTTP, а ваш веб-сайт является чистым веб-сервером, используя только HTTP. Тогда вам не нужен ваш более специализированный второй протокол. Использование только HTTP означает, что вы можете использовать SSL для обеспечения безопасной связи.

Если ваше устройство использует HTTP для получения команд и обновлений, вам нужно будет разработать полезное представление для данных, которые могут быть легко закодированы в HTTP-запросы и ответы. Варианты включают XML, JSON и YAML. Вы всегда можете придумать свой собственный формат данных; однако вы, вероятно, будете более счастливы отлаживать стандартизованный формат, такой как JSON.

Построение этих двух интерфейсов в Django довольно тривиально. У вас просто будет URL-адрес, который предназначен для людей и некоторых, которые предназначены для вашего устройства. У вас будут функции просмотра для людей, которые возвращают HTML-страницы, и просматривать функции для вашего устройства, которые возвращают JSON или XML-сообщения.