My<cod/>.net
WCF push к клиенту через брандмауэр?
Смотрите также, Как информирует сервер WCF
клиент WCF об изменениях? (Лучше
решение тогда простой опрос, например
Комент или длинный опрос)
Смотрите также, Как информирует сервер WCF клиент WCF об изменениях? (Лучше решение тогда простой опрос, например Комент или длинный опрос)
Мне нужно использовать push-технологию с WCF через клиентские брандмауэры. Это должно быть распространенная проблема, и я знаю, что она работает в теории (см. ссылки ниже), но мне не удалось заставить ее работать, и я не смог найти образец кода, который демонстрирует это.
Требования:
- WCF
- Клиенты подключаются к серверу через порт tcp 80 (netTcpBinding).
- Сервер возвращает информацию с нерегулярными интервалами (от 1 минуты до нескольких часов).
- Пользователи не должны настраивать свои брандмауэры, серверные толчки должны проходить через брандмауэры, у которых закрыты все входящие порты. TCP дуплекс на том же соединении необходим для этого, двойная привязка не работает, так как порт должен быть открыт на клиентском брандмауэре.
- Клиенты посылают сердцебиения на сервер через регулярные промежутки времени (возможно, каждые 15 минут), чтобы сервер знал, что клиент все еще жив.
- Сервер-это IIS7 с WAS.
Решение, по-видимому, дуплекс netTcpBinding. На основании этой информации:
Сохранение открытых соединений в IIS
Но мне еще предстоит найти образец кода, который работает.. Я попытался объединить образцы "Duplex" и "TcpActivation" из образцов WCF Microsoft, но безуспешно. Пожалуйста, кто-нибудь может указать мне пример кода, который работает, или построить небольшой пример приложения. Большое спасибо!
Я нашел несколько решений:
ZeroC Ice GPL с коммерческим вариантом. Только проверили быстро. Выглядит мощнее, чем .NET Remoting, и очень активно развивается.
RemObjects коммерческая, активная разработка, поддерживает все, но, похоже, не имеет всех более продвинутых функций, которые использует GenuineChannels.
GenuineChannels . Он использует удаленное взаимодействие с большим количеством приятных дополнительных функций, наиболее важным из которых является то, что он работает через NATs без необходимости открывать клиентский брандмауэр. К сожалению, кажется, что он очень мертв.
Другим решением является использование потоковой передачи с IIS, согласно этой статье: сохранение открытых соединений в IIS
Клиент делает первое соединение (http с IIS6, tcp с IIS7) с сервером на порту 80, затем соединение остается открытым с потоковым ответом, который никогда не заканчивается.
У меня не было времени экспериментировать с этим, и я не нашел образца, который говорит, что он специально решает проблему брандмауэра, но вот отличный пример, который, вероятно, работает: Streaming XML .
Вы пробовали смотреть на: http://www.codeproject.com/KB/WCF/WCF_Duplex_UI_Threads.aspx
Можете ли вы привести примеры того, что вы уже пытались сделать? С подробностями брандмауэров и т. д., сообщениями об ошибках?
Если и клиент, и сервер могут быть адресованы напрямую, и брандмауэры не являются проблемой, рассматривали ли вы возможность разрешить клиентам регистрировать URL, предоставляющий поддерживаемый контракт. Затем сервер может вызывать эту службу всякий раз, когда ему это нужно, без необходимости устанавливать длительное время работающее (но в основном простое соединение), избегая необходимости в сердцебиении и может быть сделан устойчивым через sessions\connections.
Ты уже пробовал это сделать? DuplexHttpBinding
Он использует технологию интеллектуального опроса, инкапсулированную как пользовательская привязка WCF. Так что он должен работать из коробки.
В большинстве настроек брандмауэра соединение TCP будет разорвано брандмауэром, если он не работает для экономии ресурсов. Тайм-аут простоя, вероятно, не то, что вы можете контролировать. Некоторые из них снесут их, если они будут простаивать, а лимит ресурсов будет нарушен.
Большинство корпоративных сред все равно не позволят ни одной машине установить исходящее соединение TCP.
Кроме того, использование этого механизма означает, что у вас будут проблемы с масштабированием. Я думаю, что более надежное решение-это поставить информацию в очередь и заставить ваших клиентов регулярно опрашивать их. Используйте кэширование, если это возможно, так что последующий опрос клиента получит кэшированные данные из кэша прокси-сервера клиентов, если они его используют.
Если вы должны своевременно передавать данные в субсекундной области (например, финансовые услуги), то рассмотрите некоторую инфраструктуру обмена сообщениями, такую как NServiceBus дистрибьютор на стороне клиента, но это потребует установки клиента...
Так вы пробовали использовать Toredo? Прочитав, что он там появится, это, вероятно, слишком сложно для пользователя, чтобы настроить.
Я не пробовал сценарий, о котором вы говорите, так что я не могу быть слишком полезным, извините. Если все, что вам нужно обойти-это клиентский брандмауэр, вы можете проверить эту запись .
Удачи.