Сервер команд

Советую для начала выпилить телеметрию.

Телеметрию он может отсылать по команде, а может в случае нештатных ситуаций и почаще. Еще советский конструктор Черток завещал, что телеметрия это святое.

Посылать подтверждение на землю после успешного выполнения команды?

Надеюсь, это не в продакшн, так сказать, пойдет? Или вы там опять глонасс запускаете?

вы там опять глонасс запускаете?

Бери выше. Сириус-Грунт.

Я думаю тут задача немного шире, посылать сообщение после принятия команды к исполнению. Если нам например надо 5 команд переслать, что бы знать, что 1,2,3 уже приняты, а во время 4 и 5 произошел сбой.

С чего подступиться, как подойти к задаче.

Посмотри на мессенджеры, в частности - уведомление о доставке и о прочтении адресатом сообщения. Всё уже придумано до тебя.

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

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

А что сложного в реализации такой логики, что прям надо копипиздить код?

Если нам например надо 5 команд переслать, что бы знать, что 1,2,3 уже приняты

Подтверждения вроде как должны решать эту проблему. Правда, они сами могут потеряться. Или нет?

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

с некоторых пор пишу (ще не готово) демона который на основании ответов вызываемых внешних скриптов или бинарей вызывает другие внешние скрипты или бинари. оно?

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

Похоже, на то.

врод xml-rpc подхода или там еще очереди сообщений

Ну ты мешаешь тёплое и мягкое.

Рассмотри логику брокера сообщений:

• есть сервер, и есть клиенты - спутники, звездолёты и ЦУП;
• клиенты, которые спутники и звездолёты постоянно шлют телеметрию, причём им не важно дошла она до адресата или нет;
• клиент ЦУП подписан на на конкретный спутник или на все и соответственно получает телеметрию, что он ней дальше делает уже не важно;
• ЦУП анализируя телеметрию шлёт команды спутникам;
• в свою очередь спутники подписаны на ЦУП и каждый получает свою команду и в сообщении телеметрии отражает результат её выполнения.

upd. Всё общение идёт через сервер, а не на прямую «ЦУП-спутник». Т.е. «стандартный» pub/sub.

на самом деле цэ система мониторинга, поищи срели существующих, можт подойдет

В общем:

• https://ru.wikipedia.org/wiki/%D0%98%D0%B7%D0%B4%D0%B0%D1%82%D0%B5%D0%BB%D1%8C-%D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA_(%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)#%D0%A2%D0%BE%D0%BF%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F
• https://ru.wikipedia.org/wiki/Data_Distribution_Service

ну ты и хренакнул...

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

Алгоритмы консенсуса в распределённых системах.

С чего подступиться, как подойти к задаче.

Начать читать отсюда: https://en.wikipedia.org/wiki/Consensus_algorithm

Не, конечно можно было бы сразу написать «mqtt», или даже «редис»… Но с ссылками на вики интереснее.

Где там консенсус? Там idempotent receiver и только

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

Я так понял, если использую протокол AMQP с брокерами-подписчиками и прочим мне надо еще этот компонент на сервер управления накатывать?

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

Ну вот я сейчас поисследую немного, просто на хабре нашел статью, https://habr.com/ru/post/149694/ Даже не знаю, это сейчас используется? Потом буду смотреть про консенсунс. Я так понимаю, есть уже написанные сервера протокола AMQP и их надо на машину накатывать, что бы можно было с ними работать?

Я так понимаю, есть уже написанные сервера протокола AMQP и их надо на машину накатывать, что бы можно было с ними работать?

Там есть на эту тему комментарий: https://habr.com/ru/post/149694/#comment_20197412

про консенсунс

Как выше уже говорил Begemoth, консенсус это оверкил в данной ситуации.

подтверждения получения

получатель этого подтверждения должен быть идемпотентным и всё

статус выполнения, ту же телеметрию

это вообще может доставляться at-most-once. Другой вопрос, что API должен проектироваться для предоставления атомарных операций, а не в виде «запросили статус - проверили - послали команду».

Не получится ли там в итоге консенсус-велосипед

Так что нет не получится. С другой стороны можно брать уже готовое ПО, которое этот самый распределённый консенсус реализует, Consul, например.