Как System.Net.Sockets выполняет поиск DNS в контексте поиска службы WCF?

Question

У меня есть веб-приложение и служба WCF, расположенные на одном сервере разработки Windows 2003. Каждый из них имеет свой собственный узел веб-сайта IIS, отвечающий на заголовки хостов drs.displayscreen.web и drs.displayscreen.service соответственно. Файл hosts содержит записи для обоих заголовков, указывающие на 127.0.0.1. На сайте есть сервисная ссылка на drs.displayscreen.service.

Оба приложения отлично работают, когда их пул приложений использует учетную запись «Сетевая служба».

Мне нужно выполнить некоторую обработку COM внутри службы, поэтому я хочу запускать приложения под настроенным удостоверением. Оба сайта работают в новом пуле приложений.

Когда я изменяю удостоверение пула приложений для использования новой учетной записи Windows, созданной для этой цели, я получаю следующее (внутреннее) исключение: [EndpointNotFoundException: не удалось подключиться к http://drs.displayscreen.service/Handler.svc. код ошибки TCP 10060: попытка подключения не удалась, потому что подключенная сторона не ответила должным образом через определенный промежуток времени, или не удалось установить соединение, поскольку подключенный хост не смог ответить 192.168.98.2 : 8080. ]

192.168.98.2: 8080 - это адрес DNS-сервера, который больше не используется. На него не ссылаются нигде в решении. На него вообще не ссылается ipconfig.

Я убедился, что новая учетная запись является членом IIS_WPG, и я выполнил aspnet_regiis -ga. Я также дал учетной записи явное разрешение на чтение файла hosts.

Почему приложение пытается использовать несуществующий DNS-сервер для разрешения временного URL-адреса (drs.displayscreen.service) вместо записи в файле hosts? Это должно быть какое-то разрешение, потому что у него нет этой проблемы при работе под учетной записью сетевой службы. Помогите !!

Answer 1

Ну, похоже, что ответ может включать ошибку в .Net Framework. Я обнаружил сообщение в блоге , в котором сообщалось, что реализация SocketCache.GetSocket в MS .Net может кэшировать недопустимые сокеты, а еще один , который предлагает обходной путь / хак в форме явного параметра конфигурации not-use-proxies.

На самом деле мы не используем прокси-сервер в среде, где возникла эта проблема, но кажется, что SocketCache.GetSocket переопределяется или ведет себя по-другому, когда установлен параметр not-use-proxies. Как ни странно, удаление параметра приводит к возникновению проблемы, поэтому очевидно, что SocketCache не восстанавливается при обнаружении и успешном использовании действительного имени ip / hostname. По словам автора первого поста, упомянутого выше, ошибка не существует в Mono. :)