Здравствуйте alexm1202, вы писали:

A>Гм, насколько я понял CoCancelCall тебе не подходит, он предназначен для того чтобы _попросить_ сервер быстренько вырнуться из вызова, т.е. сервер для этого должен быть жив. Слушай, а с чего ты взял, что DCOM-вызовы не возвращаются по timeout?

Во-первых, уточню, у упрожняюсь на между двумя Windows 2000 системами. И я использовал Apartment Thread Model для клиента и сервера.

Ну что не возвращается, я узнал просто — создал client/server DCOM приложение, и сделал так что при вызове клиентом сервера, методе сервера запускается for(;){}, так что он никогда контроль не возвращает. При этом если сервер тормозишь дебагером, то клиент узнает про то что сервер ушел, а вот если тупо нажимаешь Reset на компе, то клиент ничего не замечает. Я в порядке эксперемента пару раз ждал больше 10 минут — и клиент продолжал весеть, даже уже тогда когда компьютер, на котором был DCOM сервер, загружался обратно.

А если верить этой статье — то вроде timeout должен наступать максимум в течение 90 сек., но похоже что-то не так. При чем в других источника MC рассказывает про то что они проверяют DCOM соединение, и если в течение 6 мин (по умолчанию) связь с объектом не восстановится, то они забывают про него — очевидно, для этого случая, это тоже не работает.

Я думаю CoCancelCall может оказаться правильным направлением — так как для того что-бы сказать серевру, что надо прервать обработку вызова, надо к серверу обратиться, и тут должен произойти как минимум RPC timeout. Может я не прав, но похоже что при посто вызове, DCOM посылает сообщение серверу, и сидит в каком-то цикле обработки приходящих сообщении, и ничего больше не проверяет. А так как сервер умирает быстро, и без возможности сообщить клиенту что он отвалил, клиент продолжает сидеть в этом цикле до упора.