Николай, у любой живой библиотеки есть примеры, которые знающий соответствующий язык программист без проблем запустит. Совсем без знания программирования тут можно добиться успеха только чудом.
При такой постановке вопроса нельзя дать однозначный ответ.
Есть много способов. Например, можно выполнять служебные запросы с одного сайта на другой для передачи данных (в том числе и не в реальном времени, а время от времени передавать обновлённую статистику).
Можно настроить доступ одному сайту к базе данных другого. В том числе по сети, если они на разных серверах (для защиты взаимодействия лучше поднять между ними VPN). Можно вообще базу реплицировать.
В общем, тыжпрограммист, сделай хоть как-нибудь...
Безотносительно языка, полезно понимать общие идеи, которые стоят за этими подходами. Многопоточность - это когда "много потоков" - почти что отдельных процессов, но использующих общую память с основным, а асинхронность - когда поток-процесс всего один, но он выполняет разные задачи по очереди с переключениями в моменты ожиданий задачами ввода-вывода или результатов выполнения другой задачи/функции.
Когда у нас много ввода-вывода и мало процессорной работы, то асинхронность может быть очень эффективна, причём за счёт синтаксических конструкций (async/await) можно писать код очень удобно, наглядно и эффективно. Но любая вычислительная задача, любой синхронный код могут привести к заметным задержкам на выполнение других задач, это недостаток.
При этом асинхронная функция запускается быстро и дёшево, а запуск потока - это более сложная операция. Поэтому много коротких асинхронных функций это нормально, а много потоков с коротким временем жизни - нет. При многопоточности обычно или делят задачу на большие части, выполняющиеся в разных потоках, или разделяют по функционалу (например, GUI в одном потоке, вычислительные задачи в другом).
Ну а дальше начинаются вариации, которые в разных языках и фреймворках могут быть реализованы по-разному. Например, можно запустить несколько потоков и в каждом свой асинхронный цикл событий. Или асинхронные задачи распределять по пулу потоков, чтобы лучше утилизировать возможности многоядерных процессоров и уменьшить влияние синхронных кусков кода на задержки переключения задач.
Ксения Тимошенко, например, может через crontab или по вызову другой страницы (в том числе GET-запросом) восстанавливать и затем делать GET-запрос. Я бы посоветовал также проанализировать запросы с того же IP, что и сделал POST, возможно, будет сразу заметно, что именно делается. Также посмотреть cron на сервере (если это возможно) и возможно механизмы регулярных запусков задач в самом движке (я в WP не очень, не знаю, есть ли там такое).
Вообще, я сталкивался, что мошенники свои страницы засовывают, например, в свалку картинок в uploads, где их сложнее заметить. Если целенаправленно поискать там php-файлы, может оказаться, что вредонос быстро найдётся (и обязательно проверить содержание заглушечных index.php, которые должны быть именно заглушками). Кстати, неплохой идеей является настроить так, чтобы в каталогах, где не должно быть php-кода, файлы не выполнялись как код (но придётся повозиться с настройкой).
Ярослав, у меня у самого есть задача как-то красиво работать с данными, которые получаются, например, в виде json-структур, чтобы они прозрачно могли записываться в базу без написания кучи кода. Данные образуются при парсинге и архивации разных сайтов, и их структура очень разнообразна. Пока не смог придумать лёгкого и удобного решения. Для сайтов которые не меняются, можно данные сохранять как есть и грузить из них по необходимости, но бывает так, что данные могут удалять, а их нужно запомнить для истории (у данных есть уникальные ключи, которые позволят избежать дублирования). Придумал с помощью inflection конструировать объекты с полями на лету, а сами объекты описывать в peewee, но пока не получилось добиться работоспособности...
sqlalchemy вполне можно использовать как абстрактный интерфейс к базам данных, просто передавая в него строковые запросы.
А так, конечно, есть всякие https://github.com/web2py/pydal. да и в ORM-движках обычно есть средства замаппить ORM-объект в уже имеющиеся таблицы вместо создания их.
ENigma371, я бы посмотрел в сторону умеет ли он UUID или LABEL, потому что имя устройства, как я уже говорил, это ненадёжный идентификатор. В том числе и для физических дисков.
Весьма возможно, что работать не будет вообще. У меня в ИБП APC была проблема, я пытался его подключать через usb2serial и это приводило к немедленному выключению ИБП, потому что так нельзя у него делать. Но там есть и usb-порт и через apcupsd с ним можно взаимодействовать.
Надо ещё понимать, что реализации usb2serial обычно реализуют COM неполноценно, могут выдавать импульсы не той квадратуры итд итп. Я как-то пытался очень древний контроллер от конструктора LEGO подключать, он не детектился вообще или детектился и еле-еле шевелился. Прошить его так было вообще было нереально. При том, что с компьютера с полноценным COM-портом всё нормально работало.
renikrenik, наверное можно навернуть сценарий в asterisk и каким-то образом его запускать. Но я в нём разбираюсь слабо, хотя и приходилось когда-то конфигурировать немного.
ivan58, вопрос и правда очень неконкретный, трудно понять, что хочется узнать. Что такое АСУ или ТП? Определение можно найти в Википедии не только. Как делают АСУ ТП? Тоже в интернетах.
Сюда можно приходить с конкретными вопросами, которые легко не гуглятся или с которыми что-то непонятно, возникли затруднения, не удалось что-то настроить, запрограммировать... Можно посмотреть на другие вопросы (в том числе в упомянутых в вопросе тэгах) и станет понятно, о чём идёт речь.
Bermut, это делается так. Получаем AS (одну, две не надо), подключаем два провайдера и с каждым организуем BGP стык. Наша AS попадаел в BGP fullview и весь интернет начинает знать, что трафик до нашей AS можно роутить через этих двух операторов. Причём, как правило, роутиться трафик будет по условно "кратчайшему" пути.
Но это будет стоить достаточно дорого, далеко не 100 рублей в месяц, да и AS получить - это очень непростое дело. Дешевизна интернетов (даже с учётом часто заметно завышенных цен для юрлиц) - это следствие того, что это услуга массового спроса. Однако специфические требования при этом исполнит не каждый провайдер - да и небесплатно выйдет подобное удовольствие.
Поэтому так для уровня "мне достаточно /29" никто не делает ничего подобного. Обычно так делают для проектов совсем другого уровня сложности, причём чаще всего это делается в датацентре, не в офисе.
Например, у моего работодателя арендованные стойки в трёх датацентрах (причём намеренно от трёх разных операторов), между которыми проложена оптика, причём между некоторыми парами это по два независимых канала с разной непересекающейся трассой по городу. Соответственно, нужно оборудование, которое примет 10 Гбит/с на каждой площадке, и грамотный цискарь, который всё это настроит. Далее, у нас 3 провайдера, два на одной площадке, третий на другой, на третьей площадке ничего нет. С каждым из провайдеров BGP. В реальности на любую из площадок трафик может придти по любому из каналов - и дальше дойдёт уже по нашей внутренней сети.
Но у нас есть серьёзные причины для такого дорогого и сложного решения. А для пары серваков в офисе и пожеланий "до 100 рублей" это не вариант. Для такого имеет смысл решения другого класса, хотя и их простыми не назовёшь.
Заводим два провайдера и по каждому кидаем VPN до арендвоанного сервера/виртуалки. На этот сервер покупаем нужную сетку или набор IP, но только один приписываем серверу, остальные анонсируем статически в arp в сеть датацентра, а на серваке роутим в VPN. Тут надо обеспечить роутинг в любой из VPN, это проще всего метриками, но лучше поднять OSPF или даже BGP. На стороне сервера в офисе придётся нагородить policy routing. Так мы обеспечим, чтобы внешний IP, приписанный серверу, маршрутизировался поверх VPN (любого из) в датацентр, а в датацентре эти IP маршрутизируются уже поставщиком услуг.
Ну вот, а теперь нужно понять, что чаще всего даже это не нужно. На нашем сервере же будет крутиться что-то конкретное, на каких-то конкретных портах. И надо всего лишь выпустить в интернет эти порты. Так можно просто на серваке у хостера эти порты пробросить через VPN до сервера в офисе. И не светить весь сервер в интернет. Причём если не нужно видеть адрес подключающегося клиента, то можно проброс сделать с двойным nat и даже policy routing не потребуется.
Надеюсь, я убедил искать решение попроще и не заморачиваться слишком сильно :)
