Понимаю, что тема не новая и на первый взгляд есть ответы вроде этого, но если посмотреть повнимательнее, авторы сего tutorial'а последовали традиции обойти острые углы. По такой схеме всё хорошо только если callback заменяет возвращаемое значение, но если нужно послать уведомление о событии, момент наступления которого на клиенсткой стороне определить невозможно, то оказывается, что этот канал оказывается недоступен на сервере, а когда его восстанавливать на клиентской стороне, не ясно. Подскажите, пожалуйста, какое событие на клиенсткой стороне действительно вызывается при закрытии канала обратного вызова или какие есть другие решения, применимые в реальных, а не только в тестовых условиях.

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

тыц

Ну и да кучи:
http://stackoverflow.com/questions/4317754/wcf-how-to-detect-client-side-if-the-server-disconnects-me
http://stackoverflow.com/questions/16922367/c-sharp-wcf-duplex-fire-an-event-when-a-client-disconnect
http://stackoverflow.com/questions/1643476/wcf-closing-a-duplex-servicehost-blocks-for-closetimeout-duration-if-closed-wh

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

> какие есть другие решения, применимые в реальных, а не только в тестовых условиях.

В реальных условиях, если потеря событий от сервера критична, применяют различные механизмы персистентной подписки на события. Например, netMsmqBinding. Или messaging publish-subscribe. Или просто какой-нибудь message broker.