Сервер. Хочу свой IoT сервер. Вот хочу, бля, и всё тут. Разберём вопрос?

То есть, обычный куйс для IoT сети - большое количество хабов с постоянно открытым соединением, но, при этом - низкая плотность данных. 100 пользователей не сожрут даже мегабит канала, и это если они все одновременно сойдут с ума, начнут нажимать все подряд кнопки со скоростью автомата, а также будет 10 раз в скеунду происходить смена времени суток, пожар, землетрясение, и двери станут самостоятельно хлопать.
Да это ж самый идеальный сценарий. Пейсателям всяких application-серверов такое даже в самых сладких снах не снится:)

Какую архитектуру посоветуешь для такого типа сети? Много постоянно открытых коннектов с низким/умеренным потоком данных.
Вот тут не понял - в смысле какую?
Думаю, тут все предельно просто, даже не нужны никакие пулы коннекшенов - число клиентов всегда +/- константа.
Все таки, как мне нравится эрланг/эликсир, насколько там это все элементарно и надежно работает. Шо значит, для телекома создавался.
 
Вот тут не понял - в смысле какую?
Ну, программные модули чисто схематически выразить можешь?
Что многопоточно, что многозадачно.
Нужно где-то хранить листенеры на каждый коннекшен. Чем будем обрабатывать мессаги?

Думаю, тут все предельно просто, даже не нужны никакие пулы коннекшенов - число клиентов всегда +/- константа.
Не вижу связи особой с этим. К примеру, из 1000 активных клиентов - взяло и 200 отвалилось, потому, что они через один канал выползали в интернет, а у магистрального провайдера что-то упало.
Потом провайдер переключится на резерв - и все 200 одновременно ломанутся открывать потерянный коннект.

Всё только на первый взгляд статично. Там всплески бывают, и бывают не редко.

Все таки, как мне нравится эрланг/эликсир, насколько там это все элементарно и надежно работает. Шо значит, для телекома создавался.
Ну так ты склонись уже куда-то :D
 
Не вижу связи особой с этим. К примеру, из 1000 активных клиентов - взяло и 200 отвалилось, потому, что они через один канал выползали в интернет, а у магистрального провайдера что-то упало.
Потом провайдер переключится на резерв - и все 200 одновременно ломанутся открывать потерянный коннект.

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

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

Ну, программные модули чисто схематически выразить можешь?
Что многопоточно, что многозадачно.
Нужно где-то хранить листенеры на каждый коннекшен. Чем будем обрабатывать мессаги?
Опять же зависит от выбора целевой платформы.
 
Опять же зависит от выбора целевой платформы.
Так ты ж сам сказал, что по учавствовал бы в этом на расте :D
Как-то уже покури... я топологию и адресацию пока курю. Зигби призвезденый немного со своими абстракциями, которых нет у других стандартов. Части фич аналоги найти можно, а части - нет.

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

Это, к стати, проблема совместимости, в зигбе достаточно серьёзная.
И, вот, я хочу, чтобы её небыло. Чтобы можно было включить "маскарад" для определённого девайса и сказать какой класс ему подставить.
В результате сервер / плагин к нему... кто-то ещё - должен былет заменять/дополнять во фрейме зигби для пакетов к/от девайса профиль на заданный.
И тогда дверным звонком можно будет отключить тебе аппарат искусственного дыхания :угу:

Ну, и, чтобы, к примеру, Z-Wave кнопка могла управлять Zigbee ... оконными жалюзями.

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

А ты покури, всё же, как праграмизд - как и на чём лучше делать сервак. Я, один хуй, из предложенного тобой - ни в чём не ковырялся. Если его буду писать я - он будет на C# с, возможно (и даже скорее всего) какими-то сторонними либами на С/С++

P.S. К стати, пробегал мимо статьи про сервера-миллионники на питоне :угу: Там тоже какая-то внешние либы, питон, как я понял - там чисто для организации бизнес-логики. То есть - при повышении вычислительной нагрузки на обработчик сообщения - вся эта ёбань начнёт дико тупить, хотя миллион коннектов держать будет :D
 
Мельком глянул на Twisted - вроде фреймворк полностью соответствует задаче. И это пайтон, то есть - легко встроить/дописать/подключить любую доработку.
Twisted лицензирован MIT
 
Про твистед много хорошего слышал, да и сам поверхностно ковырял 10+ лет назад.
Но питон:нудно:
 
Про твистед много хорошего слышал, да и сам поверхностно ковырял 10+ лет назад.
Но питон:нудно:

ХЗ, по крайней мере, в пайтоне я хоть что-то понимаю, и в отличие от Rust - его со старта значительно проще понять.
Но ты не отвлекайся! Так какую архитектуру сервера, на твой взгляд, будем реализовывать?

По сути - IoT сервер = чат-сервер. Висит докуя клиентов онлайн, держат коннект и нихуя не делают. Но когда настаёт новый год/катаклизьм/пятница/другое интересное событие - все рачинают шо ебанутые педалить друг другу посты и постить котиков.

What about scheme?
 
А хз.
Руки чешутся на эрланг/эликсир, есть чуйка, что оно заебись подойдет под это дело.
Раст - будет мега-кроссплатформенно и охуенно лоу-левел, но дохуя работы, а при отсутствии опыта надо пиздец скока времени убить.
В эрланге у тебя будет некий глобальный процесс, где ты можешь хранить что душе угодно, и пинать его через акторы, типа как в Скале.
Естественно, он тоже будет под супервайзором и не сможет сдохнуть ни при каком раскладе.
 
