LINUX.ORG.RU

Сетевая система сбора данных (наверное)...


0

0

Здравствуйте.

Есть задача разработать систему, которая будет состоять из датчиков и центрального сервера(ов), который принимает данные с них (периодичность ~10сек). Канал связи gprs.

Не знаю с какой стороны подойти к этой проблеме, так как опыта в сетевом программирование нет никакого.

Как лучше организовать передачу данных от датчиков к серверу? Имеется ввиду tcp или udp.

Как писать демона, который будет принимать данные?

Я так понял есть несколько подходов. Т.е. Есть вариант когда один процесс делает все. Есть вариант, когда плодится по потомку на клиента...

Я так понимаю, что можно сделать так:

Датчик включают, он устанавливает tcp соединение с сервером, и отсылает свои данные. Т.е. насколько я понимаю, придется плодить по процессу/потомку на соединение?

Непонятки начинаются тут. Как я прочитал на форуме, что процессов/потоков должно быть столько, сколько есть "процессоров" в системе.

Не будет ли это сильно нагружать сервер если датчиков порядка 500?

Какие есть еще варианты решения данной задачи?

Посоветуйте пожайлуста, что почитать (желательно в электронном виде) на эту тему...

Идеально было-бы посмотреть на простого демона, в качестве примера...

Заранее благодарен.

anonymous

Решение тебе тут вряд-ли выдадут, но направить - благое дело. Книгу Стивенса "Разработка сетевых приложений" в руки - там есть ответы на 90% твоих вопросов.

jr_A
()
Ответ на: комментарий от jr_A

дык мне готового и не надо... хотелось бы послушать советы и получить наставления :)

за наводку спасибо...

anonymous
()

про SCADA системы прочитай, они этим и занимаются

anonymous
()
Ответ на: комментарий от anonymous

А какой микроконтроллер? А какая там ОС? Туда ещё надо tcp/ip и ppp запихнуть:) Уже не говоря о ядре.Получается очень продвинутый микроконтроллер.

krum
()
Ответ на: комментарий от krum

Да, но для вашей задачи это тоже может слишком. Если данные не очень сложные, и не очень разнообразные, то проще самому разработать бинарный протокол, и реализовать его на C.

krum
()
Ответ на: комментарий от krum

какой контроллер не знаю. что-то из arm ов. Вообще это готовая железка gprs модуль + контроллер (дока и sdk еще не пришли)

Пока я просто смотрю с какой стороны к этому всему подойти..

anonymous
()
Ответ на: комментарий от krum

в том то и дело что данные простые... немного ascii, и собственно сами цифры...

Я и думал разработать свой протокол...

Просто я не знаю как подойти к проектированию/реализации серверной части...

anonymous
()
Ответ на: комментарий от anonymous

А данных много? Какого типа? Или это передача пары чисел? Опять же нужна ли аутентификация? Нужно ли шифрование траффика?

krum
()
Ответ на: комментарий от krum

Порядок данных такой: на первоначальном этапе ~100 объектов. В каждом 5-6 аналоговых каналов, 2-3 цифровых. Хотелось бы еще иметь связь от сервера к клиенту (посылать команды) на 2-3 цифровых канала управления.

Аутентификация я думаю будет нужна, так как канал данных internet. Шифрование вряд ли получится... разве что какое-нибудь совсем простое...

anonymous
()
Ответ на: комментарий от anonymous

Ну в erlang потоки очень дешёвые, а если писать с использованием posix threads, то не очень. Так что язык/платформа имеют значение. ИМХО, если писать на с/с++, то делать надо так, создавать потоков или процессов столько же, сколько процессоров в системе, а в них poll/epoll/что по вкусу или libevent. ИМХО, это не принципиально, я бы начал с разоботки протокола.

krum
()
Ответ на: комментарий от krum

>создавать потоков или процессов столько же, сколько процессоров в системе, а в них poll/epoll/что по вкусу или libevent.

а можно ссылке, где про это можно прочитать на доступном для начинающего уровне?

а то что делать надо так я знаю, только что бы это значило :)

anonymous
()

Исходя из сказанного - ACE действительно будет лучше всего. Судя по всему, протокол тебе разрабатывать не придется, он уже реализован в железках. Тебе остается написать только надежный сервер для сбора данных, по готовому протоколу. При большом кол-ве клиентов (железок) создавать на каждого по нитке - неразумно. В ACE есть все, что нужно для решения этой задачи. Посмотри чего Дуглас Шмидт пишет про реактор.

anonymous
()
Ответ на: комментарий от anonymous

>Судя по всему, протокол тебе разрабатывать не придется, он уже реализован в железках.

Придется... железки то же за мной...

>В ACE есть все, что нужно для решения этой задачи.

А есть ли книжка в электронном виде? А то пока до нашей деревне доедет... :(

anonymous
()
Ответ на: комментарий от krum

>Только РСУБД!

Кстати, вопрос о том как хранить данные...

Есть идея о том что для каждого объекта использовать собственную БД. (ну то есть сервер то один а бд разные)

Думаю, что это позволит снизить нагрузку на СУБД...

Так же ИМХО будет проще расширяться в дальнейшем... Например добавилось еще 100 объектов, берем новую железку, добавляем на нее бд для нужных объектов, и настраиваем софт нужным образом.

Чем плох такой подход если он плох, и как еще можно подойти к проблемам масштабирования?

(думаю, что буду пользовать postgresql)

anonymous
()

>Непонятки начинаются тут. Как я прочитал на форуме, что процессов/потоков должно быть столько, сколько есть "процессоров" в системе.

Обычно рекомендуют 4 нативных потока на процесорное ядро.

в зависимости от архитектуры приложения и прочего эта цифра может быть больше. Брать меньшей в твоём случае скорее всего безсмысленно.

cvv ★★★★★
()

>Сетевая система сбора данных

SNMP

sdio ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.