Разработка сервера сбора и обработки данных

[Интегральный вычислитель]

Попов Роман, гр 4105.
Тема бакалаврской работы:
"Разработка сервера сбора и обработки данных для распределенной ИУС"

В рамках данный работы я разрабатываю сервер для связи между удаленными контроллерами управления и SCADA-системой через TCP/IP сети. Задачей сервера является сбор информации с контроллеров, доставка команд управления и обновлений программного обеспечения контроллеров, связь с базой данных.

Реализуемый протокол прикладного уровня является усовершенствованием протокола PM3P, используемого в учебных стендах семейства SDK. Также вводиться дополнительный протокол канального уровня, который с одной стороны позволит использовать сервер вне TCP/IP стека, а с другой стороны добавит некоторые полезные свойства, такие как шифрование.

На данный момент полностью реализована работа с контроллерами, думаю над тем, как обеспечить соединение с базой данных и SCADA системой.

[AlexNickolaenkov]

три вопроса:
1) на чем пишешь? (полагаю С+-
2) какие БД собираешься поддерживать?
3) какой интерфейс предоставляет SCADA?

[Интегральный вычислитель]

три вопроса:
1) на чем пишешь? (полагаю С+-

В основном на Си, частично на СиПлюс ( на нем написана "фабрика" пакетов канального уровня). Головная часть (приемо-передатчик) написана на Си, она работает со стандартным потоком ввода-вывода и вызывает нужные ей подсистемы (разборка пакетов, связь с БД, логер ) в отдельных процессах, передавая им данные через FIFO-файлы. При реализации конкретного канала связи пишется обертка для stdin/stdout и тривиальный механизм расспараллеливания (listen - fork) (я использую xinetd =) )

2) какие БД собираешься поддерживать?

Тренируюсь на мускуле, но ничто не мешает мне в последствии прикрутить что-нибудь типа odbc.

3) какой интерфейс предоставляет SCADA?

Никакой. Интерфейс для SCADA предоставляет сервер, либо SCADA/сервер обмениваются данными через БД. Для этого в сервере существует отдельный процесс, который на выходе генерит очереди команд для каждого процесса, обслуживающего соединение с контроллером. На данный момент эти очереди опрашиваются периодически, через заданный промежуток времени, но я надеюсь, что как только у меня появиться свободное время, я смогу придумать асинхронный механизм IPC

[AlexNickolaenkov]

Ещё подумаю, но по-моему это изобретение велосипеда. Смотрел в сторону докручивания для этой цели Nagios (http://www.nagios.org/) или Zabbix(http://www.zabbix.com/)?

Чем мотивирован выбор С+- в качестве основного языка разработки? С моей точки зрения уровень абстракции, предоставляемый этим языком при разработке подобного продукта слишком низок, что приведет к значительной сложности разработки, сложности подколючения новых людей, сложности поддержки и тестирования.

[Интегральный вычислитель]

Ещё подумаю, но по-моему это изобретение велосипеда.

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

Смотрел в сторону докручивания для этой цели Nagios (http://www.nagios.org/) или Zabbix(http://www.zabbix.com/)?

Нет, насколько я понял, это штуки соврешенно другого класса и для других целей. Мне хотелось сделать небольшой сервак, занимающий в памяти несколько десятков килобайт и расчитанный на воплощение в компактном кондовом девайсе без механических частей (жестких дисков и вентиляторов). Изначально планировалось реализовать его на SDK 2.0 под uCos/eCos, но, к сожалению, у человека занимающегося операционками возникли проблемы с ethernet контроллером.

Чем мотивирован выбор С+- в качестве основного языка разработки?

Компиляторы C++ существуют для множества аппаратных платформ, это и мотивировало выбор языка.

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

На мой взгляд "уровень абстракции" используемого языка программирования мало влияет на сложность разработки. Основным фактором, определяющим сложность, является архитектура разрабатываемой системы, сформированная на этапе проектирования. А на архитектуру системы влияют в основном парадигма программирования (ООП,ПП,ФП,ЛП..), опыт проектировщика, знание шаблонов проектирования.
Такие "фишки" как динамическая типизация,автоматическая сборка мусора, отсутствие адресной арифметики могут значительно облегчить изучение языка программирования и повысить "удобство" его использования, но повлиять на сложность они не могут. А иногда они могут породить дополнительные проблемы, страшно представить, как бы я парсил бинарный протокол на языке вроде Питона или Руби..

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

На данный момент сервер состоит из компонентов по сложности и размеру близких к программе "Hello world", а его архитектура умещается на одной странице формата A4. Такую систему достаточно легко тестировать, да и подключить в её разработку можно даже первокурсника.

[AlexNickolaenkov]

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

На мой взгляд "уровень абстракции" используемого языка программирования мало влияет на сложность разработки. Основным фактором, определяющим сложность, является архитектура разрабатываемой системы, сформированная на этапе проектирования. А на архитектуру системы влияют в основном парадигма программирования (ООП,ПП,ФП,ЛП..), опыт проектировщика, знание шаблонов проектирования.
Такие "фишки" как динамическая типизация,автоматическая сборка мусора, отсутствие адресной арифметики могут значительно облегчить изучение языка программирования и повысить "удобство" его использования, но повлиять на сложность они не могут. А иногда они могут породить дополнительные проблемы, страшно представить, как бы я парсил бинарный протокол на языке вроде Питона или Руби..

Язык непосредственно влияет на количества кода программы, его читаемость и сложность. В целом традиционная проблема с lock(u)-unlock(u) в С и решение его в Java в виде блоков synchronized(lock){ ... } и в C# lock(something){ ... } показывает что синтаксис может порождать непреднамеренные ошибки. С абстракцией то же самое. Надо четко понимать главную цель программиста при написании программ: избегать сложность (KISS from unix).

Касаемо Nagios: исходный код Nagios занимает несколько килобайт. Он достаточно маленький и достаточно хорошо написан (для С) %) Если цель потренироваться, то рассматривать такие системы с одной стороны не надо, но с другой можно учесть их опыт. Нагиос это тоже сервер, который занимается мониторингом. Его можно настроить на сбор информации с удаленных объектов через TCP/IP. Т.е. по сути если использовать нагиос как базу, надо было бы написать только реализацию протокола pm3p и доделать соединение нагиоса с базой (насколько помню сейчас он использует syslog), но наработки в этой системе по направлению к базе уже есть. Итого: взять сервер нагиос, работающий тоже через преподобный xinetd, остается написать для него сервис check_pm3p и наслаждаться работающей системой )

