Добрый день, ВСЕМ!

Вопрос состоит в следующем: некая система мониторнга собирает и передает (через GPRS) статистические данные, которые потом надо обрабатывать. Удобнее всего, чтобы они сразу попадали в БД.

Может кто подскажет, каким образом можно организовать передачу данных напрямую в БД и вообще есть ли такая возможность?

Заранее спасибо за ответы.

Все зависит от того, к чему у Вас "припаян" SIM300
маловато исходных данных, даже для минимальных рассуждений.

Меня интересует последовательность обмена с сервером, на котором БД, а конечная реализация проекта может быть разной.
Сейчас, к примеру, SIM300 подключен через EVB Kit и пробую соединиться с БД и положить туда какие-то значения.

тогда запускайте клиента MySQL и пусть он ложит туда какие-то значения.

а подключиться то как к серверу БД и передать данные с помощью АТ команд?

передача данных с помощью АТ команд описана в документации на SIM300.
а последовательность байт, которую сервер трансформирует в "insert into TABLE1 (INT_VALUE,FLOAT_VALUE) values (1,1.45)" вам здесь никто не расскажет. для этого надо по другим страничкам ходить и читать другие форумы.

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

а кто сказал про at-команды?

если вы хотите через at-команды - ставите на севрере маленького демона, который будет принимать данные по tcp в удобном для реализации на МК виде и уже эти данные пихать в mysql.
тогда вам останется соединиться с нужным портом и послать туда данные по tcp/ip. я ту часть мануала не читал, но проблем тут быть не должно - с тем же http примеры в форуме проскакивали.

меня вот какой вопрос интересует - а никто не задумывается хотя бы о примитивной авторизации? как я понял, все шлют открытым текстом, шутнику из инета будет проще простого послать на ваш сервер поддельные данные (которые вы никак не отличите от "настоящих" с ваших модемов).

IMHO это есть большая проблема при создании нормального защищенного устройства.
те, кто посерьезнее, поднимают свой SSL/TSL тунель поверх TCP или UDP,
и работают по HTTPs или FTPs, но тогда мы попадаем на какой нибудь ARM9 с операционкой вроде ucLinux и своим IP стэком. правда SSL толкнуть туда проблема та еще

ОС,безусловно, усложняет прибор, но и позволяет многое. Я бы не назвал это попаданием.
Просто следующий уровень устройства.

А в чем проблема запуска SSL на ucLinux? (просто из интереса, сам пока не сталкивался)

цена .. цена.. усе выше и выше
разработка дороже и дороже. отладка дольше и дольше и т.п.
да еще забыл. потребление все больше и больше.

я не видел свободных портов SSL под ucLinux.
а уже поднять FTPs или HTTPs в принципе не сложно.

миллион раз обсуждалось и спорилось вряд-ли всплывет что-то новое.



навскидку:
http://www.uclinux.org/pub/uClinux/archive/5300.html
а вообще - тема занятная, судя по обилию топиков..

По поводу микроконтроллеров, читаем в том же топике про openSSL (коммерческие весят поменьше).
Note, that the SSH binary's are rather large. You will need around 1 meg of flash if you
are going to use both SSH and SSHD. There is also assh-keygen binary you will
need. All are large.

1Мб только под сам SSL, про FTPs и HTTPs мы еще не говорим даже. да и + сама ось.

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

вот, вот... я взял готовую железку на mips с linux (даже не uclinux) и не парюсь.

разработка дешевле - могие вещи уже реализованы (те же tcp/ip, ppp, ssl, http). отладка тоже проще - отлаживаешься на десктопе. потребление - единицы ватт, в моем случае роли не играет.

Не знаю как в MySQL, но Sybase и MSSQL используют протокол TDS

http://en.wikipedia.org/wiki/Tabular_Data_Stream

это протокол с бинарным кодированием. Исключительный гемор несмотря на фриварные реализации.
Дешевле будет прикрутить нечто на базе XML. Например сделать на сервере ISAPI фильтр перехватывающий аплоад XML файлов с дивайсов и генерящий ивент для SQL сервера, этакая тупая утилитка, в Delphi-ах за день делается.
SQL сервер по ивенту(тригеру и чему другому) сразу запускает скрипт чтения файла из указанного места и переносит данные в таблицы.
Хотя наверно логичнее ISAPI фильтру самому парсить данные и писать в SQL сервер напрямую.

Оказалось, что с MySQL все очень примитивно.

Вообщем просто коннектимся на порт MySQL - 3306 и тупо прямо плайн текстом шлем ему натуральный SQL запрос типа такого:

UPDATE `oscommerce`.`address_book` SET `entry_firstname`='Joh' WHERE `address_book_id`='1';

это запрос на обновление содержимого поля entry_firstname. B все! Коннект разрываем.

Ну правда еще перед этим логинимся. Шлем текстовые пакеты с название базы данных, именем юзера и паролем. Сервер отвечает тупо OK. Парсить его отверы не придется.
Загвоздка только, что пароль посылается как-то зашифровано. Но на первых порах можно просто скопировать его шифрованное представление в свои запросы из снифера.

ага, и все это открыто и не шифровано посылаем через интернет

AlexandrY
А можно подробнее... Я пробовал через telnet но после коннекта сервер выдает непонятную строку символов и чегото ждет. Если нажать какую нибудь клавишу связь разрывается.

На самом деле я маленько упростил для ясности повествования.
Предпологалось, что читатель сам имеет снифер internet протоколов и поймет что еще требуется.
Обмен там пакетный, и хидер пакета имеет бинарную кодировку. Но он очень простой, буквально длина и тип команды.
Но команда проходит в одном TCP пакете. Т.е. telnet уже не катит.
В принципе в исходниках MySQL есть библиотека клиента.
Как всегда для opensource там черт ногу сломает.
Либа достаточно портабельна, но объемна неимоверного.
MySQL поддерживает SSL, если вы портировали SSL, то можете организовать защищенный канал, протокол обмена остается тот же.

Однако проблема, то что MySQL на дешевых хостингах не имеет коннекта по TCP.
На этот счет есть куча готовых PHP серверных скриптов пересылающих SQL запросы в методе POST или GET прямо в MySQL.
Самый простой путь это воспользоваться проектом phpMyAdmin, он часто уже стоит на хостингах, и посылать запросы через страницу ввода SQL запросов.
Единственную сложность вижу в парсинге ответа и запоминании возвращаемых параметров cookie и token от сервера, чтобы потом правильно формировать запросы.
Пароль здесь шифровать уже не потребуется.