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

Question

У меня есть веб-приложение и служба WCF, размещенные на одном сервере разработки Windows 2003.У каждого из них есть собственный узел веб-сайта IIS, отвечающий на заголовки хостов drs.displayscreen.web и drs.displayscreen.service соответственно.Файл хостов содержит записи для обоих заголовков, указывающие на 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.Я также предоставил учетной записи явное разрешение на чтение файла хостов.

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

Answer 1

Что ж, похоже, что ответ может быть связан с ошибкой в ​​​​инфраструктуре .Net.я нашел запись в блоге это подсказало мне тот факт, что реализация SocketCache.GetSocket в MS .Net может кэшировать недопустимые сокеты и Еще один это предлагает обходной путь/взлом в виде явного параметра конфигурации «не использовать прокси».

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