Как я могу автоматически восстановить дуплексный канал, если он получил ошибку?
Я разрабатываю клиент/серверное приложение в .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, я нашел, что включение надежного сеанса приведет к сбою во времени события в большинстве случаев. В качестве альтернативы вы можете отправлять сообщения с биением на обоих концах, чтобы "проверить" неисправный канал.