[kluchev]

Язык непосредственно влияет на количества кода программы, его читаемость и сложность. В целом традиционная проблема с lock(u)-unlock(u) в С и решение его в Java в виде блоков synchronized(lock){ ... } и в C# lock(something){ ... } показывает что синтаксис может порождать непреднамеренные ошибки. С абстракцией то же самое. Надо четко понимать главную цель программиста при написании программ: избегать сложность (KISS from unix).

Про KISS я даже плакат на стене своим программистам повесил

По поводу C и Java: посмотри на эти языки с позиции моделей вычислений, один черт по моему, и там и там - Фон-Нейман. Ни С, ни Java - не предназначены для решения задач с несколькими процессами. На эту тему есть статья Эдварда Ли - "Проблема с потоками" http://www.softcraft.ru/parallel/pwt/index.shtml

Java - хороший пример инфляционного процесса в информационных технологиях, достаточно посмотреть критику Вирта. Вообще-то в ИТ - нехилый кризис...

Кстати, мы затеяли нашу бурную деятельность именно для того, чтобы разобраться, как нам сделать более удобное средство проектирования.

[Интегральный вычислитель]

Язык непосредственно влияет на количества кода программы, его читаемость и сложность. В целом традиционная проблема с lock(u)-unlock(u) в С и решение его в Java в виде блоков synchronized(lock){ ... } и в C# lock(something){ ... } показывает что синтаксис может порождать непреднамеренные ошибки. С абстракцией то же самое.

Одним словом, мы говорим о разных вещах. То, что ты называешь сложностью, я называю удобством. Мне тоже нравяться Java и Си# (хотя synchronized в C++ легко реализуется с помощью макросов, также как и foreach циклы и прочие синтаксические удобности), но тащить вместе с программой прожорливые виртуальные машины не всегда представляется возможным, особенно если ты программируешь не под PC.

[Интегральный вычислитель]

Касаемо Nagios: исходный код Nagios занимает несколько килобайт. Он достаточно маленький и достаточно хорошо написан (для С) %) Если цель потренироваться, то рассматривать такие системы с одной стороны не надо, но с другой можно учесть их опыт. Нагиос это тоже сервер, который занимается мониторингом. Его можно настроить на сбор информации с удаленных объектов через TCP/IP. Т.е. по сути если использовать нагиос как базу, надо было бы написать только реализацию протокола pm3p и доделать соединение нагиоса с базой (насколько помню сейчас он использует syslog), но наработки в этой системе по направлению к базе уже есть. Итого: взять сервер нагиос, работающий тоже через преподобный xinetd, остается написать для него сервис check_pm3p и наслаждаться работающей системой )

Спасибо, я посмотрю на него повнимательней, когда будет время. Наверное для дипломной писанины там найдется полезная информация.

[AlexNickolaenkov]

