Здравствуйте, Иван Андреев aka Ivan, Вы писали:
ИАA>Статья:
ИАA>Перехват методов COM интерфейсов – 2Автор(ы): Иван Андреев aka Ivan
Дата: 11.07.2005
Эта статья является продолжением статьи “Перехват методов COM интерфейсов”, опубликованной в RSDN Magazine #1’2004. В предыдущей части статьи описан перехват вызовов automation-совместимых интерфейсов. В этой части описывается решение, позволяющее перехватывать и не-automation-совместимые интерфейсы.
Требуется знание COM и C++.
ИАA>Авторы:
ИАA> Иван Андреев aka Ivan
ИАA>Аннотация:
ИАA>Эта статья является продолжением статьи “Перехват методов COM интерфейсов”, опубликованной в RSDN Magazine #1’2004. В предыдущей части статьи описан перехват вызовов automation-совместимых интерфейсов. В этой части описывается решение, позволяющее перехватывать и не-automation-совместимые интерфейсы.
ИАA>Требуется знание COM и C++.
Спаибо за статью. На основее мы создали свой транспорт. Теперь наши проекты работают и на XP SP2 и вообще через интернет. Конечно, того, что в статье, было, мягко говоря, недостаточно, но направление было верное.
Здравствуйте, Tom, Вы писали:
A>>Спаибо за статью. На основее мы создали свой транспорт. Теперь наши проекты работают и на XP SP2 и вообще через интернет. Конечно, того, что в статье, было, мягко говоря, недостаточно, но направление было верное.
Tom>Интересно узнать детали, у меня на основе интерсепторов фактически есть своя реализация DCOM-а с поддержкой каналов самописных итп... Вы примерно тоже самое сделали?
Да, но только не на интерцепторах. У нас был огромный сетевой проект на DCOM-е, который чуть не умер при появлении sp2. Надо было не переписывая всего пересадить его на свой транспорт. Проект написан был на C++ поэтому за oleautomation по понятным соображениям никто не гнался. Поэтому статья хоть и дала направление, но не совсем верное. За три года исследований DCOM-а был создан транспорт, даже больше чем транспорт — от DCOM-а мы оставили лишь его маршаллинг, да и то частично, но в итоге встроились во всю архитектуру так гармонично, что для проекта изменение было лишь одно — с одной стороны CoCreateInstanceEx заменили на свой аналог, с указанием ip, порта, и настроек прокси, а на серверной стороне запуск "слушателя" входящих соединений. т.е. в тот огромный проект добавились лишь несколько строк кода и мы вышли не только за пределы sp2 но и в интернет без всяких VPN. Сейчас у нас есть сетап для сторонних разработчиков которые могут поставить себе на клиент и сервер по 4 наших dll и забыть про VPN и открытие дыр в безопасности. Более того исследования показали что в локальной сети наш SLDCOM работает быстрее чем родной DCOM. + У нас нет сетевых пингов так что мы не засоряем эфир. + есть возможность сжимать общий трафик клиент-серверного соединения, шифровать его, "проталкивать" в сетях с высокой латентностью — так называемый AntiNaggle алгоритм. И мы уже оттестировали эту зверюгу на нашей системе безопасности
www.goal-city.ru (а в современных конфигурациях она поддерживает до 300 камер на одного клиента (где то по 3 удаленных com-интерфейса на камеру)) т.е. тестик такой некислый и при этом она работет неделями без сетевых отказов...
В общем если кому то надо такое чудо, пишите: araud@goal.ru
Еще раз повторю: никаких изменений в проекте, только надо вызывать не CoCtreateInstanceEx а нашу функцию.
interface ICOMBridge : IDispatch{
//для сервера
HRESULT StartServer(USHORT nPort);
HRESULT StopServer();
//для клиента
HRESULT CoCreate(
BSTR szServerName, USHORT nPort,
BSTR szProgIdOrCLSID,
BSTR szProxy,// NULL or empty string means "no proxy"
//otherwise use standart url format <Scheme>://[<UserName>:<Password>@]<HostName>:<PortNumber>
//<Scheme> can be "https" or "socks"
[out,retval] IUnknown ** ppObject
);
};
интерфейс нарочно сделан дуальный IDispatch, так что это работает даже из-под скриптовых языков.
Если есть вопросы, wellcome
