Форум РадиоКот

Доброе время суток. Разрабатываю концепцию одного устройства. Вопрос следующий:
Необходимо сливать с устройства на микроконтроллере информацию на сервер в БД (предваоительно mysql либо postgresSQL). В качестве протокола связи с сервером будут каналы оператора сотовой связи (информация будет отсылаться с GSM-модема как GPRS-траффик). Как это лучше всего организовать? Вариантов несколько, например:
1. Научиться микроконтроллер SQL-запросам + прописать на микроконтроллере протокол авторизации с сервером и прописать куда и какую информацию писать в БД
2. Писать собственный сервер более верхнего уровня, который уже будет заниматься распихиванием информации по таблицам в базе получая команды и коды от девайса
3. Поднять на девайсе почтовый протокол, сливать всю информацию на сервер через SMTP и далее уже на сервере парсить письма и вносить необходимую информацию в базу

Решение должно быть рациональным, чтоб не грузить сильно девайс и при этом не нагружать сервер лишними действиями, учитывая что девайсов может быть бесконечно много а сервер слабым.
При этом прямой доступ к базе с авторизацией к БД давать девайсу не хочется. Желательно что-бы на стороне серверного приложения устанавливались правила доступа (чтение ИЛИ чтение/запись ИЛИ запрет чтения/записи) к определённым таблицам в базе.

1. научить МК SQL запросам совсем несложно(чтобы сливать информацию нужно всего то один запрос insert .. бла .. бла бла...), сложнее реализовать на нем доступ к самой базе, т.к не слышал реализации драйверов MySQL PGsql для МК.
2. свой сервер писать не надо . они все уже написаны )) . запускаем Linux + Apache + одна страничка на PHP. вот вам готовый сервер на который можно загружать данные. на GSM modem есть готовый протокол TCP . цепляете к нему МК и выгружаете данные.
3. тоже реализуемо, но как мне кажется немного сложнее чем вариант 2. здесь вместо апаче нужно сваять свой скрипт который по cron будет читать почту и загружать данные в БД.

если интересно мое мнение , то вариант 2 предпочтительнее и менее трудоемок

девайсов может быть бесконечно

их не может быть бесконечно много, так как клиентов в сети GSM ограничено

Второй вариант будет проще и правильней со всех точек зрения. Только как уже сказали - писать не надо, просто собрать всё в кучу и заставить работать.

