На чем написать клиент/сервер

Ну возьми жаваскрипт и напиши просто. Никто же не заставляет использовать фреймворки. Вопрос не очень понятен.

С широковещательным адресом скорей всего будут проблемы у многих. Лучше всего использовать сервер в интернете.

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

Я бы rust попробовал для такой задачи.

Есть веб приложуха для телефона

Так она уже есть или только предполагается быть?

на чем сейчас просто написать клиент подходящий для меня под все виды мобилок?

Так если на клиентской стороне уже есть веб-приложение, то там по дефолту есть как минимум браузерные апишки для взаимодействия с серверами, самый простой из которых — HTTP-клиент. Если приложение обёрнуто в какую-нибудь Кордову, то там по идее должны быть и апишки, доступные для Node.js, включая сокеты.

хочется спихнуть все задачи по формированию страницы клиенту

для этого обычно используют «какое-нибудь rocket science хай энд веб дерьмо на монструозном фреймворке», но никто не мешает написать его самому :) Впрочем, для действительно простых страничек можно или написать простенькие скрипты, или использовать легковесную библиотечку для управления элементами страницы. Всё равно для красивого приложения в большей степени нужно написать разметку и стили, а логики, по идее, будет минимум. Но готовая веб-обёртка с поддержкой всяких сокетов всё равно порядка 100 мб будет весить.

В локальной сети через бродкасты(UPNP/SSDP), в интернете через облако, то есть через сервер в интернете

Так она уже есть или только предполагается быть?

Предполагается быть. По нему я не совсем ясно задачу сформулировал, наверное. Уточню - конечно у меня нет никакого желания писать его вокруг голого сокета, хочется заюзать веб браузер, по идее, что может быть проще? Смущает только вот что - вот сделал я какую-то страницу, но на ней имеется элемент, который изменяется во времени - возьмем для примера счетчик, который инкрементится девайсом и отображается в виде какой-нибудь текстовой метки на странице. Могу ли я обойтись простой html разметкой + как-то вшить в эту же разметку инструкцию браузеу перезагружать страницу раз в 4 секунды? Если нет, то как максимально просто реализовать такую веб страницу с счетчиком?

Так страницу необязательно перезагружать. Достаточно периодически делать HTTP-запрос к серверу, получать нужные данные и обновлять значения на странице. Тогда HTML и скрипт будут статическими — их не нужно будет генерировать каждый раз. Можно будет или зашить в мобильное приложение или отдавать HTTP-сервером в девайсе. Однако вопрос определения адреса сервера остаётся открытым.

Вот, это уже что-то оно. Т.е. я могу написать статическую html страницу с динамическими элементами внутри (счетчики, значение которых приходит извне) при помощи простой html разметки? Рядом со странцией молотит javascript скрипт, который общается с сервером и перезагружает странцу/обноволяет необходимые элементы на странице при необходимости. Я правильно понимаю? Мне будет достаточно так сказать базового JavaScript, без всяких дерьмо фреймворков, которыми славятся веб поделки?

PS: просто я никогда не писал «продвинутых» веб страниц совсем, максимум простенькие со статических контентом пару раз

С широковещательным адресом скорей всего будут проблемы у многих. Лучше всего использовать сервер в интернете.

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

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

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

Мне будет достаточно так сказать базового JavaScript, без всяких дерьмо фреймворков

Для данной задачи будет достаточно. В первом приближении:

const counter = document.getElementById('counter');

async function fetchData() {
    try {
        const response = await fetch('https://example.com/data');
        
        if (!response.ok) {
            const message = `An error has occured: ${response.status}`;
            throw new Error(message);
        }
        
        const data = await response.json();
        
        counter.textContent = data.counter;
    } catch (err) {
        console.error(err);
    } finally {
        setTimeout(fetchData, 5000);
    }
};

fetchData();

нужно закостылить на внешнем сервере в сети ресурс, куда юзер может зайти в личный кабинет и покрутить некоторые крутилки

Сервер можно писать на чём угодно. Веб-интерфейс админки — или отдельный на голом JS или фронтендном фреймворке, или реализованный на серверном фреймворке.

в перспективе прикрутить оплату, т.е. какой-то баланс для каждого аккаунта

