Какую выбрать среду разработки для приёма данных по UDP и записи в БД mysql?
В разработке серверная часть программы, которая будет передавать данные о поступающих звонках на клиентский компьютер по сети (на UDP-порт).
Нужно написать клиентскую часть программы под Windows для секретаря, которая будет отображать данные о звонящем клиенте с возможностью их редактирования. Программа должна соответствовать следующим требованиям:
1) работать в фоне и быть не закрываемой
2) для каждого нового звонка она должна показывать отдельное окно с большими буквами поверх всех окон, даже если секретарь просматривает фотографии на весь экран, например
3) после редактирования данных секретарём, они должны попасть в БД mysql, которая находится на сервере в локальной сети
4) соответствующее окно должно автоматически закрыться, если получен сигнал о завершении разговора
5) должно быть окно для поиска записей в БД и их редактирования (подобие таблицы)
От разработки в среде WEB отказался, т. к. приложение должно работать независимо от браузера. Опыт "программирования" ограничивается написанием vbs-скриптов, поэтому обращаюсь к спецам за помощью. Какую среду разработки и какой набор библиотек лучше выбрать для моей задачи, и чтобы она работала как на XP, так и на Windows 7.
Главный вопрос - почему информация о звонке приходит на UDP? Как реализован контроль доставки? Где гарантии, что пакет не потерялся? То есть, сюда просится TCP со всеми наворотами, вроде heartbeat, keep-alive и контроллеров.
И да ответ "у нас ethernet, пакеты не теряются" никуда не годится. Даже на loopback пакеты с удовольствием могут теряться.
А так, это задачка по Qt джуну на один-два вечера.
Возможно действительно лучше слать по TCP. Линуксовая команда "nc" умеет это делать. Надо бы почитать доки про TCP.
Значит буду смотреть в сторону QT. А язык какой лучше выбрать, чтобы не палить из пушки по воробьям? У qt есть варианты для разных языков.
Армянское Радио: телепат ) Да, панасоник. А какие варианты? Фирменное ПО для KX-TDA100 уже не продаётся. Пиратки не нашёл. Так что приходится делать самому.
Григорий Бондаренко: У меня есть для TDA200. Алгоритм такой
-программа слушает COM-порт и пишет все, что услышит в файл.
-вторая программа читает файл, разбирает SMDR и сваливает в таблицу в базе Firebird.
Однако, здесь нет задачи немедленного уведомления БД о новом звонке, это, фактически, сбор статистики (потому и пишется в файл - коннект упал, но статистика пишется). Период обновления - минута (по cron).
В вашем случае, чтобы обеспечить железобетонную надежность, придется также использовать две программы. nc, socat и другие аналоги не подойдут - они не уведомляют о разрыве соединения.
Первая программа будет разбирать то, чем плюется АТС и по TCP общаться с программой на рабочем месте секретаря. Вторая программа будет показывать окошки и прочие фокусы.
К сожалению, мои программы написаны на C++ и могут оказаться трудны для адаптации.
От Qt здесь понадобятся QSerialPort, QTCPServer, QTCPSocket.
Армянское Радио: Имеется ввиду разрыв соединения между клиентом и сервером? Так он не повлияет на ведение лога: этим будет заниматься сервер без участия клиента. Клиент будет только получать уведомления о звонках и править БД клиентов при необходимости. То-есть будет две таблицы: собственно лог звонков и перечень клиентов. Они будут обрабатываться вместе только для отчётов: будут сопоставляться номера из лога и номера из перечня клиентов.
Григорий Бондаренко: Имеется в виду разрыв соединения между БД и АТС, при котором звонки перестанут попадать в базу и отображаться у оператора.
Понятно, что это маловероятная ситуация, но довольно опасная.
Григорий Бондаренко: У меня "C++ головного мозга", поэтому я буду всячески рекомендовать C++, к сожалению.
В принципе, мою связку программ можно настроить на более частую передачу информации в базу. Firebird умеет слать уведомление клиенту о новых записях - это как раз можно применить для организации всплывающего окна.
Армянское Радио: Предложение заманчивое, но есть два вопроса:
1. Сможет ли секретарь получить уведомление с задержкой, не больше полсекунды?
2. Попадают ли в базу строчки о поступлении звонка (ещё до поднятия трубки)?
Если нет, то придётся писать серверную часть.
Есть мысль попробовать сделать это на bash. Например, так:
while read -r line < /dev/cuau1; do
# отправляем $line в качестве аргумента обработчику
done
Обработчик тоже написать на bash, который будет командой "nc" отправлять данные клиенту по tcp-протоколу. Но возникает вопрос задёжности: не будет ли скрипт пропускать символы/строки? И можно ли будет обеспечить контроль доставки tcp-пакетов таким образом?
Григорий Бондаренко: 1) Надо поглядеть исходники. Дело в том, что в них реализован конкурентный доступ к промежуточному файлу, а значит, нет гарантии, что процесс не "подзастрянет" на сотню-другую миллисекунд. Можно провести эксперимент.
2)В базу попадает все, что попадает в SMDR.
3) Эти решения очень ненадежны - приложение на этом конце должно одновременно обслуживать события от TCP и от ком-порта, что на баше сделать трудновасто.
4) Контроль доставки по TCP реализуется очень просто. Клиент шлет серверу по соединению запросы "Есть чего?", а сервер отвечает "Есть, вот" или "нету". А если не отвечает, клиент поднимает тревогу.
Армянское Радио: Лишние задержки не есть хорошо. И, думаю, у меня больше проблем будет с написанием клиентской части. Так что буду писать с нуля
Насчёт третьего пункта: а что если скрипт, обслуживающий события от ком-порта, будет вызывать другой скрипт, обслуживающий TCP, не дожидаясь его завершения? Типа, принял строчку по COM-порту и отправил её в другой скрипт, а сам принимает следующую? Решит ли это проблему?
Григорий Бондаренко: Это решается программой на Qt в 150 строчек. Логика такая:
обработчик сигнала "можно читать строку из ком-порта" - читает и запоминает данные в буфере
обработчик сигнала "можно читать TCP" - читает TCP, смотрит в буфер, Если буфер пустой, отсылает, что он пустой, иначе - отсылает буфер.
обработчик сигнала "новое соединение" - создает класс - приемник событий от клиента TCP.
обработчик сигнала "TCP разъединилось" - уничтожает приемник событий от клиента TCP
Армянское Радио: Панасоник на работе и не подключён к серверу пока. И, я признателен за помощь, но хочу сделать сам. Практический опыт - очень ценная вещь.
И вот, спустя две недели, я близок к завершению проекта. Всё получилось: чтение com-порта, отправка и приём уведомлений по TCP, удобные окошки, таблицы, кнопочки. Но, блин, никак не могу скомпилировать драйвер для MySql.
При запуске проекта qtcreator выдаёт ошибку:
QSqlDatabase: QMYSQL driver not loaded
QSqlDatabase: available drivers: QSQLITE QMYSQL ...
То-есть, драйвер доступен, но не загружен.
В инклудах указал:
#include
#include
#include
Перечитал кучу инструкций, форумов: все они относятся либо к старым версиям QT, либо к компилятору mingw. А у меня по умолчанию установлен MSVC и соответственно свежая версия QT 5.4.1. Я собрал драйвер из библиотек MySql командой qmake, но как его скомпилировать? Файл nmake нахожу в папке компилятора Microsoft Visual Studio. Если копирую в папку с этим файлом собранные исходники и запускаю nmake, то выдаёт ошибку: "не хватает сведений для построения...", если наоборот, копирую nmake.exe в папку с исходниками, то выдаёт ""rc" не является внутренней или внешней командой...".
Думал установить компилятор mingw, но судя по инструкциям, он тоже непросто ставится.
Как мне поступить?
Значит всё таки устанавливать mingw ради драйвера mysql? Или просто использовать mingw для компиляции sql-библиотек и не подключать к QT-creator? Так получится сделать?
Григорий Бондаренко: скажем так, проблема состоит в том, что скрипт сборки не находит компилятор ресурсов. Он либо находится в другом месте, либо называется иначе.
Я бы не стал устраивать из программы лоскутное одеяло, собирая ее разными компиляторами - так как возможность все собрать одним компилятором есть - почему бы ей не воспользоваться?
Установил mingw (Basic setup). Компилятор автоматически появился в списке компиляторов QT-Creator. Собираю драйвер:
D:\CallCentreProject\qtsrc\qtbase\src\plugins\sqldrivers\mysql>set mysql=C:\PROG
RA~1\MySQL\MYSQLS~1.6\
D:\CallCentreProject\qtsrc\qtbase\src\plugins\sqldrivers\mysql>qmake "INCLUDEPAT
H+=%mysql%\include" "LIBS+=%mysql%\lib\opt\libmysql.lib" -o Makefile mysql.pro
Выполняется без ошибок, появляются файлы и папки для компиляции.
Далее ввожу mingw32-make и вот что он выдаёт:
В интернете пишут, что это может быть из-за того, что сборка и компиляция выполняются утилитами из разных пакетов. И действительно, qmake.exe находится в папке "msvc2010_opengl\bin", следовательно он принадлежит пакету Microsoft Visual Studio. Так какого чёрта во всех инструкциях, которые я находил приведен пример именно с qmake?
Уже целый день убил безрезультатно. Может забить и скачать пиратку QT-Creator Enterprise-версии, туда вроде входит драйвер mysql. Что посоветуете?
Григорий Бондаренко: Первый мой совет звучал бы так "выбросьте windows". Я никогда с глюками make под windows не боролся, а под linux со мной такого отродясь не было. Кросс-компиляция этого дела под linux проходит без каких-либо проблем.