Ну просто не хотелось задействовать HTTP-запросы для такой простой задачи. Хотя IIS в связке с PHP и MySQL уже есть на сервере. Просто в случае с собственным сервером во первых протокол может быть собственный (меньше вероятность что кто-то сможет воспользоваться через web-интерфейс SQL-инъекцией да и передата данных не будет завязана только на одном из методов (post или get). А во вторых можно будет делать авторизацию на сервере "не стандартным" способом, например в маркере пакета писать ID девайса отправляющего пакет.
Просто мне кажется что HTTP не самый лучший вариант для такой узкопрофильной задачи

с контроллера по протоколу tftp передавать сырую инфу файлами на хост
на хосте поставить тфтп сервер из стандартного набора
кроном запускать любой самопальный скрипт на любом языке, который будет парсить и пихать данные в бд
никакой тут апач не нужен, да и сетевая бд для небольшого количества данных тоже не нужна
есть sqlite и в пхп есть модуль для работы с ним, если данные надо предоставлять через вебморду

контроллер должен делать csv файлы с любым форматом
в педевикии посмотри что это такое

kalobyte писал(а):
с контроллера по протоколу tftp передавать сырую инфу файлами на хост

Ну это не самый разумный вариант, т.к. задача контроллера не сливать какой-нибудь большой лог в базу, а писать время от времени в удалённую базу события с небольшой частотой. Так что я не вижу смысла в tftp сессии ради передачи 2-8 байт информации. При этом важно что-бы информация писалась на сервер сразу и без какого-нибудь кеширования (буфера/файла).

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

база должна быть серьёзная

а что мешает написать свой http сервер (правда название ему будет уже другое )? ну на крайний случай изуродовать апач .

Chiper писал(а):Так что я не вижу смысла в tftp сессии ради передачи 2-8 байт информации.

в чем гимор тогда?
делаеш гет запрос с паролем на свой пхп скрипт и передаеш свои 8 байт типа
send.php?token=ergfer867w78f6&byte1=123&byte2=23...
для этого надо открыть сокет, сформировать хттп заголовок и прицепить к нему эту строку, а потом послать в сокет и закрыть

можно конечно и всю строку зашифровать ключом и потом расшифровывать

kalobyte писал(а): для этого надо открыть сокет, сформировать хттп заголовок и прицепить к нему эту строку, а потом послать в сокет и закрыть

Плюсую. Лучше использовать стандартный апач, чем начинать писать стомиллионное собственное серверное приложение.
Но можно и собственное приложение нарисовать, там ничего сложного нет, задача для студента первокурсника.
Как я понимаю из слов IIS в качестве ОС там виндовс?
Ну, тогда берем пример и разукрашиваем его своей логикой.

Tolmi писал(а):Как я понимаю из слов IIS в качестве ОС там виндовс?

А чем Вам windows server 2008 R2 не угодила? По моему очень надёжная платформа под такие проекты.
Хотя я даже не хочу начинать сейчас холивар linux vs windows, далеко уйдём от темы.

igor-x писал(а):в чем гимор тогда?делаеш гет запрос с паролем на свой пхп скрипт и передаеш свои 8 байт типаsend.php?token=ergfer867w78f6&byte1=123&byte2=23...

Ну это уже ближе к делу. Но я думаю нужно тогда ещё и контрольную сумму передавать, вдруг запрос "побьётся" по пути.

Профит в собственном сервере есть вот в чём, не будет лишней прослойки в виде PHP, научить сервис сразу писать в базу и гуд.

Chiper писал(а): Но я думаю нужно тогда ещё и контрольную сумму передавать, вдруг запрос "побьётся" по пути.

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

Профит в собственном сервере есть вот в чём, не будет лишней прослойки в виде PHP, научить сервис сразу писать в базу и гуд.

Если речь идет о Windows и IIS, то чем вам ASP.NET не угодил? IIS как сервер в любом случае будет более качественным, по сравнению с самопальным, тем более, если он в первый раз пишется.

Chiper писал(а): А чем Вам windows server 2008 R2 не угодила? По моему очень надёжная платформа под такие проекты.
Хотя я даже не хочу начинать сейчас холивар linux vs windows, далеко уйдём от темы.

Да нет, я просто так спросил, без всяких задних мыслей. Я не оспаривал её надежности и возможности на ней что-то построить.
Я лишь про то, что если используется платформа от Microsoft, то почему бы не использовать и остальные инструменты от неё тоже. Про ASP.NET здесь уже упоминали, зачем на IIS костыль из PHP ? На technet я видел где-то чуть ли не просто готовый шаблон приложения как раз под этот случай, остаётся только набить своей логикой, если она есть.



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

А эмбедщики ли тут? Зачем так разбазариваться ресурсами микроконтроллера и возможно наступить на кучу граблей?
Во первых нужно выяснить, что за GSM модем. Если у него нет встроенного TCP/IP стека - вам скорее всего прийдется реализовывать PPP, IP, TCP в микроконтроллере. Если еще и HTTP - это уйма работы, поэтому подходите к выбору модема тщательно.
На мой взгляд достаточно передать по TCP и получить подтверждение на случай сбоя на стороне сервера. Со стороны сервера несложно написать маленький TCP демон, который уже и закинет вам хоть на ASP по HTTP, хоть на черта лысого.

nuclearcat писал(а):Если у него нет встроенного TCP/IP стека

даже если он есть, воспользоваться им скорее всего не удастся. Хотя, есть вариант, на смартфоне пишется приложение, которое каким-то образом (USB,Bluetooth ?) взаимодействует в МК, и тот передаёт в это приложение, а уж оно пользуется стеком TCP в смартфоне как пожелает.

- вам скорее всего прийдется реализовывать PPP, IP, TCP в микроконтроллере. Если еще и HTTP - это уйма работы, поэтому подходите к выбору модема тщательно.

Ой да ну прямо таки аж архисложная задача. Если решать узкую задачу донести информацию до некоторого сервера в инете, и не заморачиваться полной поддержкой всего протокола по стандарту, то ничего там сложного нет. И туча самоделок с веб-серверами на мегах тому лучшее подтверждение.

Tolmi писал(а): даже если он есть, воспользоваться им скорее всего не удастся. Хотя, есть вариант, на смартфоне пишется приложение, которое каким-то образом (USB,Bluetooth ?) взаимодействует в МК, и тот передаёт в это приложение, а уж оно пользуется стеком TCP в смартфоне как пожелает.

Вот пример как устанавливается соединение через AT команды. Минимум места в микроконтроллере:
ftp://ftp.multitech.com/resolutions/doc ... 1_v302.doc

Ой да ну прямо таки аж архисложная задача. Если решать узкую задачу донести информацию до некоторого сервера в инете, и не заморачиваться полной поддержкой всего протокола по стандарту, то ничего там сложного нет. И туча самоделок с веб-серверами на мегах тому лучшее подтверждение.

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

Что мешает на стороне сервера просто слушать порт и принимать на него данные? В каком захотите формате, в таком и можно сделать... накой эти монстры вроде апача?
Надо только прикрутить алгоритм цифровой подписи по ресурсам микроконтроллера(врятли он потянет шифрование с 1024-битным ключом, дай бог 56 бит реализовать), чтобы решить задачу авторизации и делов-то. А уж программа, когда примет авторизованные данные уже может свободно общаться с базой данных, ресурсы и язык программирования для этого можно выбрать по вкусу.

В монстрах типа IIS и апача ( кстати этот "монстр" в нынешних многогигабайтных серверах незаметен на фоне других монстров типа СУБД) вылизана сетевая часть с точки зрения производительности и потенциальных дыр в реализации. Не, если кто-то умеет писать масштабируемые, высокопроизводительные сетевые сервисы, то, понятно, ему никакой апач и не нужен. Но если это делать первый раз ...

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