Как я могу автоматически восстановить дуплексный канал, если он получил ошибку?

Я разрабатываю клиент/серверное приложение в .NET 3.5 с помощью WCF. В основном, длительное обслуживание клиентов (на нескольких машинах) устанавливает дуплексное соединение с сервером через netTcpBinding. Затем сервер использует контракт обратного вызова клиента для выполнения определенных по требованию oparations, на которые клиент реагирует асинхронно (довольно стандартный материал, который я думаю). Я подклассифицирую класс DuplexClientBase для обработки большей части сообщения.

К сожалению, когда что-то пойдет не так на обоих концах (например, сбой сети, неожиданное исключение и т.д.), канал получает сбои/прерывается, а все последующие операции терпят неудачу. Я обошел это ограничение в недуплексных каналах, создав класс RecoveringClientBase, который автоматически подхватывает, когда клиент сбой и повторяет операцию.

Итак, мой вопрос: существует ли установленный способ определения, когда дуплексный канал сработал? Где я должен проверить это, на сервере или клиенте? В противном случае, какие параметры я должен обеспечить, чтобы соединение было восстановлено?

Обновление: Я ищу несколько советов, специфичных для дуплексных каналов, где сервер может попытаться использовать обратный канал, который был сбит. Таким образом, мне нужно что-то, что будет немедленно повторно подключаться/повторно подписываться, когда что-то происходит с каналом. На данный момент я слушаю событие закрытия канала и воссоздавая его, если состояние ничего не закрыто. Это своего рода работы, но они чувствуют себя взломанными...

Ответ 1

У меня возникла хладнокровие в длительных сеансах (минут-часов). Я не могу быть уверен, что это WCF, я уверен, что его уровень сети.

Я думаю об удалении с дуплексом вообще. Это реальная неприятность, пытающаяся управлять состоянием соединения.

Я думаю о размещении конечной точки службы на клиенте для операций, которые в настоящее время являются частью контракта обратного вызова. Клиент свяжется с сервером с данными о конечной точке, сервер может хранить их где-нибудь (сохраняется или где угодно). Когда серверу необходимо связаться с клиентом, он открывает соединение с клиентом через данные о закрытых конечных точках. В основном, превращение дуплексного соединения в 2 соединения клиент-сервер.

Не отвечает на ваш вопрос, но я чувствую вашу боль.

Ответ 2

У Николаса Аллена из команды WCF есть предложения для этого:

http://blogs.msdn.com/drnick/archive/2007/11/05/custom-transport-retry-logic.aspx

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

Ответ 3

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

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

Я реорганизовал свои приложения на более мелкие элементы работы. Поэтому вместо одного большого длинного предмета теперь у меня появилось много мелких предметов. Конечно, иногда этого достичь невозможно. Затем я должен молиться за стабильные сетевые подключения (исключения могут быть пойманы, поэтому ошибка не является действительно проблемой, я думаю).

Ответ 4

Я думаю, что вам действительно нужно слушать об ошибке. Вы можете прослушивать его на обоих концах, клиентский конец Я думаю, что вы уже обрабатываете, серверный конец - OperationContext.Current.Channel.events.

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

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

В принципе, единственный способ восстановления с неисправного/закрытого канала - заменить его на новый, однако самая ключевая часть - это то, что вы должны действительно обнаружить отключенное ON TIME, я нашел, что включение надежного сеанса приведет к сбою во времени события в большинстве случаев. В качестве альтернативы вы можете отправлять сообщения с биением на обоих концах, чтобы "проверить" неисправный канал.