Насколько надежно привязанное к сети бесконечное значение receiveTimeout? - PullRequest
1 голос
/ 22 января 2011

У меня есть дуплексная служба WCF, которая использует согласованное соединение по именованному каналу между службой и клиентом.Это своего рода система публикации / подписки, в которой клиент вызывает службу подписки и помещается в список подписки.Затем служба вызывает определенные собственные методы обновления, которые передают обновление клиенту (-ам) через обратные вызовы.

Я установил recieveTimeout для привязанного по сети pipebinding к «бесконечному».Могу ли я разумно полагаться на то, что эта связь будет открыта навсегда?Что еще более важно, существуют ли ситуации, когда канал выйдет из строя вне тайм-аутов?

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

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

1 Ответ

3 голосов
/ 22 января 2011

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

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

...