COM начал изучать недавно, так что просьба сильно не бить =)
1. Есть две программы: сервер и клиент, расположенные соответственно на разных машинах (но в пределах одного здания).
— Клиент и сервер соединены постоянно (в данный момент посредством stream сокета).
— Клиент и сервер обмениваются (не реже 1 раза в минуту) запросами и ответами, каждый из которых фактически является некой КОМАНДОЙ, которая расшифровывается и инициирует определенное визуальное проявление на экране =)
Вопрос: насколько целесообразно будет заменить сокеты СОМ классами (аргументация обязательна =), какие в этом плюсы и минусы ?
2. Предположим клиент и сервер соединены с помощью СОМ. Какая реакция будет на разрыв соединения (машина клиента зависла и перезагрузилась) ?
Здравствуйте KarPet, Вы писали:
KP>Привет All !
KP>COM начал изучать недавно, так что просьба сильно не бить =)
ну вот так всегда ... =)
KP>1. Есть две программы: сервер и клиент, расположенные соответственно на разных машинах (но в пределах одного здания). KP>- Клиент и сервер соединены постоянно (в данный момент посредством stream сокета). KP>- Клиент и сервер обмениваются (не реже 1 раза в минуту) запросами и ответами, каждый из которых фактически является некой КОМАНДОЙ, которая расшифровывается и инициирует определенное визуальное проявление на экране =) KP>Вопрос: насколько целесообразно будет заменить сокеты СОМ классами (аргументация обязательна =), какие в этом плюсы и минусы ?
я писал подообную штуку на сокетах и до сих пор жалею что не сделал подобное на DCOM'е (траспортный уровень).
+ DCOM-а —
1)работа через интерфейсы ... то есть взял указатель — и вперед ... ничего не надо мудрить с
обектами в программе и.т.д.
2)автоматическая поддержка связи (не знаю как у тебя реализовано в твоих сокетах — как они реагируют
на разрыв соединения и.т.д) — то есть не то что он автоматически переконнектися — просто сексом
с протоколом связи будет занят DCOM.
3)Подержка COM Event's (если какие-то ограничения — что-то связанное с firewalls). На сокетах же надо
слущать постоянно в отдельном потоке ...
4)Поддержка security ...
-DCOM
1)Портабельность ... я писал сервер для both Win32 & *nix на pure C++. Заюзать DCOM на юнихе ... может
и возможно ...
KP>2. Предположим клиент и сервер соединены с помощью СОМ. Какая реакция будет на разрыв соединения (машина клиента зависла и перезагрузилась) ?
насколько я знаю на internal уровне идет постоянный checking доступности клиента. То есть какая-то обработка dead клиента точно есть. Знающие люди допишут...
Сейчас бы выбирая МЕЖДУ DCOM & sockets я бы выбрал первое.
Здравствуйте Igor Soukhov, Вы писали:
IS>Здравствуйте KarPet, Вы писали:
KP>>2. Предположим клиент и сервер соединены с помощью СОМ. Какая реакция будет на разрыв соединения (машина клиента зависла и перезагрузилась) ? IS>насколько я знаю на internal уровне идет постоянный checking доступности клиента. То есть какая-то обработка dead клиента точно есть. Знающие люди допишут...
DCOM Ping. Реализована, если не ошибаюсь, на уровне RPC. Три попытки через 2 минуты — таймаут. Не изменяемо. Практически выглядит как возврат hresult-а через 6 минут.
Для постоянного отслеживания связи все-таки нужно самому писать регулярный обмен вызовами.
IS>Сейчас бы выбирая МЕЖДУ DCOM & sockets я бы выбрал первое.
Но dcom security может создавать такие проблемы....
KP>2. Предположим клиент и сервер соединены с помощью СОМ. Какая реакция будет на разрыв соединения (машина клиента зависла и перезагрузилась) ?
Согласно MSDN 6 минут должно пройти прежде чем сервер узнает о разрыве коннекции с клиентом — поэтому, если нужно узнать более оперативно, нужно имплементить свой механизм.
Сервер посылает клиенту пинг мессаги (каждые 120 секунд). Если 3 мессаги не пришли — считается что коннекция разорвана. После этого делается релиз всем ссылкам этого клиента.
* thriving in a production environment *