Аппетиты растут :)

В готовых решениях я не силён. Я бы это делал на облачной платформе, это будет проще и дешевле всего, но у меня есть примерное понимание, как это делать. Могу посоветовать арендовать VPS-ку за 5 баксов где угодно и написать на Go простое серверное приложение со всей логикой. Данные хранить в postgres или sqlite, как кажется удобней. Тут будут проблемы со 100% доступностью, но наверное это не медицинский монитор и такое можно пережить.

С широковещательным адресом скорей всего будут проблемы у многих

Ещё интересно - а можно ли считать общепринятой договоренностью, что дефолтная локальная сеть домашних ширпотребных роутеров 192.168.1.0/24, и что dhcp даёт адреса от 192.168.1.100 и выше? И я смогу безопасно взять адрес какой-нибудь …1.90 для своего девайса, а если кто-то этот дефолт изменил под себя, то и статические адреса осилит. Из всех роутеров, что у меня были - данные предустановки соблюдались, но как там во всех палатах, а не в общем по больнице - хз. Можно ли на это положиться?

И ещё вопросик, не совсем по теме правда, но вы ведь всё знаете: какой бы 3д принтер взять для печати корпусов девайсов? Небольшая коробочка сантиметров 5. Нужен какой-то простенький дешевый принтер, рабочая лошадка, который сможет напечатать корпусов 20 за день. Или проще найти кого-то на стороне с более серьёзным принтером и не брать на себя всё?

Я бы rust попробовал для такой задачи.

Rust для клиента который на браузере вертится? Это как?

Ну я видел 192.168.0.0/24. Лично у меня сейчас 192.168.2.0/24, но это я сам уже настроил. По 100+ не скажу, никогда не интересовался, но очень сильно подозреваю, что и такой договорённости по дефолту у большинства нет.

Ты скажи, что ты хочешь сделать. Хочешь с телефона найти девайс в том же WiFi? Самый простой способ, который я бы рекомендовал - если сеть /24 то тупо по всем адресам на фиксированный порт отправить UDP-запрос, а девайс уже должен на этом порту ответить. Думаю, это сработает для подавляющего большинства типичных сетей и займёт немного времени.

если сеть /24 то тупо по всем адресам на фиксированный порт отправить UDP-запрос

Только, к сожалению, такой service discovery на чистом Web API не напишешь

c++/Qt

Хорошая идея, спасибо, в копилку. У меня сценарий такой: у юзера в локальной сети включен мой девайс, юзер сканирует qr код попадает на девайс, тот его редиректит на сайт в инете вместе с необходимой метаинфой. Долгая история почему всё именно так, это часть задумки, но адрес, на который попадает юзер после сканирования qr когда - должен быть фиксирован (QR код нельзя менять).

Смогу ли сделать так - юзер сканирует QR код, качает с моего сервера в инете какой-нибудь javascript, который уже в свою очередь находит необходимый адрес девайса и попадает на него?

PS: и да, я нельзя установить юзеру на телефон заранее какаую-нибудь приложуху, доступны только штатные средства (браузер), это как бы из развлекательной области все, и это должно быть неожиданным для «жертвы»

Проще всего найти на стороне, конечно. 3д принтер это адский геморрой, если ты рассчитываешь поставить его на стол и начать печатать, то ты зря рассчитываешь, с ним возни очень много, особенно с дешёвыми. С другой стороны со своим принтером в любом случае гораздо быстрей цикл «спроектировал-напечатал-исправил-напечатал». Корпус это вообще больной вопрос. Я бы советовал поискать на китайских сайтах готовые корпусы и использовать их, если получится. Это будет самый дешёвый вариант, а качество литого корпуса ни в какое сравнение не идёт с качеством напечатанного.

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

Не уверен точно, но краем уха слышал, что маршрутизаторы дефолтно их не пропускают

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

Или проще найти кого-то на стороне с более серьёзным принтером и не брать на себя всё?

Или поискать готовый корпус, что еще лучше, проще и дешевле. А если совсем никак - то ищите партнера, все вы не осилите. Я бы даже трассировку плат на профессионала возложил.

Только, к сожалению, такой service discovery на чистом Web API не напишешь

