Wcf callback net tcp duplex только 1 путь неисправен

Question

У меня есть собственный wcf-сервис, использующий дуплексный обратный вызов net tcp

на стороне клиента, я прослушиваю сбойное событие на Channel и ChennelFactory.когда канал вышел из строя, клиент будет воссоздавать канал и повторно подписываться.

на стороне сервера, я сохраняю канал обратного вызова и сохраняю ссылку на канал, вызывая OperationContext.Current.Channel, чтобы я мог прослушивать неисправный изакрытое событие на этом канале.При сбое сервер удалит этого подписчика.

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

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

Включен надежный сеанс, и время ожидания очень велико (2 часа) (может быть, это может привести к тому, что клиентский конец не будет достаточно быстро обнаруживать ошибку?)

Может кто-нибудь объяснить, почему это происходит?

Еще один вопрос: почему это так?У меня подключено 40 клиентов, но сервер обнаружил случайный сбой клиента в случайное время.

Answer 1

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

Во всяком случае, в своем проекте я пришел к выводу, что полагаться на события с ошибочными каналами недостаточно надежно. Поэтому я регулярно пингую всех подписчиков с сервера через канал обратного вызова. Если клиент не отвечает в течение срока ожидания, он удаляется из списка подписчиков.

Со стороны клиента вы также можете перехватывать исключения тайм-аута и заново создавать канал, если это необходимо.

Answer 2

Не виноваты длительные тайм-ауты, в этом я уверен, потому что я нахожусь в идентичной ситуации, и у меня тоже возникла проблема с короткими тайм-аутами.

Работать с неисправными каналами на сервисной стороне легко. Вы можете пробовать / ловить вызов обратного вызова и обрабатывать его только тогда, когда это действительно необходимо.

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