LINUX.ORG.RU
ФорумTalks

На каких технологиях построить сетевой проект?


0

1

Сейчас у нас пилится система сбора и предоставления данных.

Существует много девайсов, с них инфа льется в базу по различным каналам связи. Из этой базы надо предоставлять данные на веб и мобильные аппы.

Хочу посоветоваться на чем это лучше реализовать.

На сечас в начальном приближении пилится минимальное исполнение на ARM EmbeddedLinux + Qt + SQLite. Обмен внутри неё и вовне унифицирован в XML для ip сетей. Но в составе будущей системы это будет только одна из минорных нод.

Вопрос в том, на чем пилить мастер ноду всего комплекса. Я так понимаю, что плюсы не вариант ибо будет полноценный серв по сбору данных. СУБД скорей всего какойнить постгресс.

Обертку на какомнить php/ruby/python. Из всего этого я разрываюсь между python и руби. И за питон по той причине, что на нем уже девелопил, и у него есть django и twisted. С другой стороны, у руби есть rails и event machine (уж не знаю насколько оно конкурент питоноаналогам).

Гонять нужно будет как просто текст, так и фото, возможно видео.

Итак потобную систему удобно будет запилить на django+twisted? Может и вовсе посмотреть в сторону java чтобы было enterprise?

зы. в активе молодая команда из меня и 4х молодых студентов, жадных до инноваций и любящих плюсы и андроид.

Есть только одно годное решение: С.
Менее годное, зато более простое С++.

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

Jetty ★★★★★
()

Как-то сумбурно все...

1) Откуда берется информация?

2) Как много?

3) Насколько сложна ее структура?

4) Каковы требования по надежности и безопасности?

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

> 1) Откуда берется информация?

ethernet, gsm, rs485, пром радиоканалы - но все в конце концов так или иначе приводится к XML в ip ну или json+HTTP_POST - не суть важно

2) Как много?

как правило небольшие порции данных - с прибора по нескольку int раз в минуту. но иногда и побольше если требуется передать фото и массив инфы

3) Насколько сложна ее структура?

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

4) Каковы требования по надежности и безопасности?

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

VladimirMalyk ★★★★★
() автор топика
Ответ на: комментарий от VladimirMalyk

Что-то я не понял, что у вас за «ноды»?

Я понимаю так. Есть часть, работающая в реальном времени:

1) На местах есть embedded-нечто, собирающее инфу с неких приборов и отсылающее ее в центр по разным каналам.

2) В центре есть сервер (точнее два или три) с базой данных, собирающий инфу с мест.

Аналитика - отдельно. Взять инфу из баз и обработать можно когда угодно и чем угодно.

В чем именно задачка? Чем принимать инфу в пункте 2? Я бы сделал обычный HTTPS-сервер. Код писал бы на языке с жесткой типизацией, т.е. Java, С++, Ada, Pascal. Потому что функциональность простая и надолго, а требования к надежности все-таки есть.

Deleted
()

Морду на жаве/джанге/рельсах, стриминг - на эрланге?

По поводу жаваморды недавно был срач в вебдеве. Мне (нисмотря ни на что :) таки нравятся Play (клон рельсов) и Tapestry.

а стриминг и ноды на эрланге - ну, он же для того и делался, грех не заюзать :)

stevejobs ★★★★☆
()
Ответ на: комментарий от Deleted

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

VladimirMalyk ★★★★★
() автор топика

только С, только хардкор

XML не нужен, когда есть ASN.1

Harald ★★★★★
()
Ответ на: комментарий от bakugan

мы не претендуем на уровень больших промышленных скада систем, там и так полно конкурентров

VladimirMalyk ★★★★★
() автор топика

>На каких технологиях построить сетевой проект?

WCF, инфа 100%! ;)

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