Язык непосредственно влияет на количества кода программы, его читаемость и сложность. В целом традиционная проблема с lock(u)-unlock(u) в С и решение его в Java в виде блоков synchronized(lock){ ... } и в C# lock(something){ ... } показывает что синтаксис может порождать непреднамеренные ошибки. С абстракцией то же самое. Надо четко понимать главную цель программиста при написании программ: избегать сложность (KISS from unix).

Про KISS я даже плакат на стене своим программистам повесил

По поводу C и Java: посмотри на эти языки с позиции моделей вычислений, один черт по моему, и там и там - Фон-Нейман. Ни С, ни Java - не предназначены для решения задач с несколькими процессами. На эту тему есть статья Эдварда Ли - "Проблема с потоками" http://www.softcraft.ru/parallel/pwt/index.shtml

Java - хороший пример инфляционного процесса в информационных технологиях, достаточно посмотреть критику Вирта. Вообще-то в ИТ - нехилый кризис...

Кстати, мы затеяли нашу бурную деятельность именно для того, чтобы разобраться, как нам сделать более удобное средство проектирования.

Да, знаю эту точку зрения. Но переход от одной системы к другой никогда не будет быстрым. Поэтому если что-нибудь получится, то еще лет 20 мы будем работать с тем, что есть. Так что не сильно бы я рассчитывал на новую модель и яростно ее защищал. Я бы сказал -- ну да, есть такое.

Не бывает плохих технологий и хороших, каждая из них решает свою цель. Целей у Java много, у C# тоже и у других языков типа C, ++, python и Ruby. Естественно все эти технологии большое зарабатывание денег и переливание из пустого в порожнее, но движение там есть, и его необходимо видеть для того чтобы успешно работать над новыми концепциями. К чему я это клоню? Не изменив базу мы не сможем изменить технологии. Как базировались мы на Тьюринге, так и будет наша железка работать выбирая одну команду за другой, не накладывая никаких других ограничений. Так как наша отрасль делает такое железо, то софтверные ребята, базируясь на нем делают свои технологии. В общем тут все очень глубоко, с моей точки зрения. И нельзя сказать что Java 7 там что-нибудь решила кардинально новое. Совсем нет -- просто улучшенный синтаксис на той же основе. Более удобное средство для зарабатывания денег.

Более того, надо помнить, что в ИТ все завязано на деньгах и исследования тоже. Западные профессора живут на грантах, поэтому работают на производство, которое налагает на них такие ограничения. Только учитывая весь опыт мы сможем сделать что-нибудь полезное. С моей точки зрения решение нашей задачи может растянуться на десятилетия, которых судя по всему у нас нет.

Поясню про lock-unlock:
Переход от lock-unlock к synchronized вызыван совсем не удобством, и for(int i=0; i = somthing.length; i++) -> foreach тоже. Старые конструкции пораждают баги. Например, вот классический пример

Код: Выделить всё

if(a || b){
   lock (d);
   // dosomething
}

if(a & b){
   unlock(d);
}


видим, что лок в этом случае не всегда отпускается - результат на лицо: дедлок.

Очевидно что переход от такой структуры к синтаксису

Код: Выделить всё

lock(something){
// do something
}


полностью убирает в этом случае проблему дедлока. Это сделано для уменьшения количества таких "глупых" дефектов в программах. Удобство второстепенно.

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

З.ы. с нетерпением жду момента роспуска кафедры "Прикладной математики и информатики", ну или по крайней мере прекращения преподавания их в дисциплинах нашей кафедры. Всем уже давно очевидно, что никаких полезных знаний они не дают.

[Интегральный вычислитель]

Поясню про lock-unlock...
Переход от lock-unlock к synchronized вызыван совсем не удобством, и for(int i=0; i = somthing.length; i++) -> foreach тоже. Старые конструкции пораждают баги...

Это понятно, просто я хотел сказать что в C++ подобные операторы можно реализовать с помощью макросов.

Код: Выделить всё

#define synchronized(something)  for(lock( something ); islocked( something ); unlock( something ))


Код: Выделить всё

