| 0
- 04.06.2012 - 11:23
|
Добрый день. Впервые решил разработать ком-сервер, и столкнулся в одной очень интересной проблемой. Мой сервер общается с клиентами средствами событий. т.е. создан dispinterface событий на которые подписывается клиент. Делал все по мануалу. Забегая на перед скажу что данная связка реализрована и работает в штатном режиме отлично. Генеральная задача ком-сервака - это коннект к некой софтине через функции реализованные в DLL (реализация моя). Моя DLL периодически вызывает функции из DLL поставляемой с вышеупомянутой софтиной. Связка "моя DLL - DLL API сторонней софтины" понадобилась чтобы нарастить некий функционал. Связка "ком-сервер - моя DLL" понадобилась чтобы уйти от ограничения "одна DLL - один клиент" (это будет системы роботизированного трейдинга на бирже). Итак, ком-сервер коннектится к DLL (объект работающий с DLL реализует паттерн Синглтон), а неопределенное количество клиентов в ком-серверу. Все получается складно. НО В API DLL сторонней есть функции которые работают асинхронно. В обработчики этих callback-ов я прописал вызов внешних собственных callback-ов с ком-сервака, чтобы передавать через них нужные мне параметры. И они не работают. Если я свой внешний callback вызываю в функции которая непосредственно вызывается с сервака - все корректно, клиенты получают события инициируемые этими callback-ами на серваке. А если мой callback прописан в обработчике callback-а передаваемого в DLL API сторонней софтины, то клиенты просто не видят сгенеренные события... В ком-серваке событие инициируется и отправляется подписчику: procedure TRobotArmyServerAutomation.OnResultOperations(ACod eResult: Integer; ADescription: LPCTSTR); begin if FEvents <> nil then FEvents.OnResultOperationsEvent(ACodeResult, ADescription); end; , а подписчик их тупо не видит... как-будто сервер молчит. В какую сторону копать подскажите плиз... В чем может быть причина? Сервер, клиент реализован на delphi. DLL на с++...     | |
| 1
- 04.06.2012 - 11:25
| В заголовке темы: "СОМ".... копи-паст блин. | |
| 2
- 04.06.2012 - 21:26
|
В общем прикол в том, что сервак, генерируя события видит клиента, но клиент не может его услышать из-за особенностей STA (настройки фабрики tmApartment). Как только я указал в параметрах фабрики классов tmFree или tmBoth - клиент прозрел на нужные события. Впринцыпе и сервер и клиент будут однопоточными, поэтому AV быть не должно. Если есть корректировки к моим умозаключениям буду только рад. | |
| 3
- 05.06.2012 - 09:51
| Пачиму Дельфи??? :))) | |
| 4
- 05.06.2012 - 18:25
| 3-And justice for all > Потому что приложения которые преобразовались в com-клиенты изначально (очень давно) были написаны на делфи, и далее поддерживаться будут делфистами как, собственно, и сам сервак. :) | |
| 5
- 06.06.2012 - 06:09
| если в DLL передается функция, вызываемая ею при определенных обстоятельствах, и внутри этой функции производится вызов функций, переданных клиентами в COM-объект, то все должно работать. однако, если в этих клиентских функциях происходит вызов методов STA COM-объекта, то они не пройдут - объект блокирован вызовом со стороны DLL и вызов его метода будет ожидать снятия блокировки. естественно, ожидание будет вечным. если все необходимое клиентские функции получают через аргументы и не обращаются к COM-объекту, то, вроде должно работать и с STA COM-объектом. | |
| 6
- 06.06.2012 - 13:37
|
5-vxg > У меня следующая связка (есть 2 совмещенных варианта): 1-й варинат) В dll передается некие callback-и, обработчиками которых являются процедуры на базе ком-сервера. Внутри этих процедур идет вызов событий объекта-синглтона (не COM). Далее существует COM-объект, который при инициализации передает ссылки на свои события событиям синглтона. Таким образом. В событиях COM-объекта релизована работа с FEvents (рассылка событий). Все это выполняется в штатном синхронном и отлично работатет. 2-вариант) В DLL есть функции которые выполняются асинхронно. Т.е. функция может отработать в лююбой момент вне зависисмости от того когда ее это попросили сделать. В этой асинхронной функции прописан callback работающий по пронципу описанному выше. и эта схема не работала. Ре работала по причине того, что DLL выполняет асинхронные функции в другом потоке, поэтому при использовании потоковой модели основанной на STA, сервер инициируя событие терял истенный указатель на подписчика. поэтому на стороне сервера все происходило как положено, а клиент просто напросто не видел то что в него прилетает. Какими то специальными способами я это не проверял, но на практике похоже что я прав... Надо проверить чтоб прийти к однозначности утверждения )))) | |
| 7
- 06.06.2012 - 17:41
| как то очень заумно. я даже не знаю что такое события) я думал ком объект при создании загружает длл и передает ей указатели на функции обратного вызова (обычные функции живущие в одном модуле с ком объектом). длл когда ей вздумается вызывает эти функции а изнутри этих функций идет обращение к ком объекту ну а уже оттуда обращения к пользовательской стороне через зарегистрированные на ком объекте функции обратного вызова индивидуальные для каждого пользователя ком объекта. что такое события (для расширения кругозора)? вызовы реально проходят и улетают в никуда (ведется лог и он подтверждает что прога жива) или может просто она все таки висит на этом месте? | |
| 8
- 06.06.2012 - 22:06
| drmiller, http://rsdn.ru/article/com/apartmnt.xml - вот, почитай, может поможет. Заодно и еще там кучу статей найдешь, возможно по теме. :) | |
| 9
- 07.06.2012 - 12:15
| 8-And justice for all >Спасибо, хорошая статья. | |
Интернет-форум Краснодарского края и Краснодара |
