LINUX.ORG.RU

Работа с сокетами через веб

 , , , ,


0

1

Пилю веб-управлялку некими железками, взаимодействие с которыми происходит по сокетам (в большинстве случаев через конвертеры rs232 <=> tcp socket).

До последнего времени задача была одна - послать команду, а там трава не расти. С этим успешно справлялось простое приложение на Flask с post-запросами через jquery и socket.send().

Но настала пора слушать что железки вещают и сигнализировать об определенных событиях в веб-морду.

1. Есть ли актуальные best practice как это все делается? Ни с async, ни c обычными потоками я никогда не работал, поэтому не знаю с чего начать.

2. Если брать asyncio, то стоит ли переходить на aiohttp, или из Flask тоже можно работать?

★★★★★

Возьми aiohttp или tornado. Есть какие-то асинхронные фласк-подобные фреймворки(sanic и т.п.) но я не пробовал.

Слушай сокет и при получении данных отправляй их через websocket и наоборот.

pawnhearts ★★★★ ()
Ответ на: комментарий от Shadow

Как я понимаю - есть два способа.

1. Периодически опрашивать все железки на предмет изменения состяния

2. Слушать сокет и реагировать по событию от конкретного контроллера.

Первый способ мне придется по любому использовать - не все железки шлют в сокет сообщение об изменении состоянии.

Не есть критические участки. Например, контроллер конференции - в момент включения микрофона он шлет номер сплиттера и микрофона. И реагировать надо мгновенно - повернуть на участника камеру.

Turbid ★★★★★ ()
Последнее исправление: Turbid (всего исправлений: 1)

Есть ли актуальные best practice

Насчёт бест неуверен, но если задаться ассинхронщиной, то как вариант, через очередь. Одна корутина в цикле опрашивает железки, фильтрует и нужное событие пихает в очередь. Другая корутина слушает очередь и уже отправляет что нужно через ws клиенту.

Если брать asyncio, то стоит ли переходить на aiohttp

Да, aiohttp прикольная. Но вебсокеты там своеобразны, надо просто вникнуть как с ними работать, в принципе документации должно хватить.

vvn_black ★★★★ ()

может ли железка принимать команду, пока не завершила ответ на предыдущую? если нет и количество железок ограничено (например, 10-20 штук на один сервер), то лучше использовать подход prefork и держать по воркеру на железку, которые будут работать полностью синхронно.

annulen ★★★★★ ()
Ответ на: комментарий от annulen

Порт-то один! А железок много.

Лучше так: один (основной) поток на порт и по одному потоку на каждую железку. Основной поток будет парсить сообщения и через очереди или еще как-нибудь рассылать их нужным потокам; он же будет слушать потоки и при необходимости писать нужное в порт. Плюс еще один поток нужен для работы с вебсокетами: отсылка команд из входящей очереди в вебсокет и отправление входящих через вебсокет сообщений в очередь к основному потоку.

Все достаточно просто можно накалякать. Особенно если учесть, что клиент может быть только один! Здесь даже веб-сервер использовать не нужно! Сам основной демон может отдавать веб-страницу и жабоскрипт по запросу.

anonymous ()
Ответ на: комментарий от anonymous

Порт-то один! А железок много.

Порт один, но если открыть слушающий сокет до форка, то ОС будет работать как балансировщик между несколькими процессами

Пардон, это только с EPOLLEXCLUSIVE так. В остальных случаях событие придет на все копии сокета, и первый проснувшийся воркер должен сделать accept под мьютексом

annulen ★★★★★ ()
Последнее исправление: annulen (всего исправлений: 1)
Ответ на: комментарий от Turbid

Ну так Стивенса почитай! В чем проблема? pthreads, select/poll — и вперед!

Обычный язык С. Или С++, если он тебе больше нравится (хотя, в данном случае он вообще не нужен, т.к. никакой ООПщиной здесь не пахнет).

anonymous ()

Если на питоне, то asyncio/aiohttp лучше не придумаешь. Flask вообще не умеет в вебсокеты емнип.

