Блог

Мы используем дуплексный контракт для одной функции в нашем еще не выпущенном LOB-приложении корпоративного уровня, которое использует толстый клиент, построенный на WPF, и сервер, построенный на WCF.

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

Я начал использовать wsHttp и wsDualHttp, но тем временем понял, что дуплексные соединения через веб-прокси (и с обходом NAT) на самом деле невозможны.

Теперь я думаю: почему я не могу настроить tcp-туннель (используя собственное программное обеспечение, поддерживающее веб-прокси, используя HTTP CONNECT) и получить лучшее из обоих миров — поддержку прокси, скорость и безопасность?

Казалось бы, это обычное требование.

Ваши параметры не являются обширными. Служебная шина Microsoft, вероятно, ваш лучший выбор, если она подходит для ваших нужд. Другие варианты:

• VPN: Довольно понятно.
• SSH: SSH имеет встроенную функциональность туннелирования. Если у вас только небольшое количество подключений, вы могли бы использовать готовые SSH-клиент и сервер, но при большем количестве подключений трудно гарантировать, что все они остаются надежно подключенными. Несколько компаний создают SSH-компоненты, которые вы могли бы использовать (они не подходили для наших нужд), но они больше ориентированы на использование SSH для удаленного выполнения, чем туннелирование.
• Самодельный TCP-туннель, который представляет собой большую работу. Не невозможно, но большая работа. И потребуется огромное количество тестов, чтобы убедиться, что вы все поняли правильно.

Что касается запуска WCF через туннельное соединение, если вы пойдете этим путем, у вас не возникнет никаких проблем. Все привязки и функции работают — обратные вызовы, надежность, безопасность сообщений, безопасность транспорта, транзакции, все работает просто отлично.