Блин, хочу поковырять эликсир, заодно освежить познания в эрланге, заодно может какие-то идеи появятся, но как на зло все на работе посыпалось, думаю как минимум неделю не судьба подступиться.
Даже пришлось свои личные поделки забросить.
 
Блин, хочу поковырять эликсир, заодно освежить познания в эрланге, заодно может какие-то идеи появятся, но как на зло все на работе посыпалось, думаю как минимум неделю не судьба подступиться.
Даже пришлось свои личные поделки забросить.

Ну, ты недельку по тупи - и выбери уже наконец, что ты хочешь по ковырять :D
Rust-ом я без твоего участия не буду пользоваться для этого - на 146%.
Я посмотрел, и понял - те, кто писал раст - ненавидят людей.

А идеи... идеи то фоновый процесс.
Никогда не видел в доках идеи сервера. А, вот, архитектура - вполне часто встречается.
Идея - 100500миллионов актичных коннекшенов+если все разом начнут плеваться и займут канал - чтобы не падал сервак. Пусть по таймауту валятся, если им хочется, но сервак должен стоять и обрабатывать что может.
Скорости я уже писал. Там хуйня, а не скорости передачи.
 
amazon в хату!

кто-то пробовал их прошивку на распбери притулить ? чтоб логика по местному обрабатывалась а потом с кладом синкалось ?
 
Хочу свой IoT сервер. Вот хочу, бля, и всё тут. Разберём вопрос?
Хотел уже подписаться, потом прочел и понял, что
что-то мне подсказывает что здесь уже начинается хуита.... по всем направлениям.
:)

Рекомендую всё-таки определится с целями, потом изучить суть, а потом уже заниматься прочей хуйней.
ЗЫ. Протоколы зигби\зетвейв ковырять смысла нет ваще, ибо они структурированы под иот.
ЗЫЫ. ХА (НА) на сегодняшний день самая продвинутая система интеграции, малинка там просто как самое простое и малошумящее.
ЗЫЫЫ когда ещё никто не пытался прикрутить интернет к умному дому уже тогда было два основных направления, вылившихся в клауд коннектед и директ коннектед.
 
Хотел уже подписаться, потом прочел и понял, что
:)
Хорошо, что хоть прочел.

Рекомендую всё-таки определится с целями, потом изучить суть, а потом уже заниматься прочей хуйней.
О, не прошло и пол-года, как в тему подтянулся иксперд" :D Иксперда сразу видно по одному факту - он первым делом сразу советует ТСу RTFM, не зная, чем ТС занимается и знаком ли он с темой.

ЗЫ. Протоколы зигби\зетвейв ковырять смысла нет ваще, ибо они структурированы под иот.
:рл:
Может мне лору туда прикрутить, ась?
вообще, речь о сервере, а не о консолях.

ЗЫЫ. ХА (НА) на сегодняшний день самая продвинутая система интеграции, малинка там просто как самое простое и малошумящее.
И накуя мне хоум ассистант?
Тема о собственной платформе.
И ХА - не самая лучшая и удобная. Пользовательские качества у алексы в разы выше.

ЗЫЫЫ когда ещё никто не пытался прикрутить интернет к умному дому уже тогда было два основных направления, вылившихся в клауд коннектед и директ коннектед.
И?
Я рад, что ты знаешь эти слова. А скахать-то что хотел?
 
И ХА - не самая лучшая и удобная.
Вообще нихуя не удобная ишо?
Пользовательские качества у алексы в разы выше.
Адекса-то тут причем?:незнаю:
вообще, речь о сервере, а не о консолях.
Я ж и пытаюсь понять, чего ты от сервера получить хочешь? Прикрутить дейтаграммы EIB к Тасмотовской ESP розетке?
 
Вообще нихуя не удобная ишо?
Ну и нахуй ті тогда её приплёл?

Адекса-то тут причем?:незнаю:
Ну просто, я подумал, что, собсно, по бэкэнду тебе сказать нечего и просто продолжил разговор. Давай вообще всё обсуждать :угу:


Я ж и пытаюсь понять, чего ты от сервера получить хочешь? Прикрутить дейтаграммы EIB к Тасмотовской ESP розетке?
Это опять не про сервер. Какое отношение имеет сервер к дэйтаграмам, которые рисует UI? Это интеграция называется. Если в БД есть нужные данные - можешь строить хоть диаграммы, хоть налоговые отчеты печатать.

От сервера требуется совсем другое. Ну... то, что от серверов обычно требуется.
Я специально подсказывать не буду :)
 
Пиздец нахуй :рл: Так ты просто поумствовать хочешь? ну так бы сразу и сказал.:D Удачи!

Просто поумствовать, походу, сюда ты заходил.

Сервер выполняет вполне определённые задачи:
1. Поддерживает соединение (в т.ч. защищённое)
2. Поддерживает авторизацию
3. Поддерживаетадресную доставку данных в обе стороны.

Собственно - это и есть минимальные требования к серверу. У сервера есть данные. Всё. Всё, у чего есть данные - сервер.
Причём тут хабы и протоколы - непонятно совершенно, это другая сторона сети.
Серверу допизды по какому из интерфейсов оконечные взаимодействуют с хабом - это проблемы хаба, звэйв/зигби/лора или ещё что-то. В идеальном варианте - сервер не должен об этом знать и ему похуй.

Собственно, что я хочу - я уже в стартпосте написал, там 2 пункта всего. Но можешь продолжать их игнорировать, это, на самом деле, ни чего не меняет :)
 
Назад
Зверху Знизу