rPman

web api на запись файлов и перезапуск служб.

уверен что для этого нужно использовать СИ?

в мире web бакэнда очень большую популярность имеет php - кроссплатформенный (идет по дефолту со всеми дистрибутивами, собран и поддерживается подо все платформы), самый быстрый интерпретируемый (буквально после 7-ой версии с ним сравнится только nodejs и то при условии кучи ограничений и за счет встроенной асинхронности), самый быстрый по разработке (особенно не сложных приложений и скриптов)

теперь ложка дегтя

перезапуск служб

это вообще не про язык программирования, и способ зависит от выбора операционной системы и даже ее версии

Скорее всего будешь запускать что то типа sudo service служба restart, само собой, настроив права доступа на запуск

p.s. на самом деле истиной кроссплатформенности мало какая платформа даст, везде свои нюансы, например то что работает на linux в php, в windows не всегда заработает (например работа с пайпами, posix и куча плагинов), и выбор другого языка может не решить проблемы, тут вон предлагают java, исходники на нем многословные а привязка к операционной системе и железу там тоже присутствует, хоть и менее выраженная но все же попадается.

Могу предположить что это баг телеграм (сам не смотрю видео из него, неудобно), чтобы смартфон не выключался приложение должно сообщенить об этом ОС, отсюда и теория что последние обновления теперь так не делают.

проведи тест, настрой в смартфоне отключение экрана через 30 секунд и запусти видео из telegram и каким-нибудь просмотрщиков android (штатно гугловская галерея) и в догонку - браузер

upd. способ настройки блокировки экрана при бездействии в android изменился (его тупо нет на последних версиях, включается в оптимизации питания), только что проверил, официальный телеграм не отключается при просмотре видео но отключается если просто открыто приложение.

Правильно - настроить vlan на роутере, выделив для компьютера отдельную локальную сеть. не все роутеры это поддерживают. В этом случае сменой конфигурации или переустановкой ОС на компьютере выйти из 'сетевой песочницы' не получится.

Еще вариант, настроить фаервол на машине, закрыв доступ ко всем машинам локальной сети кроме роутера... в зависимости от операционной системы способы настройки отличаются. По уму для данной задачи штатного фаервола как win так и linux будет достаточно

Добавить фильтр по времени так чтобы результаты были в пределах лимита и по очереди меняй дату пока не переберешь все

ЗЫ во первых количество результатов сильно приблизительное, в реальности сильно меньше, во вторых перебирать все, если данных много вручную не реально, а за ботов Гугл бранит, когда-то ip-шники подсетками брали на это дело...

Одно слово - wifi

Обеспечить стабильную связь с помощью этой технологии можно только 'в пустыне', иначе любой проезжающий мимо тебя водитель со смартфоном, раздающим wifi например на планшет обеспечит нестабильность (на самом деле есть 100500 причин в нестабильностях, это просто одна из понятных)

p.s. понятно что по уму нужно провести исследование, запустить сканер к примеру mtr и смотреть его статистику (он покажет где именно возникают потери, хотя и не 100% гарантия)

Сам apk это zip архив, есть декомпиляторы, получить полностью рабочий исходный код обычно не получится но поковыряться в логике и файлах приложения могут помочь

Получить доступ к данным работающего приложения без root нельзя, теоритически это можно сделать с помощью резервного копирования (сам механизм создания копии локально работает, там будет зашифрованный паролем пользователя tar архив, но восстановить ее уже не получится, android сломан гуглом специально уже почти 10 лет как, но сами данные доступны), но только если разработчики приложения не запретили это в принципе (тогда остается только рут доступ на устройстве)

p.s. на сколько я знаю эмуляторы не ограничивают доступ к данным, по этой причине приложения, которые желают защитить данные, на эмуляторах не запускаются да и рут пытаются контролировать

У вас должны быть какие то механизмы развертывания сайта на проде, не важно какие, хоть скрипты, хоть ansible, главное не вручную! Причем такие скрипты должны различать установку с нуля и обновление (обновление - отдельный разговор, к сожалению красиво и универсально с базами данных не получится, но стараться нужно, чтобы иметь повторяемость и тестируемость и получать хоть какие то гарантии того что процесс обновления ничего не сломает)

Мне нравится способ создания тестового окружения через снапшоты и репликацию...
Файлы могут попадать простым копирование (развертывание архива, rsync, набор патчей и т.п.) а база данных через поддержание онлайн реплики master->slave, на машине, где можно временно остановить slave реплику, снять снапшот с файловой системы или всей машины (например виртуализация), и поднять копию параллельно в другой сети (виртуальные машины очень красиво позволяют все это разрулить с автоматизацией).