#define foreach( i, c ) \
  typedef __typeof__( c ) c##_CONTAINER;\
  for( c##_CONTAINER :: iterator i = c.begin(); i != c.end(); ++i )


[kluchev]

Это понятно, просто я хотел сказать что в C++ подобные операторы можно реализовать с помощью макросов.

Хм... Упаси господь применять это на практике. Применение макросов убивает проверки компилятора и приводит к трудноуловимым ошибкам. А ещё очень сильно страдает идиоматичность кода из-за введения новых языковых конструкций, от которых непонятно чего ожидать. В C++ и так все плохо, а тут ещё и макросы... О вреде конструкции lock/unlock теперь надо смотреть в курилке, в разделе "Размышления о науке, образовании и смысле жизни"

[Интегральный вычислитель]

Это понятно, просто я хотел сказать что в C++ подобные операторы можно реализовать с помощью макросов.

Хм... Упаси господь применять это на практике. Применение макросов убивает проверки компилятора

We all know that C and C++ macros are evil, sharing a level of hell with the devil himself
Макросы работают на уровне препроцессора, поэтому никакие проверки компилятора не должны убиваться.

и приводит к трудноуловимым ошибкам.

Наоборот. Как было замечено выше, применение подобных конструкций помогает избежать глупых ошибок.

Подобные приемы с макросами применяются во многих C++ библиотеках. К примеру, у того же Майкрософта.
В библиотеке Qt, которую я сейчас использую, даже написан дополнительный препроцессор, который добавляет в C++ дополнительные конструкции для обмена сообщениями между объекатми. (макосы SIGNAL и SLOT, по сути синтаксичесое воплощение механизма делегирования событий.)

[AlexNickolaenkov]

Код: Выделить всё

#define TRUE FALSE


Эх не ссылался я бы на труды Microsoft, говоря о хорошем стиле программирования... Интересно мнение Аркадия Олеговича на тему Я на C++ почти не программировал, но с моей точки зрения макросы -- хак на c++, вносящие лишнюю сложность и неоднозначность.

[kluchev]

Эх не ссылался я бы на труды Microsoft, говоря о хорошем стиле программирования... Интересно мнение Аркадия Олеговича на тему Я на C++ почти не программировал, но с моей точки зрения макросы -- хак на c++, вносящие лишнюю сложность и неоднозначность.

Ну, я уже накушался макросов по самое немогу, причем я использовал большей десятка различных компиляторов... А по поводу Microsoft - действительно так. Это не то место, где нужно учиться технологиям. Это скорее Мекка для спекулянтов, IMHO

[NickBorisov]

Это понятно, просто я хотел сказать что в C++ подобные операторы можно реализовать с помощью макросов.

Хм... Упаси господь применять это на практике. Применение макросов убивает проверки компилятора

We all know that C and C++ macros are evil, sharing a level of hell with the devil himself
Макросы работают на уровне препроцессора, поэтому никакие проверки компилятора не должны убиваться.

и приводит к трудноуловимым ошибкам.

Наоборот. Как было замечено выше, применение подобных конструкций помогает избежать глупых ошибок.

Подобные приемы с макросами применяются во многих C++ библиотеках. К примеру, у того же Майкрософта.
В библиотеке Qt, которую я сейчас использую, даже написан дополнительный препроцессор, который добавляет в C++ дополнительные конструкции для обмена сообщениями между объекатми. (макосы SIGNAL и SLOT, по сути синтаксичесое воплощение механизма делегирования событий.)

ИМХО, такое мнение о макросах может сложиться только у человека, не имеющего опыта разработки и поддержки сколько-нибудь крупного, совместного проекта на С++. Не в обиду будет сказано.

Так сложилось, что в моем случае наиболее коммерчески востребованным оказался именно С++ Он не идеален, как и все остальные языкм. Но с этим можно справляться Могу посоветовать 2 очень неплохие книги:
"Веревка достаточной длины, чтобы ... выстрелить себе в ногу" - это исключительно про С++. Читается не очень увлекательно, но когда столкнешь с описанным там, все осознаешь.
"Совершенный код" Стива Макконнела - тут уже речь идет о том, чтобы код можно было не только писать, но и потом читать, а главное - поддерживать

[kluchev]

ИМХО, такое мнение о макросах может сложиться только у человека, не имеющего опыта разработки и поддержки сколько-нибудь крупного, совместного проекта на С++. Не в обиду будет сказано.

Так сложилось, что в моем случае наиболее коммерчески востребованным оказался именно С++ Он не идеален, как и все остальные языкм. Но с этим можно справляться Могу посоветовать 2 очень неплохие книги:
"Веревка достаточной длины, чтобы ... выстрелить себе в ногу" - это исключительно про С++. Читается не очень увлекательно, но когда столкнешь с описанным там, все осознаешь.
"Совершенный код" Стива Макконнела - тут уже речь идет о том, чтобы код можно было не только писать, но и потом читать, а главное - поддерживать

Мне кажется, что осознание у меня произошло уже достаточно давно

Такое мнение о макросах появилось после реализации у нас на кафедре нескольких компиляторов с помощью которых было реализован ряд крупных проектов

По поводу C++ я близок к критике Вирта. У нас на FTP выложены его статьи.

[AlexNickolaenkov]

Я думаю NickBorisov имел в виду опыт Раб Лампы.

[NickBorisov]

Я думаю NickBorisov имел в виду опыт Раб Лампы.

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

[NickBorisov]

хотя, если интересно, могу привести случаи, когда это очень даже удобно и эффективно.