Обмен данными между сервисом и GUI

← →
Empleado © (2009-07-24 13:23) [0]

Допустим, имеется сервис (W2003Srv), который занимается отправкой/получением данных с помощью TServerSocket/TClientSocket в блокирующем режиме с организацией пула потоков.
Одновременно работающих потоков практически немного - 20-50, теоретически может быть 100-300.
Каждый поток имеет всю необходимую информацию о своем соединении и может получать данные об отправленных/полученных данных своего сокета после каждого Read/Write.

Допустим, имеется отдельное приложение, которое контролирует работу этого сервиса (старт, стоп, отсоединить клиента, запустить что-то новое и т.д.) и получает информацию о состоянии и функционировании каждого потока (кто законнектился, что делает, тип обрабатываемых данных, сколько передано/получено данных, время и т.д.).

Вопрос.
Как бы вы организовали передачу информации одновременно из всех потоков в GUI?
Например, данные о полученных/отправленных байтах в реальном времени и затраченного времени, из всех потоков в приложение.

Спасибо

← →
Palladin © (2009-07-24 13:27) [1]

когда то и у меня такая задача была... Игорь посоветовал ipc, но я решил все таки использовать пайпы... не прельстила меня зубодробильня с ipc )

← →
tesseract © (2009-07-24 14:10) [2]

> Как бы вы организовали передачу информации одновременно
> из всех потоков в GUI?

У тебя же TCP сервер - и сделай передачу по IP - заодно удлённое управление будет

← →
clickmaker © (2009-07-24 14:16) [3]

можно сделать сервис COM-сервером. Тогда вообще удобно: просто методы вызываешь

← →
Тимохов_ (2009-07-24 14:44) [4]

именованные каналы. у меня так сделано.

только сервис ничего не должен передавать сам - он должен отвечать на запросы со стороны GUI, т.е. быть сервером :)

← →
Тимохов_ (2009-07-24 15:06) [5]

2Автор

Вот пример транспорта на именованных каналах:
http://www.vkkb.ru/temp/NapedPipes.zip

Если нужно, то бери. На вопросы отвечу. Там есть тонкие места.

Я его в реальном проекте использую. Полностью асинхронный вводы/вывод по сети (т.е. в одном потоке множество клиентов). Обработка запроса может быть синхронной, может быть нет - настраивается в колбеке обработчика запроса.

Протокол - клиент инициирует и прерывает соединение.

По моему личному опыту - именованные каналы в windows сетях несут меньше проблем в настройке, нежели использование TCP/IP напрямую.

← →
DVM © (2009-07-24 16:10) [6]

> По моему личному опыту - именованные каналы в windows сетях
> несут меньше проблем в настройке

До тех пор пока не понадобится управлять через Интернет.

← →
antonn © (2009-07-24 17:37) [7]

> Вопрос.
> Как бы вы организовали передачу информации одновременно
> из всех потоков в GUI?

MMF

← →
Eraser © (2009-07-24 18:39) [8]

> [0] Empleado © (24.07.09 13:23)

в Windows используются именованные каналы, делайте так же - не прогадаете.

← →
Медвежонок Пятачок © (2009-07-24 21:54) [9]

Чтобы точно не прогадать, надо реализовать веб-интерфейс к сервису.

← →
тимохов © (2009-07-25 01:24) [10]

замаешься ты на дельфи делать нормальный веб-интерфейс.
я лично именно замаялся.

← →
Дмитрий С © (2009-07-25 10:59) [11]

> замаешься ты на дельфи делать нормальный веб-интерфейс.
> я лично именно замаялся.

А я php5ts.dll прикрутил и интерфейс делал на php.

> Empleado © (24.07.09 13:23)

Я бы сделал на TCP (свой интерфейс или web). Пайпы и прочее всеравно на этом же принципе работает. А с COMом я не связывался бы, если можно обойтись без него.

← →
DVM © (2009-07-25 22:26) [12]

> А я php5ts.dll прикрутил и интерфейс делал на php.

Хм. Надо поглядеть что за штука.

← →
Дмитрий Белькевич (2009-07-26 13:44) [13]

>А с COMом я не связывался бы, если можно обойтись без него.

Почему? Я бы именно его рекомендовал. Никаких убедительных аргументов против не имею. Зачем городить очередной свой огород, если MS уже всё сделала?

Спасибо всем!
Хотелось узнать мнения программистов.

Пока у меня реализовано через MMF и, частично задействованы сообщения Windows (пробовалось как тест, да так и осталось).
(Делал на том, с чем знаком).
Но ведь хочется, чтобы оно потом и издалека было доступным :)

Думал про TCP. Терзают сомнения, что через TCP может не получиться ввиду большого потока разнородных данных. Возможно я ошибаюсь. Например: сотня-две tthread одновременно отправляет потоки данных о сокетных операциях снова в сокет. Не будет ли тормозить обработка и представление в GUI, например, на этом же сервере..., а на удаленной машине?..

С web интерфэйсом, честно говоря, я совсем не знаком и о их разработке только догадываюсь.
Можно, конечно же отдать жене, она на java что-нибудь да сотворит, но потом дорого спросит :))

С named pipes ни разу не работал, но читал. Подходящий вариант.
--> to Тимохов_ (24.07.09 15:06) [5]
Особое спасибо.

А вот про COM даже не подумал. Действительно интересно.

Спасибо!

> через TCP может не получиться

А у тебя нет выбора, ибо

> хочется, чтобы оно потом и издалека было доступным

Даже если вместо TCP выберешь UDP, чтобы снизить транспортные расходы, все равно IP не миновать, со всеми вытекающими)

> А у тебя нет выбора, ибо

Тоже верно.

сегодня сделаешь на COM, а завтра захочешь с коммуникатора поадминить свой сервис.

← →
Дмитрий Белькевич (2009-07-27 14:09) [18]

> сегодня сделаешь на COM, а завтра захочешь с коммуникатора
> поадминить свой сервис.

Ну тогда еще одно предложу. SOAP, который над HTTP. Это опять исходя из того, что бы руками всё не "пилить".

А я вот написал свой DCOM и 2 месяца его тестю и отлаживаю... :) Предложил бы купить, но сыро еще )

Обмен данными между сервисом и GUI Найти похожие ветки