Этот подход позволяет поднять тестовое окружение с текущей базой данных за минуты, вне зависимости от ее размера (хоть терабайты), время развертывания скорее зависит от того как долго будет останавливаться реплика (ожидание завершения текущих операций записи)

p.s. во время развертывания обновления, обычно сильно затрагивающего базы данных, советую держать 'рядом' предыдущую версию с возможностью оперативно откатиться, нервов и времени сбережете очень много

Все так, коллизия маловероятна.

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

Просто подумай, не сломается ли у тебя ничего в твоей логике, если злоумышленник такое провернет

И причем тут эластик?

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

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

Ну и само собой демон или много, берут задачи из списка воркера и ищут.

Есть старый подход к созданию web приложений на php, которому обычно учатся начинающие (я надеюсь) который подразумевает следующее - любое действие пользователя на странице отправляется на сервер запросом и о в ответ возвращает НОВУЮ страницу с новым содержимым, 'по счастливой случайности' являющейся точной копией предыдущей кроме ну например появляется div элемент с нужным содержанием.

Реализуется это следующим образом - php файл это программа, которая генерирует все формы страницы, которые могли бы быть (может быть много разных php файлов, обычно разделяемых по смыслу, например разные разделы сайта), а url в браузере (адрес этой страницы) описывает как именно нужно генерировать страницу, на практике это реализуется http GET параметрами в формате:

http://site.com/cool_prog.php?param=value&other_param=other_value

в php программе список этих параметров хранится в переменной $_GET в виде массива (кстати там возможны параметры массивы с именами типа param[]=value1&param[]=value2)

Отсюда при нажатии на кнопку у тебя должна открываться к примеру страница
http://site.com/cool_prog.php?show_div=
а в коде php, где нужно вставить какой то кусок html проверка

<?php if(isset($_GET['show_div'])) { ?>
<div>yooo!</div>
<?php } ?>

Само собой способов передать состояние приложения много, так же с помощью настроек веб сервера (у apache к примеру это .htaccess модуль mod_rewrite) можно подменить часть некрасивых к примеру &category=value на приятные глазу https://site.com/value/

Повторюсь - это устаревший подход и использовать его нужно только если есть потребность в создани веб приложения для машин, не поддерживающих javascript (такие приложения создают сильную нагрузку на сетевой трафик и сервер но зато никой нагрузки и никаких требований для клиентов)

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

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

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

Самое верное, реализовать свое приложение не как http rest архитектура (где каждый запрос это запуск приложения которое собирает заново свое состояние из базы данных или других мест) а как приложение и есть веб сервер, где между разными запросами оно не закрывается а значит память не очищается и состояние приложения остается постоянным. В этом случае http и websocket запросы будут идти к одному и тому же приложению, а если все изменения в данных происходят через веб, то нет нужды даже периодически перечитывать базу данных, ведь момент изменения нужных данных можно отловить и в этот же момент инициировать отсылку нужным клиентам данных.

Этот подход наиболее эффективный по всем параметрам, на порядок или даже два быстрее чем http rest (с оговорками, существуют способы ускорить его за счет рядя ограничений и нагромождений на стороне сервера), эффективный по памяти, меньше нагрузка на базу данных и прочее прочее, за счет того что все приложение крутится в пределах буквально одного приложения (некоторые даже в пределах одного потока остаются, используя асинхронные методы работы с файлами, базой, сетью).

К сожалению недостаток напрямую вытекает из этого свойства - масштабировать такое приложение тяжело. Если http rest масштабируется чуть ли не из коробки, даже почти не затрагивая приложение только со стороны администрирования продукта (накидываешь серверов, реплики базы, кеши и т.п.) то тут придется сильно менять приложение и подгонять его к работе в кластере.

Единственное скажу что 'эти проблемы' у подхода начинаются с десятков и сотен тысяч пользователей.

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

Универсального инструмента нет, но в частных случаях можно написать приложение, использующее headless браузер и какое то закодированное условие окончания загрузки (таймаут например) и формат, в котором сохранять страницу (например картинка, или pdf, или html дамп,..)
p.s. когда то давно я писал приложение на visual studio .net c# использующее стандартный компонент WebBrowser (это древний internet explorer, поддерживается до сих пор), так вот при запуске его в linux mono, подставляется headless firefox

приложение это выглядело как форма, на которую кидаешь компоненту браузера, дальше 1 строчка прописать адрес странице, еще пара строк на регистрацию колбека на окончание загрузки, и пара строк сохранения,... приложение пишется за 2 минуты