WCF: как определить клиентскую сторону, если сервер отключает меня

у меня есть самостоятельная служба WCF с сетью.протокол TCP DuplexChannel. На сервере я запускаю следующее, Чтобы отключить клиент:

((ICommunicationObject)client.CallbackChannel).Close();

это работает нормально, но как я могу обнаружить на клиенте, что он был отключен?

Ive подключился к закрытым и ошибочным событиям как на InstanceContext обратного вызова, так и на канале к серверу:

InstanceContext callback = new InstanceContext(callbackImp);
callback.Closed += new EventHandler(callback_Closed);

и

((ICommunicationObject)Channel).Closed += new EventHandler(Channel_Closed);

но ничего не работает. Я никогда не получаю уведомления. Решение im через теперь в обратном вызове должен быть метод, который вместо этого запускает отключение от клиентской стороны. Но я предпочитаю не делать этого таким образом. Я особенно не хочу, чтобы сервер ждал, пока пользователь отключится.

редактировать

Я только что понял, что при отключении от клиентской стороны я запускаю метод в сервис-контракте, который отмечен IsTerminating = true:

[OperationContract(IsTerminating = true)]
void Disconnect();

Я подумал, что это будет то же самое в контракте обратного вызова? Я попытался добавление того же метода к моему обратному вызову, и он прекратил обратный вызов-канал с точки зрения сервера, но я все еще не получил уведомление на стороне клиента...странно!--5-->

редактировать

я узнал больше информации об этом:

когда сервер прерывает обратный вызов канал, недостаток перемещает назад к клиент, клиент ошибается и мы получаем неисправное событие на клиенте.

когда сервер закрывает обратный звонок канал, сеанс все еще открыт пока клиент не выдаст закрытие.

как только клиент закрывает канал вы увидите закрытое мероприятие.

согласно этому заявлению Close-event не запускается mearly путем закрытия канала callbackchannel с сервера, клиент также должен закрыть его. Таким образом, я мог бы запустить близко к клиенту в завершающем Disconnect-методе обратного вызова. Или я мог бы использовать метод Abort на стороне сервера обратного вызова и пропустите использование Disconnect-метода при обратном вызове. Я не знаю, какой из них я предпочитаю честно. Хммм.

редактировать

Я пошел с аварийно-подход. Это казалось самым логичным методом, и он работает очень хорошо. Клиент получает уведомление с Faulted-событием на callback-instancecontext. Милый.