Почему? fetch("http://192.168.1.123:8080") должен сработать.

Рассмотри такой вариант.

У девайса есть id. Пусть 789123 для примера.

Девайс при получении IP-адреса на сервер отправляет его и свой идентификатор. Сервер это записывает в свою базу данных. Т.е. сервер знает, что у девайса 789123 в последний раз был IP-адрес 192.168.1.178.

В QR-коде закодирован адрес http://mycooldevice.com/go/789123.

Сервер при получении этого запроса выдаёт редирект на http://192.168.1.178.

В итоге юзер сканирует код, делает запрос на сервер и редиректом переходит на девайс. Всё происходит незаметно для него.

Альтернативно можно использовать dynamic dns. Девайсу присваивается адрес 789123.mycooldevice.com. Этот адрес закодирован в QR-коде. Далее всё примерно как в предыдущем варианте. При старте девайс связывается с сервером, сообщает ему свой локальный адрес, сервер перенастравивает DNS-записи, таким образом всё уже идёт без редиректов, через DNS. Но мне этот вариант нравится меньше, не люблю DNS.

1. https://yew.rs/
2. https://tauri.app/
3. https://dev.to/stevepryde/create-a-desktop-app-in-rust-using-tauri-and-yew-2bhe

Всё дело в том, что QR код одинаков у всех клиентов, т.е. у Васи и Ивана. Все они будут получать не только девайс, но и целое «кино», куда вшит QR код. Я просто не хочу генерить для каждого свою версию, + это надо будет держать видики для всех клиентов у себя на сервере, чего не хочется, проще отправить всех на условный ютуб, а дальше уже у каждого свой сценарий, в зависимости от метаинфы, которая вшита в девайс

Понятно. Ну тогда только discovery каким-то образом.

Да, это должно сработать. Например, страничку роутера на 192.168.1.1 находит, но иногда такой запрос залипает на некоторых адресах, ожидая ответа. Например, у меня он подвисает на 192.168.1.2. Если отправлять запросы строго последовательно, то пользователь может не дождаться ответа. Либо же нужно чуть усложнить код и рубить запрос по небольшому таймауту. Если же попытаться отправить 255 запросов одновременно, то браузер их всё равно поставит в очередь. Ну и это всё-таки HTTP over TCP, а не дешёвый UDP.

У меня так роутер кинетик себя вёл. И когда сеть была недоступна, я тупо не мог попасть в административную панель. Ох, как я был зол:)

Смогу ли сделать так - юзер сканирует QR код, качает с моего сервера в инете какой-нибудь javascript, который уже в свою очередь находит необходимый адрес девайса и попадает на него?

В целом да: страничка в интернете запустит описанный выше HTTP-discovery по /24, найдёт девайс и сможет открыть его страничку или просто обращаться к его API.

Благодарю за ответы. В целом некоторые моменты прояснил, надеюсь, что получится без проблем особых закостылить девайс discovery.

Конечно меня несколько пугает перспектива писать продвинуты сайт в сети и прикрутить к нему оплату, подозреваю, что говно там поесть придется знатно. Беда ещё в том, что мне веб программирование вообще не заходит, не люблю совсем, разбираться не хочется в нём

Оплата сейчас прикручивается довольно просто, например, если в России — через ЮКассу: https://yookassa.ru/developers/payment-acceptance/getting-started/quick-start Нужно будет для юзера зафиксировать id платежа, а затем начислить на его баланс деньги, когда платёж перейдёт в статус succeeded (проще всего поставив вебхук на событие успешного платежа, но можно и самостоятельно статус дёргать).

По сути на сервере понадобятся: публичные страницы с рассказом о девайсе (могут быть отдельно на любой CMS), страница регистрации, страница логина, страница(ы) личного кабинета, страница управления девайсом, страницы админки, эндпоинт возврата из платёжного сервиса, эндпоинт вебхука уведомлений, эндпоинт для девайса. Всё это можно реализовать на любой серверной технологии, даже по-старинке на отдельных php-страницах.

Беда ещё в том, что мне веб программирование вообще не заходит, не люблю совсем, разбираться не хочется в нём

