Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

регистрация сервера приложения DCOM на клиенте

kostik78ua © (2002-07-29 11:41:00)
Помогите новичку!
Создал сервер приложения svr1.dll (а также клиента). На одной машине сервер и клиент коннектятся нормально, но только развел на разные машины, пишет "Сервер не зарегистрирован".
Прочитал, что на всех клиентских местах надо зарегистрировать.
Что-то типа: regsvr32 svr1.dll Но ведь на клиентской машине этой dll-ки НЕТ. Как прописать эту строку?

Pitek (2003-04-21 16:54:00) [1]
DLL - это СОМ или СОМ+
Может лучше дейстивельно DCOM написать? ;-)

А. Н. Оним (2) (2002-07-29 12:26:00) [2]

DLL действительно должна быть зарегистрирована как на клиентской, так и серверных машинах. Клиенту она сама по себе не нужна (так как не к ней он будет обращаться), но важна регистрация интерфейсов коклассов этой DLL в реестре клиента (может быть, зарегистрировав её раз, можно потом и удалить с диска).
Дело в том, что SCM на клиентской машине будет загружать в адрессное пространство клиента прокси кокласса сервера, к которому клиент обращается. Откуда взять Proxy - SCM решает на основе зарегистрированных интерфейсов. Каждый интерфейс (из HKEY_CLASSES_ROOT\Interfaces) может содержать вкладку ProxyStubClsid32 - указывающий на Clsid своего прокси. Если твой интерфейс подходит под определение OleAutomation, то пойдёт стандартный Proxy (его CLSID {00020424-0000-0000-C000-000000000046} - самый самый распространённый среди Proxy CLSID'ов), а если нет, то придётся строить свою Proxy/Stub Dll и регистрировать её как на клиенте, так и на сервере. Можешь поэкспериментировать, какой сюрприз вылезает, если на клиенте нет ProxyStub DLL, но на сервере есть (IUnknown ты получишь, но только его).

А. Н. Оним (2002-07-29 12:10:00) [3]
Сервер в DLL в случае одной машины для клиента и сервера грузится в адрессное пространство клиентского процесса в момент создания экземпляра CoClass'а. Поэтому на одной машине у тебя всё и работало.
В случае разных машин, транспортировка DLL-сервера по сети не предполагается на машину клиента с последующей загрузкой в его адрессное пространство. Но в то же самое время, DLL должна получить своё "место жительства" в чьём то адрессном пространстве для своей работы. В DCOM это реализовано следующим образом. На сервере по запросу должен подняться хостящий процесс, который загрузит твою DLL к себе и уже с ним ты и будешь общаться. Такой хостинг выполняет утилита dllhost.exe;
Для того, чтобы настроить твою DLL для хостинга каким-то приложением при запросе с другой машины, необходимо прописать в реестре под AppID ключ DllSurrogate с именем хостящего процесса [dllhost.exe](кажется так, точно не помню, уточни где-нибудь).
Но даже так мало кто делает потому, что DLL имеет выгоды по скорости вызова методов только в InProc взаимодействии, что возможно только на одной машине. В случае нескольких станций работа с ней уподобляется работе с сервером в EXE, в качестве которого и будет выступать DllHost. Поэтому пиши сразу сервер в EXE.
Но даже здесь проблемы не закончатся, а только начнутся. Предстоит настроить политику безопасности серверной машины. Наиболее удобно это сделать при помощи утитилиты dcomcnfg.exe
Твой сервер должен давать клиенту права на доступ (и возможно) запуск. Хорошо, если у тебя в сети стоит контроллер домена - тогда пользователя клиентской машины можно будет создать в домене и на сервере дать ему права, но если контроллера нет, тогда пользователь клиента (его учётная запись) должен быть продублирован вместе со своим паролем на сервере.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »