Здравствуйте, SPeller, Вы писали:
SP>1. Моей задаче полтора месяца от ее постановки, через 3 дня поисков в гугле я знал всё то, что описано в статье, хотя на начало поисков я не знал вообще ничего ни про маршалинг, ни про прокси-стабы. Еще за месяц я реализовал полноценный клиент-сервер дком. До завершенного продукта ему еще предстоит пройти долгий путь, но уже сейчас он работоспособен. Фактически — это своя реализация дком, выдергивающая из системы функционал стандартного маршалинга. Правда, есть свои ограничения. Как оказалось, не маловажные, но решаемые.
Интересно какие ограничения? У нас можно любой проект пересадить на ComBridge за 5 мин, не меня только 1 строчку кода на клиенте и добавляя 1 на сервере. т.е. под ComBridge не надо писать специальный код. Наши приложениея имеют переключатель DCOM\ComBridge и даже не знают через что работают. Огромная распределенная система.
SP>2. Да, выкладывать годы работы не целесообразно. Но, как я уже писал выше — нужно сделать для статьи работоспособный пример реализации, который имел бы сильные играничения и упрощения в функционале, но показывал суть метода, которым достигнуто удаленное взаимодействие. Только тогда от статьи будет польза для общественности.
Пример работы с нашей либой дан. А для того собрать работоспособный пример from scratch надо написать еще код передающей(например сокетной) подсистемы. Ты какой пример имел ввиду?
SP>Со временем я, возможно, тоже напишу статью по изложенным выше принципам, идея такая есть, но планов таких пока нет. Идея еще не вызрела, да и достаточно времени пока не предвидится.
A>Интересно какие ограничения? У нас можно любой проект пересадить на ComBridge за 5 мин, не меня только 1 строчку кода на клиенте и добавляя 1 на сервере. т.е. под ComBridge не надо писать специальный код. Наши приложениея имеют переключатель DCOM\ComBridge и даже не знают через что работают. Огромная распределенная система.
У нас готовой системы нет, поэтому можно варьировать. Одним из принципов была независимость от реестра. Использую перехват API функций, который нужно сделать до инициализации COM-RPC runtime, который запоминает адреса оригинальных функций и после этого момента перехватить то что надо не удастся. Если только не использовать правку первых байт оригинальной функции, но от этого я решил отказаться.
Кроме того, моя система одновременно работает как со стандартным DCOM, так и со своим. А ваша?
A>Пример работы с нашей либой дан. А для того собрать работоспособный пример from scratch надо написать еще код передающей(например сокетной) подсистемы. Ты какой пример имел ввиду?
И это тоже. Возможно, я мыслю дельфийскими критериями, по которым можно за 20 минут накидать простой клиент-сервер на TServerSocket и TClientSocket, не знаю сколько времени занимает такая задача на сях. Больше всего же важно как заставить маршалить интерфейсы. Циферки-буковки бегают без проблем. Так же, есть проблема вложенных вызовов, когда клиент вызывает метод сервера, а тот делает вызов клиента.
A>А времени эта штука у тебя съест немеряно.
Не сомневаюсь. Поэтому и не собираюсь за это хвататься сейчас.
Здравствуйте, SPeller, Вы писали:
A>>Интересно какие ограничения? У нас можно любой проект пересадить на ComBridge за 5 мин, не меня только 1 строчку кода на клиенте и добавляя 1 на сервере. т.е. под ComBridge не надо писать специальный код. Наши приложениея имеют переключатель DCOM\ComBridge и даже не знают через что работают. Огромная распределенная система.
SP>У нас готовой системы нет, поэтому можно варьировать. Одним из принципов была независимость от реестра. Использую перехват API функций, который нужно сделать до инициализации COM-RPC runtime, который запоминает адреса оригинальных функций и после этого момента перехватить то что надо не удастся. Если только не использовать правку первых байт оригинальной функции, но от этого я решил отказаться.
SP>Кроме того, моя система одновременно работает как со стандартным DCOM, так и со своим. А ваша?
Читай выше
A>>Пример работы с нашей либой дан. А для того собрать работоспособный пример from scratch надо написать еще код передающей(например сокетной) подсистемы. Ты какой пример имел ввиду?
SP>И это тоже. Возможно, я мыслю дельфийскими критериями, по которым можно за 20 минут накидать простой клиент-сервер на TServerSocket и TClientSocket, не знаю сколько времени занимает такая задача на сях. Больше всего же важно как заставить маршалить интерфейсы. Циферки-буковки бегают без проблем. Так же, есть проблема вложенных вызовов, когда клиент вызывает метод сервера, а тот делает вызов клиента.
A>>А времени эта штука у тебя съест немеряно.
SP>Не сомневаюсь. Поэтому и не собираюсь за это хвататься сейчас.
Если ты на делфи, читай про интерсепторы. У нас задача сложнее — надо все интерфейсы чтобы работали, а не только OLE.
Я в статье сделал простенький пример, он правда не передает данные далеко, просто показывает что вклинится реально.
A>Если ты на делфи, читай про интерсепторы. У нас задача сложнее — надо все интерфейсы чтобы работали, а не только OLE. A>Я в статье сделал простенький пример, он правда не передает данные далеко, просто показывает что вклинится реально.
Дык у нас тоже все будут работать. И то что в системе зарегано, и своё, лишь бы typelib был доступен. Система сама прокси-стабы нам изготовит для маршалинга. А вот как и где ловить этот момент для пересылки — тут уже другой разговор. Здесь-то и интереснее всего.
A>Наши приложениея имеют переключатель DCOM\ComBridge и даже не знают через что работают
Я имел ввиду можно ли с вашим переключателем работать в одном процессе одновременно со стандартным DCOM и ComBridge?
Re[2]: COMBridge DEMO
От:
Аноним
Дата:
30.05.09 03:27
Оценка:
Здравствуйте, Figaro, Вы писали:
F>а 500 убитых президентов немного ли?
Лет 5 назад я занимался этим-же, многое было сделано, но потом забросил в виду слишком сомнительных коммерческих перспектив. Не думаю, что ситуация с тех пор в этом плане улучшилась Хотя кто знает, если всерьёз займутся продвижением, то может и прорвутся, так что авторам можно только пожелать удачи
Здравствуйте, SPeller, Вы писали:
A>>Наши приложениея имеют переключатель DCOM\ComBridge и даже не знают через что работают
SP>Я имел ввиду можно ли с вашим переключателем работать в одном процессе одновременно со стандартным DCOM и ComBridge?
Да, конечно, только интерфейсы полученные прямо или косвено из ComBridge работают через него.
т.е. если создаешь объект через ComBridge то все его интерфейсы и все что из него можно получить будет на канале ComBridge с тем компом откуда получили первый объект. И при этом можно из одного процесса с любым количеством компов по ComBridge связаться. И DCOM обычный и COM можно использовать. Т.е. сядешь на тот канал на котором создал первый объект. Создал на DCOM -на нем и будешь.
Здравствуйте, SPeller, Вы писали:
A>>Если ты на делфи, читай про интерсепторы. У нас задача сложнее — надо все интерфейсы чтобы работали, а не только OLE. A>>Я в статье сделал простенький пример, он правда не передает данные далеко, просто показывает что вклинится реально.
SP>Дык у нас тоже все будут работать. И то что в системе зарегано, и своё, лишь бы typelib был доступен. Система сама прокси-стабы нам изготовит для маршалинга. А вот как и где ловить этот момент для пересылки — тут уже другой разговор. Здесь-то и интереснее всего.
я говорю, посмтори статью про интерцепторы тут на rsdn. Там уже все сделано что необходимо для Delphi.
Но вообще конечно мне не понтно желание работать с Delphi когда есть шарп. А в дотнете решена поблема транспортов.
Здравствуйте, Figaro, Вы писали:
F>а 500 убитых президентов немного ли?
Давай рассуждать так: что для Вашей конторы выгоднее, содерджать программера довольно высокого уровня несколько лет, пока он изучает все плохо документированные особенности DCOM и потом еще долго собирает все знания в соложнейший проукт, или отдать за готовое, прошедшее суровое тестирование решение всего половину его месячной зарплаты?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Figaro, Вы писали:
F>>а 500 убитых президентов немного ли?
А>Лет 5 назад я занимался этим-же, многое было сделано, но потом забросил в виду слишком сомнительных коммерческих перспектив. Не думаю, что ситуация с тех пор в этом плане улучшилась Хотя кто знает, если всерьёз займутся продвижением, то может и прорвутся, так что авторам можно только пожелать удачи
спасибо!!! Действительно, раскрутка — дело сложное.
Здравствуйте, araud, Вы писали:
A>Здравствуйте, Figaro, Вы писали:
F>>а 500 убитых президентов немного ли? A>Давай рассуждать так: что для Вашей конторы выгоднее, содерджать программера довольно высокого уровня несколько лет, пока он изучает все плохо документированные особенности DCOM и потом еще долго собирает все знания в соложнейший проукт, или отдать за готовое, прошедшее суровое тестирование решение всего половину его месячной зарплаты?
К тому же вывести проект из локальной сети в интернет за 500$ и 1 час работы, да еще параллельно избавившись от проблем с настройками безопасности, да еще ускорив сетевой обмен данными, помоему, вполне заманчиво. Я думаю, когда пойдут продажи, мы еще повысим цену.
Здравствуйте, Figaro, Вы писали:
F>Выы принципе правы, но видимо у меня еще советско-российский менталитет
Да я прекрасно Вас понимаю. Мы написали сами кучу всего того, что можно было просто купить для наших проектов
Это зависит от политики фирмы. Кстати, потестите демку, оцените — может пригодится в Ваших проектах?
Здравствуйте, Figaro, Вы писали:
F>А почему ограничение на один порт per process?
На сервере. На клиенте можно поключатся к любому количеству серверов.
На сервере я не вижу смысла открывать несколько портов делающих одно и тоже. Нужно будет в файрволы по несколько потров прописывать, а реальной выгоды я не вижу.
Если Вы сможете привести пример, как может пригодится несколько портов у сервера, я сделаю несколько
На деле, там у нас один из компонентов — полноценный вебсервер, открыть на нем еще порт дело не хитрое. Просто пока незачем
A>я говорю, посмтори статью про интерцепторы тут на rsdn. Там уже все сделано что необходимо для Delphi. A>Но вообще конечно мне не понтно желание работать с Delphi когда есть шарп. А в дотнете решена поблема транспортов.
Что-то я не нашел ничего с дельфийскими примерами. Видел только статью про интерсептор в первой части про перехват методов COM интерфейсов, но там всё тот же си. Да и вообще, какая разница на чем писать? У каждого языка есть свои плюсы. У нас задействованы плюсы дельфей. Тем более, что 2009-я стала достаточно вкусной. Кроме того, против дотнета у нас есть свои моменты. Да и свой транспорт можно будет расширить и общаться хоть по почте, добавлять любое шифрование. Я не стал завязываться на TCP и сделал основу расширяемой. Можно пайпы задействовать для общения внутри компа, можно вообще прямые вызовы делать если в одном процессе клиент и сервер. Да, это всё смахивает на то, что уже реализовано в COM, но я делаю упор на то, что приложение не зависит от регистраций компонент в реестре. Запустил — заработало, не ругается что "интерфейс не зарегистрирован". Это во-первых, а во-вторых, у юзера не всегда могут быть права на запись в реестр. И вообще, я противник загаживания реестра
A>если создаешь объект через ComBridge то все его интерфейсы и все что из него можно получить будет на канале ComBridge с тем компом A>откуда получили первый объект
У меня так же ) Можно создавать сколько угодно серверов и клиентских соединений. Где объект создался, там и будет висеть связь с ним.
Еще вопрос — у вас потоковые модели поддерживаются все?
Хотя кто знает, если всерьёз займутся продвижением, то может и прорвутся, так что авторам можно только пожелать удачи 
