В COM все это делается через reference count. Т.е. Соединяясь клиент вызывает AddRef() а отсоединяясь вызывает Release(). Клиент не идентифицируется. Просто считаются ативные соединения. Тоже самое должно происходить и в DCOM. Проблемы возникают тогда, когда клиент забывает вызвать Release() или умирает не успев. Но это на одном компьютере. В вашем случае могут еще и провода перерезать.

Существуют и более продвинутые механизмы. Например связка интерфейсов IDataObject - IAdviseSink. Если клиент хочет получать уведомления от сервера, то он должен иметь IAdviseSink, а сервер - IDataObject. Для того, чтобы подписаться на уведомления клиент вызывает IDataObject->DAdvise сервера и получает назад идентификатор соединения. А когда хочет отсоединиться вызывает IDataObject->DUnadvise и передает в нем тот самый идентификатор соединения. Таким образом сервер может вести учет клиентов.
Причем связи могут быть как горячими, когда само уведомление содержит обноаленные данные, теплыми, когда сообщается что данные изменились но не сами данные так и холодными, когда клиент опрашивает сервер. Все это нормально работает в СОМ, будет ли работать в DCOM не знаю, возможно придется писать свой Marshaling.

Проблемы остаются теми же - когда клиент забывает вызвать Release() или умирает не успев + провода...

Вообще, в коммуникационных системах существует стандартное решение подобной проблемы: Hartbeat. Т.е вы посылаете предельно простое сообщение и ожидаете ответ, если ответа нет, то соединение потерянно. В СОМ можно, например, унаследоваться от IAdviseSink, добавив к нему метод HartBeat , который должен возвращать S_OK. И вызывать его периодически. Посмотреть, что он вернет, если разорвать провода.

Petro123 AndreiNzВообще, в коммуникационных системах существует стандартное решение подобной проблемы: Hartbeat. Т.е вы посылаете предельно простое сообщение и ожидаете ответ, если ответа нет, то соединение потерянно. В СОМ можно, например, унаследоваться от IAdviseSink, добавив к нему метод HartBeat , который должен возвращать S_OK. И вызывать его периодически. Посмотреть, что он вернет, если разорвать провода.
думаю можно ещё проще:


Пожалуй, Да.

Только в данном случае вы вызываете 2 метода вместо одного. А, принимая во внимание то, что общение еидет через сеть, один метод может оказаться эффективнее.

Вообще-то я говорил про HeartBeat как отдельный метод, а вовсе не про вызов одного из Release или AddRef в отдельности.

И почему это но не работает в WAN? Если реализация HeartBeat сделана через UDP, то у вас будут проблемы, Если же используется TCP/IP, то проблем быть не должно. Вы же говорите о DCOM, который сидит на TCP/IP.

Для таймера, в крайнем случае можно запускать отдельную Thread, которая ничего не делает, а только спит определенное время, а когда просыпается, то делает то, что вам нужно и умирает. Если же клиент откликается до того как истекет интервал, то вы убиваете Thread.

rodb,

Я сам DCOM-ом не пользуюсь. Предпочитаю использовать TCP/IP для межкомпьютерного взаимодействия. А локально использую СОМ.

Из того, как я понимаю ситуацию, сервер (не только DCOM, но и любой сервер) желательно держать в памяти в постоянной готовности к запросам. То есть то что сервер не убивается, может оказаться положительным фактором.

Спасибо, за поздравления.

Вас так же поздравляю с наступающим Новым Годом.

Андрей.