Полный ответ на ваш вопрос зависит от того, является ли «сценарий реального мира» сценарием для внутренней сети или Интернета. Хотя WSDualHttpBinding работает в обоих сценариях, есть особенности, о которых следует знать:
Intranet
WSDualHttpBinding будет работать с вашим приложением .NET, используя предварительно настроенный настраиваемый порт в сценарии интрасети, и «Да» служба сможет разрешать базовые адреса клиента и порт для обратных вызовов: как это будет объяснено ниже. Причина, по которой это объясняется ниже, заключается в том, что WSDualHttpBinding в первую очередь предназначен для использования через Интернет.
Дуплексные обратные вызовы в сценарии интрасети, когда вы можете использовать WCF как на клиенте, так и на сервере, лучше всего достигается с помощью NetTcpBinding или NetNamedPipeBinding. Эти привязки используют TCP и ICP соответственно в качестве транспорта (а не HTTP) и пользовательскую двоичную кодировку, поэтому WCF требуется с обеих сторон. Для обратных вызовов к клиенту тот же канал, который использовался для подключения к Сервису через привязку, используется повторно без необходимости открытия нового порта.
Интернет
В сценарии Интернета действительные запросы и ответы HTTP передаются только в одном направлении, HTTP задуман как односторонний протокол. Поэтому при использовании WSDualHttpBinding WCF создает отдельный канал HTTP для обратных вызовов. В ответ на ваш второй вопрос: адрес назначения для этого обратного вызова клиенту по умолчанию состоит из имени хоста клиентского компьютера и порта 80. Если клиент, например, является машиной разработки и на нем установлен IIS, порт 80 будет зарезервирован исключительно в некоторых сценариях, что приведет к конфликтам с вашим прототипом приложения. Это то, для чего это сообщение в блоге представляет решение и для чего предназначено свойство ClientBaseAddress. Независимо от того, какой порт вы используете - по умолчанию или пользовательский, вы должны убедиться, что все межсетевые экраны и маршрутизаторы с обеих сторон настроены правильно, чтобы можно было установить как исходящий канал, так и отдельный канал обратного вызова.
Приложение .NET также может обозначать приложение Silverlight. Из-за того, что приложение Silverlight, запущенное в браузере, не может принимать новые входящие HTTP-соединения, WSDualHttpBinding с отдельным обратным каналом не будет работать. Следовательно, PollingDuplexHttpBinding был создан вначале в Silverlight 2, который можно рассматривать как умный «трюк», позволяющий обойти тот факт, что HTTP является однонаправленным, сохраняя канал запроса открытым в течение длительного времени (длинный опрос) и используя его в качестве обратного канала для перезванивает клиенту. Это имеет ряд последствий как на стороне клиента, так и на стороне сервера, особенно связанных с масштабированием, более подробно см. этот пост из моего блога .
Имея представление о вашем конкретном «сценарии реального мира» и ваших сценариях использования, мы надеемся, что это поможет вам выработать правильную привязку для использования для дуплексных обратных вызовов.