Если есть возможность, то пиши ТЗ и отдавай на проверенный аутсорц, экспертизу решения тоже на аутсорц (если есть кому конечно). Выиграешь время.

Я не понял, а нужен ли тут вообще tcp/ip? Мож bluetooth хватит?

Мож bluetooth хватит?

Для этого придётся писать мобильное приложение. У Web Bluetooth API поддержка не очень хорошая.

А я могу из javascript узнать адрес и маску интерфейса, который привязан на wifi карту? На мобиле ведь их несколько, запросы нужно делать в локалку, а там wifi, а не та карта, которая торчит в опсоса

А я могу из javascript узнать адрес и маску интерфейса, который привязан на wifi карту?

Нельзя, в этом-то и прикол. Только подразумевать 192.168.1.* и проходить в цикле.

Засада какая-то. Не хотел заставлять юзеров, но похоже придётся писать отдельную полноценную софтину и накатывать её на телефон при сканировании qr. Тут qt советовали, на них, наверное, и закостылю.

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

Под iOS придётся разбираться с публикацией

С широковещательным адресом скорей всего будут проблемы у многих.

А почему так думаешь? Как же всякие SSDP протоколы на широковещательных запросах? Винде, так понимаю, сервисы на этой основе глубоко сидят (видимо, всякие сетевые принтеры и тп), неужели какой-то роутер захочет поломать функционирование массы вин десктопов? Или есть какие-то «безопасные» широковещательные адреса и желательно мимикрировать под условный SSDP, а не 255.255.255.255?

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

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

Ребят, ещё по поводу app stora’a и google play’a - нужно сделать оплату для размещения своих поделок. Сам из РФ, попросить заграницей есть кого сделать платёж, но не станет проблемой то, что девайс (айфон например) зареган на первое имя, у меня имя второе, а имя плательщика третье?

Просто по опыту с другими сервисами - сильно натрахался, где от несовпадений местоположение ip/имя плательщика/имя регистранта/местоположение банка отправляют в секс-тур в лес

Полезная ссылка, даёт представление о дефолтных сетях в роутера. Наверное, попробую обойти их с javascript’a, если удастся сделать это за какое-то адекватное время (секунд 5 хотя бы), то меня это устроит. Бороться ещё и со сторами, искать лазейки для оплаты, регать карты заграницей (уже одна полумертвая из Турции валяется) - мне вообще не хочется

Кстати, тут вопрос - вот все знают, что 192.168.1.0/24 - приватная сеть, и роутер не должен форвардить запросы на эти адреса во внешнюю сеть.

А что это значит? В роутере где-то в прошивке стоит запрет на переправку таких пакетов, или это программно сделано? Это работает благодаря таблице маршрутизации? Т.е. если там имеется запись вида

192.168.1.0/24 dev enp4s0f0 proto kernel scope link src 192.168.1.100

то, очевидно, нет смысла слать пакеты на шлюз, которые имееют получателя 192.168.1.50, они будут отпавлены на более подходящий интерфейс. Но эта запись в таблице появилась благодаря тому, что интерфейсу был этот адрес назначен, но там нет слова о сети 192.168.0.0/24. И если я буду слать запросы на 192.168.0.50, то это пойдет через default gate?

А что если я хочу построить приватную сеть из нескольких маршрутизаторов в её топологии? Маршрутизаторы ведь надо как-то должны будут пропускать пакеты в wan

Все что не подходит идёт в default.

Там только бондинг косячный, если нужен. Понадобится через систему делать. А так норм, если RPC поверх GATT навалять.

Мобильный Safari не поддерживает

https://github.com/puzrin/reflow_micro тут посмотри. Тоже прикидывал, как юзерам без пердолинга коннектиться к девайсу. Решил что из вебни по bluetooth сподручнее.

Приложуха на vuejs + typescript. Общие структуры через protobuf генерятся, чтобы с рассинхроном не вляпываться. Поверх GATT запилен RPC.

А никто кроме хрома не поддерживает. Ну тут такое - либо загнать юзеров в хром (такое они в состоянии осилить), либо взваливать на себя пердолинг по ведению и публикации приложений.

Наверное можно комбо - по блютусу и вафле одновременно, на выбор. И даже по USB :).