У меня есть небольшое приложение .net 2.0 systray (C #), которое периодически проверяет сетевое подключение. Это делается путем попытки открыть соединение с экземпляром SQL-Server на другом компьютере (и выбрать строку из таблицы). Приложение сохраняет документы, созданные другим процессом, в базу данных, когда находит соединение. Он будет использоваться в средах с потенциально опасными беспроводными сетями.
При тестировании наша команда QA использует ipconfig /Release на сервере БД (на котором размещается БД Sql-Server 2005). Мы обнаружили, что приложение продолжало утверждать, что оно подключено к сети, поскольку оно продолжало успешно открывать подключения к SQL Server. Поведение приложения systray было ошибочным в моем собственном тестировании с использованием ipconfig /release.
По предложению нашего отсутствующего в настоящее время сетевого парня я изменил свое собственное внутреннее тестирование (приложение, размещенное на ВМ, подключающееся к БД на моей рабочей станции), чтобы вместо этого отключить сетевое соединение с ВМ. Это приводит к ожидаемому поведению (приложение systray не может найти сетевое соединение). Ребята из QA немного подозрительно относятся к моим предположениям, что они делают то же самое, и я должен успокоить их.
Мне было предложено, чтобы SQL Server использовал именованные каналы для приема входящих соединений. Если Именованные каналы и TCP / IP включены, аннулирует ли это тест ipconfig /release?
Я не особо разбираюсь в сетях. Именованные каналы, согласно тому, что я прочитал, звучат так, как будто они предназначены для использования между приложениями на одном сервере. Но это может быть использовано для внутренней связи?
Здесь происходит что-то еще, о чем я не подозреваю? Что-то о том, как ipconfig /release работает