Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2009.09.27;
Скачать: [xml.tar.bz2];

Вниз

Обмен данными между сервисом и 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 уже всё сделала?


 
Empleado ©   (2009-07-27 12:34) [14]

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

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

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

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

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

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

Спасибо!


 
Сергей М. ©   (2009-07-27 12:44) [15]


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


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


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


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


 
Empleado ©   (2009-07-27 12:46) [16]


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

Тоже верно.


 
Медвежонок Пятачок ©   (2009-07-27 12:48) [17]

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


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


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


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


 
SPeller ©   (2009-07-28 09:03) [19]

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



Страницы: 1 вся ветка

Форум: "Прочее";
Текущий архив: 2009.09.27;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.49 MB
Время: 0.044 c
2-1248034498
tcler
2009-07-20 00:14
2009.09.27
Как организовать scripting host плагин на делфи?


2-1248345894
Bruth
2009-07-23 14:44
2009.09.27
Да вы сами не знаете ответа


15-1248650332
Petr V. Abramov
2009-07-27 03:18
2009.09.27
Центры НТТМ


2-1248338287
b/@.
2009-07-23 12:38
2009.09.27
Можно ли "склеить" несколько гридов для отображения данных разных


2-1248330602
JohnKorsh
2009-07-23 10:30
2009.09.27
Как средствами Dilphi создать точку восстановления?





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский