Григорий Бондаренко: Это решается программой на Qt в 150 строчек. Логика такая:
обработчик сигнала "можно читать строку из ком-порта" - читает и запоминает данные в буфере
обработчик сигнала "можно читать TCP" - читает TCP, смотрит в буфер, Если буфер пустой, отсылает, что он пустой, иначе - отсылает буфер.
обработчик сигнала "новое соединение" - создает класс - приемник событий от клиента TCP.
обработчик сигнала "TCP разъединилось" - уничтожает приемник событий от клиента TCP
Григорий Бондаренко: 1) Надо поглядеть исходники. Дело в том, что в них реализован конкурентный доступ к промежуточному файлу, а значит, нет гарантии, что процесс не "подзастрянет" на сотню-другую миллисекунд. Можно провести эксперимент.
2)В базу попадает все, что попадает в SMDR.
3) Эти решения очень ненадежны - приложение на этом конце должно одновременно обслуживать события от TCP и от ком-порта, что на баше сделать трудновасто.
4) Контроль доставки по TCP реализуется очень просто. Клиент шлет серверу по соединению запросы "Есть чего?", а сервер отвечает "Есть, вот" или "нету". А если не отвечает, клиент поднимает тревогу.
Григорий Бондаренко: У меня "C++ головного мозга", поэтому я буду всячески рекомендовать C++, к сожалению.
В принципе, мою связку программ можно настроить на более частую передачу информации в базу. Firebird умеет слать уведомление клиенту о новых записях - это как раз можно применить для организации всплывающего окна.
Григорий Бондаренко: Имеется в виду разрыв соединения между БД и АТС, при котором звонки перестанут попадать в базу и отображаться у оператора.
Понятно, что это маловероятная ситуация, но довольно опасная.
Григорий Бондаренко: У меня есть для TDA200. Алгоритм такой
-программа слушает COM-порт и пишет все, что услышит в файл.
-вторая программа читает файл, разбирает SMDR и сваливает в таблицу в базе Firebird.
Однако, здесь нет задачи немедленного уведомления БД о новом звонке, это, фактически, сбор статистики (потому и пишется в файл - коннект упал, но статистика пишется). Период обновления - минута (по cron).
В вашем случае, чтобы обеспечить железобетонную надежность, придется также использовать две программы. nc, socat и другие аналоги не подойдут - они не уведомляют о разрыве соединения.
Первая программа будет разбирать то, чем плюется АТС и по TCP общаться с программой на рабочем месте секретаря. Вторая программа будет показывать окошки и прочие фокусы.
К сожалению, мои программы написаны на C++ и могут оказаться трудны для адаптации.
От Qt здесь понадобятся QSerialPort, QTCPServer, QTCPSocket.
respe-t: Это сейчас "не нужно", а дальше может резко стать "нужно".
"Компактно" - тоже странная затея. Насколько я помню, Firebird Интербейсович под Blob изволит съедать всю страницу - минимум 4 килобайта. Вот вам и "компактно".
jcmvbkbc: да, да, классический эффект последней строки. На момент написания моего ответа, там было for(i=j+1,..., а дальше тупоголовый парсер тостера все пожрал.
Rainberd шустро комментарий поправил, и теперь я выгляжу немножко тупицей.
