Ищу хорошего программиста (Raspbian, WIN7 ._NET)

[Artem35]

Задание: Центральный блок и операторский пульт управления "УМНЫМ ОГОРОДОМ"

Развернуть для просмотра

Мне нужен TCP-сервер (демон), написанный на С под Debian 9 (Raspbian) для обработки запросов по 2 портам,
и программа - TCP-клиент, работающая с ним под Win7 ( C# .Net Framework), (операторский пункт).
TCP-клиенты у сервера будут двух видов - исполнительный клиент (железо) и операторский пункт (программа TCP-клиент). Исполнительный клиент отсылает запрос на один порт сервера (4001), с него же получает ответ. Оператор отсылает запрос на другой порт (4005), с него же получает ответ.
Исполнительный клиент в сети (Moxa NPort 5232), работает как шлюз, «представляя интересы» приборов, подключенных к нему с другой стороны по сети RS-485. Работает в режиме TCP-клиента. Приборы (в т. ч. реле) периодически шлют ему данные, а он, соответственно, отправляет эти данные в запросах на порт сервера 4001. За один запрос отправляет данные только от ОДНОГО прибора. Сам ничего в данные не добавляет, не изменяет, просто как шлюз.
В этих запросах данные - простая строка максимум на 32 байта, из которых первые 5 байт – ID прибора в сети RS-485, остальные - данные. Сервер должен их принять и сохранить в оперативной памяти в массиве-буфере «измеренных данных» и отправить ответом данные из переменной-буфера «на отправку» (подробнее в пояснении 1). Если буфер пуст (нет данных на отправку), отправляются любые данные (например «1»), иначе моха, не получив ответа, будет повторять запрос много раз.
Другие клиенты – операторы (программа TCP-клиент), хотят эти измерения контролировать и некоторые из них изменять (реле). Для этого они периодически обращаются к серверу с запросом на получение данных, сервер ответом отправляет данные из буфера массива «измеренных данных», клиентская программа принимает и отображает эти данные в полях “Label” и состояния кнопок “Button”. Кнопки принимают свои значения в зависимости от принятых для них данных (нажата-не нажата, т.е. вкл/выкл, подробнее в пояснении 2). Событие нажатия пользователем каждой кнопки немедленно инициализирует запрос серверу, в теле запроса – ID прибора и новое значение данных (состояние кнопки). TCP-Клиент, также как и исполнительный клиент, за один запрос может отправить только ОДНУ команду касаемо одного датчика – по его ID.
Сервер, приняв запрос-команду от оператора в буфер «на отправку», немедленно отправляет их ответом исполнительному клиенту на первый (ближайший) же его запрос. Хочу заметить, что неважно, от какого прибора с каким ID пришли очередные данные и кому (какому ID) сервер в данный момент отправляет ответные данные, потому что ни один прибор после отправки не ждет персонального ответа на свой запрос, а переходит в режим прослушки шины. Приборы в сети RS-485 разберутся сами, кому пришли данные, читая ID.


Теперь ПОЯСНЕНИЯ:
1: Массив-буфер «измеренных данных» - массив строк [32] фиксированной длины, для начала на 4 элемента.
Каждый прибор имеет ID длиной 5 байт, из которых первый байт будет уникальным для каждого прибора и будет являться его номером, по этому номеру данные можно располагать в массиве:
Buf[0] = 0x00,r,e,l,a,rhgjrhghr…
Buf[1] = 0x01,t,e,m,p,dwdhiw…
Buf[2] = 0x02,t,e,m,p,sdwqdf…
Buf[3] = 0x03,r,e,l,a,rtryryy…
Физически всего приборов никак не будет больше 255. Остальные 4 байта – доп. идентификатор (на всякий случай).
2. Буфер «на отправку» - просто массив размерностью 6, в него записывается текущая команда-данные от оператора, из которых первые 5 байт – ID, а последний – данные (1 или 0, т.е. вкл/выкл). Пока управлять нужно только реле, в дальнейшем будет видно.
Каждая кнопка и лейбл в интерфейсе программы-оператора изначально соответствует номеру «своего» прибора. Т.е.,
btn_rel0 – прибору с номером 0x00,
label_temp1 - прибору номер 0х01,
btn_rel2 – прибору с номером 0x02,
label_temp3 - прибору номер 0х03.
Пользователь за один раз может нажать только на одну кнопку и инициировать отправку только одной команды одному прибору. После отправки серверу, операторская программа может не дожидаться ответа от сервера на свою команду. Сервер, после отправки команды оператора исполнительному клиенту, очищает свой буфер «на отправку.
Подтверждением выполнения команды будет ответный «доклад» от реле о своем текущем статусе, который оно отправит Мохе после выполнения команды, который Моха отправит серверу, и который потом получит операторская программа в очередной раз отправив запрос серверу (раз в секунду). Можно разве что заблокировать кнопку от пользователя на время (секунды на 3), чтобы пользователь ее повторно не жал.

[свернуть]

Ну, вроде расписал подробно.
Я, хоть и немного разбираюсь в С, если буду эту работы выполнять самостоятельно – у меня уйдет уйма времени (много вечеров), пока перечитаешь все, разберешься, потом ошибки, баги и т.д. Поэтому решил обратиться к программистам (а в интернете реально немало действительно сильных программистов), которым, эта работа на вечер (или два, первый чтоб понять что к чему).
Почему не HTTP –сервер и интерпретируемый PHP, Python и т.д?
Решил, что запускать такую махину ради пары клиентов нет смысла.
В личку.

[Admin]

Почему не HTTP –сервер

А почему не mqtt server? Он специально разработан для IOT

[Artem35]

Сообщение от Admin

А почему не mqtt server? Он специально разработан для IOT

Знаний мало, до вашего сообщения можно сказать, не слышал. Буду изучать.

P.S. Admin, хотел бы вам сказать огромное спасибо за информацию. Действительно... все мои выдумки - деревянный велосипед.

Вопрос закрыт.