Вообще в питоне работа с асинхронщиной проще чем работа с тредами. В асинкио есть фичи которые оч сильно упрощают жизнь и ускоряют разработку, но на изучение придется потратить время.

redixin ★★★★ ()
Ответ на: комментарий от Turbid

Мне кажется, тебе надо отдельно замутить демон, который слушает железки и в примерно реальном времени обновляет, допустим, файл с данными, управляет камерами и т.п.
А веб-приложение шлёт ему команды и показывает данные.

Shadow ★★★★★ ()
Ответ на: комментарий от Shadow

А иначе никак.

Простой пример. Демон работает с железяками и вебсокетом.

В новом фотометре думаем в будущем вообще сделать прозрачное сетевое управление: разнородные железяки делятся на группы (HID управляются одним демоном, RS-232 - другим, ПЗС - третьим); у каждого из их демона открыт локальный (т.е. недоступный снаружи) сокет. Общий демон работает с ними и держит открытым наружу сокет+вебсокет, через которые происходит авторизация и управление. В итоге юзверь может на любой платформе (особые содомиты могут с «телефона») запустить управление железкой. Хоть в CLI, хоть в GUI.

anonymous ()
Ответ на: комментарий от Shadow

Вроде бы уже есть демон который видит железки через uart и показывает их через tcp.

На самом деле на том же пыхтоне можно и с /dev/ttyS* работать. Все в одном процессе через asyncio. Синхронизировать доступ к железкам через всякие asyncio.Lock/Semaphore/Condition. Хотя через tcp примерно то же самое получается.

А Эдика не слушайте, он дилетант.

redixin ★★★★ ()
Ответ на: комментарий от redixin

он дилетант

Однако, у меня все работает, в отличие от некоторых!

на том же пыхтоне можно и с /dev/ttyS* работать

Видел я, как черезжопно это делается! Иди, детсадовцев поучи в абдурине ковыряться. Как раз этот уровень!

anonymous ()
Ответ на: комментарий от Turbid

Разрешил жабоскрипт, говносайтег внезапно что-то показал. Срать им в руки!!! Вот же ублюдки, хоть бы надпись дали: «отключи noscript, чтобы что-то увидеть». Но нормальные люди делают статические сайты так, что там вообще нет жабоскрипта!

По девайсу: говно с жуткой ценой. Ты бы сам сделал на 1 порядок (десятичный, есличо) дешевле.

anonymous ()
Ответ на: комментарий от anonymous

Я это тебе не рекламирую и сам не покупал. Работаю с тем, что есть и никто менять не даст.

Плюс есть LCD-панели, в которых свой tcp-сервер.

Turbid ★★★★★ ()
Последнее исправление: Turbid (всего исправлений: 1)
Ответ на: комментарий от Turbid

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

redixin ★★★★ ()

И да, если ты не кодер то лучше в job, а иначе будешь мучаться как Эдик производя глючный говнокод и тратя на это неимоверно много времени.

redixin ★★★★ ()

для этого и был придуман MQTT, например.

менеджер подписывается на события клиентов (железок), железки подписываются на команды от менеджера в своих топиках. Дальше все логично шлется и разруливается.

И в идеале нет необходимости в непотребщине с низкоуровневой сетевой подсистемой.

zudwa ()
Ответ на: комментарий от redixin

Оказывается в Python завезли сахара для работы с асинхронными сокетами: https://docs.python.org/3/library/asyncio-protocol.html

Вот небольшой пример, который позволяет слушать одну из моих железок:

import asyncio
from binascii import hexlify


class ClientProtocol(asyncio.Protocol):
    def __init__(self, loop):
        self.loop = loop

    def connection_made(self, transport):
        print('Connected')

    def data_received(self, data):
        print(hexlify(data))

    def connection_lost(self, exc):
        print('The server closed the connection')
        print('Stop the event loop')
        self.loop.stop()


loop = asyncio.get_event_loop()
coro = loop.create_connection(lambda: ClientProtocol(loop),
                              '192.168.15.16', 10001)
loop.run_until_complete(coro)
loop.run_forever()
loop.close()
Turbid ★★★★★ ()
Последнее исправление: Turbid (всего исправлений: 2)