Благодарю за советы, но тема с роутером мне кажется может быть не совсем стабильной. К тому же, к моему WIFI-роутеру кроме нужного ПК, подключены еще несколько ПК и устройств. Это не будет помехой?
А что если задействовать что-то типа базы данных на общем веб-сервере или на хостинге, где установлен сам сайт?
ПК и веб страница будут записывать команды на сервер каждую 0.1 сек и брать инфу оттуда же (обмениваться командами).
Так получится? Разве не проще?
А не опасно такое разрешать всем желающим из всемирной сети? 
Как я понял авторизации нет раз только HTML.
Нет, если только к одному надо обращаться.
Да, так проще.
Тут важнее даже не БД, а скрипт на сервере сайта (на PHP, например), который будет куда-то писать данные (команды) и по другому запросу (например, при запросе к http://мойсайт.ru/commands.php) отдавать их.
То есть кнопка на сайте вызывает скрипт для записи команды, а программа на ПК каждые 0.1 сек обращается ко второму скрипту для проверки наличия новых команд.
Авторизация есть и онлайн модерация/контроль тоже.
Команды должны находиться в БД в зашифрованном виде, чтобы их мог давать только тот юзер, у кого в данный момент имеется доступ к кнопкам. Или же для каждой сессии создавать временный скрытый раздел с рандомным именем, типа:
http://мойсайт.ru/command853983834573998893384.php)
http://мойсайт.ru/command256869697897954937273.php)
http://мойсайт.ru/command494874758374747577611.php)
и т.д.
Разве не существует уже готовых решений со скриптами?
А то мне кажется, мы тут вел сейчас пытаемся сконструировать))
Ну так это уже тогда не “немного HTML” )
к БД не должно быть доступа извне напрямую, только у скриптов на том же сервере сайта.
Тогда можно в скриптах просто проверять авторизацию стандартными способами через сессию (куки) как на любом сайте.
У команды писать чья она и в скрипте сравнивать с данными из сессии.
Для ПК особый админский юзер с доступом ко всем командам.
Вполне возможно, что нет. Это же не типовая задача типа сделать интернет-магазин.
Alex P., пасибо за внимание. Пока что буду искать готовые бесплатные решения, но если кто-то изъявит желание написать скриптик, пишите мне пожалуйста личные сообщения, обсудим цены и т.д. Дорого не потяну, спешки нет.
А от дельных советов в данной теме, конечно же, не откажусь))
Если имеется ввиду взаимодействие между desktop-приложением и веб-сайтом в реальном времени, то один из самых простых способов - использовать вебсокеты. Node.js является одним из самых простых решений, потому что есть бесплатный Heroku. Библиотеку socket.io, которая является обёрткой над WebSockets и упрощает работу с вебсокетами. На стороне клиента один из самых простых вариантов сделать Desktop приложение на C#, в котором есть поддержка вебсокетов из коробки, а для его большего упрощения можно взять реализацию socket.io для C# в виде пакета, который устанавливается через NuGet: Создание простейшего чата с клиентом на консольном C# и с сервером на Node.js/socket.io/JavaScript. Бонус - WPF-клиент
Getting Started on Heroku with Node.js | Heroku Dev Center - это официальная пошаговая инструкция, как разворачивать сервер на Heroku. Если не знакомы с Node.js, то можно начать с этого замечательного руководства: Руководство по Node.js - METANIT.COM Если не знакомы с C#, то можете стартовать на том же Metanit: Язык программирования C# и платформа .NET - METANIT
1 лайк
Это же скорее оптимизация для случаев когда не хватает обычного HTTP.
Типа чата с кучей участников.
Если просто иногда отправлять команды, то думаю не стоит париться, по-моему это наоборот сложнее будет, чем просто HTTP сервер и клиент.
Вот здесь написано, что нужно моментально взаимодействие между EXE и сервером:
Если нужно будет двустороннее взаимодействие, то самый быстрый способ - вебсокеты, но с вебсокетами напрямую работать сложнее, чем с помощью socket.io, тем более, что для C# есть пакеты для работы с socket.io. На самом деле socket.io на стороне клиента и сервера очень сильно упрощает взаимодействие. Нужно знать только: emit() и broadcast() и функции обратного вызова. У этого способа есть намного больший потенциал для развития приложения. Моё дело предложить, а будет ли автор темы его использовать - это его дело.
думаю для
0.1 сек (или даже пару сек) задержки не так критично.
С вебсокетами автору все равно нужен HTTP сервер, БД для авторизации и т.п., а не одни вебсокеты.
Я бы всё равно делал на C#, Node.js и socket.io. На бесплатном Heroku есть базы данных. На Node.js можно сделать HTTP сервер. А на сокетах можно развивать даже это приложение интереснее, чем просто HTTP. Можно даже чат очень просто реализовать. На официальном сайте есть пример готового чата в качестве вводного туториала: https://socket.io/get-started/chat/
Иван, благодарю за интересные мысли. Вот это мне и нужно было - побольше инфы с разжевывнием и конкретными ссылками для дальнейшего изучения.
Вот только я хочу реализовать все прямо на странице сайта. Изначально была задумка написать приложение для Android/iOS, но это дополнительная делюга - скачать и установить програмку, тем более мало кто любит скачивать и устанавливать себе всякие приложения…
Подскажи, из того что ты написал выше, это все относится только к приложению или что-то оттуда можно использовать для реализации процесса прямо на странице сайта?
(чат не нужен).
Чат - это просто учебный пример. Как раз на нём показано, как обмениваться сообщениями между клиентом и сервером (или между клиентами через сервер). В этом вводном туториале показан сервер на Node.js, а клиент в виде веб-клиента: https://socket.io/get-started/chat/ Веб-клиент пишется один раз и он будет запускаться на всех ОС, платформах (desktop, mobile) в один клик. Делайте, как вам проще. Если не хотите изучать Node.js, то продолжайте делать на PHP. Я изучал PHP когда-то давно, а теперь изучаю Node.js и лично мне Node.js кажется намного проще и мне он больше нравится. О вкусах не спорят, просто лично мнение.
Я все же пока больше склоняюсь к PHP. Хочется как всегда быстрее, проще и доступнее, а Node.js, C# и socket.io - для меня абсолютно темный лес, из которого чтобы мне выбраться придется потратить не один месяц…
Посоветуйте, с чего мне начать, для реализации на PHP?
Я выше описывал приблизительную схему с обменом инфой на сервере, как я это представляю, но на деле я не в курсе, из каких конкретно компонентов все должно состоять и как обычно подобные схемы работают.
Нужна ли база данных для обмена командами? Если да, то какую лучше использовать?
Сокеты, как я понял, для PHP не подойдут? Только для приложения?
Любую, MySql, Postgre, …
Через PDO код почти одинаковый.
http://getjump.github.io/ru-php-the-right-way/#базы_данных
https://phpbestpractices.org/#mysql
http://phpfaq.ru/newbie/na_tanke
в той схеме да, но она видимо нужна и для
чтобы пользователей хранить, выводить команды модераторам.
Для самого обмена хватит просто двух скриптов и БД, как я выше писал. Ну и программа на любом языке (C#, …) с любым HTTP клиентом на ПК.
Но раз нужна авторизация, модерация и т.д., то видимо всё не так просто, и скорее всего для сайта лучше взять фреймворк типа Laravel. Он упрощает многое, сложнее сделать что-то плохо/не безопасно. Например, авторизация там уже готова.
Там хорошая документация https://laravel.com/docs/6.x и видео-уроки https://laracasts.com/series/laravel-6-from-scratch, но на английском, не знаю есть ли что-то хорошее на русском (в курсах Хекслета есть немного по нему, но это наверно не самый простой вариант чтобы просто сделать, а не становиться проф. программистом).
Хостинг — упомянутый тут Heroku проще всего: не надо самому настраивать VPS, но и не имеет недостатков shared хостингов. И даже бесплатно если мало нагрузки (но если не хватит бесплатного, то дороже других вариантов).
Разворачивать туда сайт на Ларавеле примерно так: https://github.com/AlexP11223/CatToDo#heroku-deployment
Не читал всю тему.
Могу предложить использовать почтовый клиент. Например, MS Oulook можно настроить таким образом, чтобы он при получении письма выполнил некую команду.
А письмо это отправить с сайта на заданный адрес.
Задержка большая будет, автор вроде бы хотел как можно меньше. Пока дойдет, пока клиент увидит.
Хотя для второго в IMAP вроде есть фичи/расширения типа IDLE, Push, если поддерживаются сервером и клиентом.
Сокеты можно использовать не только для Desktop-приложений, но и для Web-приложений. Сокеты для Web-приложений называются вебсокетами. Я почти уверен, что в PHP тоже реализовали вебсокеты, просто погуглите, например: php websocket
Но вопрос в том, горите ли вы желанием изучать работу с сокетами. Это наложит определённый архитектурный опечаток на ваш проект. Если нет желания учиться работать с сокетами, то и не нужно в это лезть. Вы можете прекрасно без них обходиться.
Это ж разные вещи. Вебсокеты это протокол, а сокеты в API ОС и т.п. это просто низкоуровневая абстракция для отправки данных по сети (поверх нее можно например реализовать HTTP, или вебсокеты).
В случае с вебсокетами, непонятно что автор имел в виду под “приложением”.
Нужен сервер (для PHP тоже есть реализации http://socketo.me/docs/hello-world), а клиентами могут быть хоть браузеры, хоть десктопные приложения (по сути упрощенный браузер). Так же как и для HTTP.
Я бы в сторону веб-сокетов смотрел только если обычного HTTP не хватило по каким-то причинам. Тут же вряд ли сотни клиентов одновременно, да и задержка даже секунду (думаю будет меньше) скорее всего не критична для принтера.
Я имею ввиду, что с точки зрения программиста, который занимается разработкой клиент-серверных приложений на сокетах нет разницы, как внутри реализованы сокеты. При использовании чистых вебсотеков, сокетов на C# или WinSock на C++, или же через обёртки, например, socket.io - это всё равно. Сокеты - это просто API для обмена данными между desktop- веб-приложениями и сервером. Понятно, что, например, socket.io может вообще использовать HTTP если, например, нет реализации вебсокетов на данном браузере на мобильном телефоне.
Если человек с чем-то какое-то время не работал, то он это забывает и ему приходится изучать с нуля. Если человеку нравится работать с сокетами, то он найдёт возможность их применить и сделать приложение более интереснее. Например, он может добавить общий и приватный чат на своём сайте. Может сделать, чтобы список пользователей отображался в реальном времени. Например, справа отобразить список пользователей, кто сейчас онлайн и можно кликом открыть окно чата. Это больше зависит, чем человек интересуется, что он хочет поддерживать и развивать. Если человек поставит себе цель разрабатывать приложения вообще без сокетов, то он может это реализовать, а если он наоборот хочет развиваться и не забывать как с ними работать, то он будет искать, как сделать приложение интереснее за счёт вебсокетов.
Я связываю контекст с его первым сообщением, где он написал, что сервер у него на PHP, а клиента он хочет написать в видео приложения для Window 7. Потом он написал, что возможно пересмотрит свою позицию, потому что есть сложности с созданием приложений-клиентов для разных платформ, поэтому веб-клиент предпочтительнее. А вообще, конечно, зря я написал, потому что сбил автора с панталыки. Он спрашивает, есть ли реализация сокетов на PHP, а сам не стал даже гуглить. Я ему скидывал ссылки, а он не по какой даже ниразу не перешёл. Совершенно зря я потратил время. Моё решение о взаимодействии ПК и веб-сайта на Node.js через обёртку над вебсокетами я считаю вполне удачной. Приходится тратить время, чтобы доказывать очевидные вещи. Поэтому я постепенно перестаю общаться на форумах (особенно на русскоязычных, потому что на англоязычных такого практически нет). Надо использовать свои решения, которые выстраданы, а не уговаривать и не переубеждать других, как проще, быстрее и приятнее, тратя драгоценное время, которое можно было потратить на отработку знаний на практике.