php и последовательный порт RS232
Лапоть
Имеется следующая схема.
Компьютер + Apache + PHP + (еще что-то не особо важное).
Это компьютер подключен по последовательному порту (RS232) к
техническому устройству, например, телефону.
Как реализуется доступ к устройству из stand-alone приложения знаю, а
как в сеансовой веб-среде без сохранения состояния пока не очень :).
Заранее благодарен за любые ссылки и подсказки по следующим вопросам:
1) Интересуют варианты управления телефоном с помощью браузера через
PHP. Точнее техническая реализация подобной системы, ее архитектура.
Класс для работы с COM-портом нашел, но им можно только записывать
команды в девайс. А задача получить ответ, а потом и отправить его на
клиента. Каким путем это можно реализовать?
2) В схеме меняем RS232 на Ethernet. Используем сокеты. И опять какая
будет архитектура системы взаимодействия с устройством?
3) Ссылки на подобные странички интересуют больше всего.
DimoNya
последующими пометками о выполнении / ошибке / и т.д и т.п. ...
crim...@googlemail.com
On 2 ноя, 13:19, Лапоть <lapot1...@gmail.com> wrote:
> Добрый день.
>
> Имеется следующая схема.
> Компьютер + Apache + PHP + (еще что-то не особо важное).
> Это компьютер подключен по последовательному порту (RS232) к
> техническому устройству, например, телефону.
>
> Как реализуется доступ к устройству из stand-alone приложения знаю, а
> как в сеансовой веб-среде без сохранения состояния пока не очень :).
В любом случае надо реализовывать приложение, работающее независимо
от запросов. В этом случае использование PHP теряет смысл, делай его
на С или на чем привык, и где есть нормальные библиотеки работы с
требуемой аппаратурой. А на PHP пиши только фронт-энд, который
обеспечит интерфейс пользователя и передачу команд приложению, через
базу, как предлагает DimoNya, или через memcache, или хоть через файлы
- как удобнее.
Nikolay Galkin
Для фронтенда использовал РНР+AJAX. Для работы с RS232 программулина на Delphi. Хранили все в MySQL. "Общались" тоже через БД. Если честно, работать через БД не очень удобно. Мой совет пропарьтесь чуть больше, но сделайте "конфетку". Есть много технологий общения. Возможно работа через порты (сокеты) или через XML-RPC. Я бы щас сделал как раз через второе. Не знаю, как там у вас, но нам пришлось делать приложение с потоками. Ну там вообщем много че еще вертелось. Дерзайте.
В Срд, 04/11/2009 в 17:13 -0800, crim...@googlemail.com пишет:
Василий Князев
Собственно уже первое приближение реализовал.
Если кому интересно:
1) Написал rs232 сервер-мультиплексор.
2) Скрипт коннектится к с серверу по сокетам.
Пока все работает :). Ответ на команду от устройства приходит менее чем за секунду.
Быть может, когда нибудь, появятся команды исполняющиеся сильно больше во времени, дольше разрешенного времени исполнения скрипта. Ну и вообще длительные команды тоже.
В таком случае как реализовать обработку подобных команд.
Я вижу след. вариант.
1) браузер шлет запрос на команду
2) сервер отвечает что команда принята
3) браузер по таймеру шлет "запрос на результат"
4) сервер отвечает. "Продолжаем", "сбой", "результат"
Прав ли я?
Спасибо.
crim...@googlemail.com
On 9 ноя, 14:28, Василий Князев <lapot1...@gmail.com> wrote:
> 1) браузер шлет запрос на команду
> 2) сервер отвечает что команда принята
> 3) браузер по таймеру шлет "запрос на результат"
> 4) сервер отвечает. "Продолжаем", "сбой", "результат"
>
> Прав ли я?
Проблема эта в общем виде звучит так: "Как передать браузеру
сгенерированное сервером событие?" В данном случае событие - конец
обработки запроса, а сама проблема возникает из-за того, что
изначально протокол HTTP проектировался исходя из того, что события
будет генерировать исключительно пользователь.
Можно делать и так, это метод опроса. Но есть и другие варианты,
более эффективные. Я когда-то решал такую задачу, когда писал WEB-чат,
никакого Ajax тогда еще не было. Я тогда назвал это технологией
бесконечного соединения и использовал фреймы, а в современных реалиях
это выглядит примерно так: браузер шлет ajax запрос на определенный
URL, на котором сидит скрипт, проверяющий наличие событий. Скрипт этот
крутится в вечном цикле, где делает следующие действия: предотвращает
завершение соединения по таймауту (например, шлет один пробел в
минуту), проверяет, не завершил ли соединение клиент (тогда поток
стреляется), и проверяет наличие событий. При наличии событий
формируется пакет с информацией о них и посылается клиенту. В браузере
срабатывает обработчик onreadystatechange, забирает данные и
обрабатывает соответствующим образом, меняя что надо на клиенте. При
этом задержка отображения события в браузере зависит от периода цикла
опроса на сервере, что можно сделать очень быстро, плюс сетевые
задержки. В случае постепенного прихода событий нормальные браузеры
позволяют забирать их порциями, по мере прихода, так что оверхеда по
траффику практически нет - все идет в рамках одного соединения,
которое открылось один раз, а закрывается только когда пользователь
уходит со страницы. Единственная проблема - с IE, потому что эти
дебилы не в состоянии нормально реализовать свой собственный стандарт.
В IE невозможно получить responseText, пока соединение не будет
закрыто, поэтому если надо, чтобы работало и в нем, серверный скрипт
шлет информацию и закрывает соединение, а клиентский скрипт, получив
инфу и обработав ее, опять делает AJAX запрос на тот же URL и сидит
ждет событий дальше.
alex basov
понедельник, 9 ноября 2009 г., 14:28:41 UTC+2 пользователь Лапоть написал: