Можно ли уничтожить стек TCP / IP программно?
https://stackoverflow.com/questions/133442
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Наше серверное приложение прослушивает порт, и через некоторое время оно больше не принимает входящие соединения.(И хотя я бы с удовольствием решил эту проблему, это не то, о чем я здесь спрашиваю;)
Странно то, что когда наше приложение перестает принимать подключения на порту 44044, то же самое делает IIS (на порту 8080).Отключение нашего приложения все исправляет - IIS снова начинает отвечать.
Итак, вопрос в том, может ли приложение испортить весь стек TCP / IP?Или, возможно, как приложение может это сделать?
Бессмысленная деталь:Наше приложение написано на C #, под управлением .Net 2.0, на XP / SP2.
Разъяснение:IIS не "отказывается" от попыток подключения.Это значит никогда их не видеть.Клиенты получают сообщение "сервер не ответил своевременно" (используя клиент .Net TCP).)
Решение
Вполне возможно, что вы морите стек голодом.Его довольно легко слить в условиях высокой скорости открытия / закрытия транзакций в секунду, напримервеб-сервер, обслуживающий множество нераспределенных запросов.
Это компенсируется задержкой ОЖИДАНИЯ по умолчанию - количество времени, которое сокет должен быть закрыт перед переработкой, по умолчанию равно 90 (если я правильно помню)
Существует множество разделов реестра, которые можно настроить - предложите создать / отредактировать хотя бы следующие разделы
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
TcpTimedWaitDelay = 30
MaxUserPort = 65534
MaxHashTableSize = 65536
MaxFreeTcbs = 16000
В MSDN и Technet есть множество документов о функциях этих клавиш.
Другие советы
Вы ведь не исчерпали доступные дескрипторы портов, не так ли?
netstat -a
Я видел нечто подобное, когда приложение открывало и закрывало порты (но на самом деле не закрывало их корректно).
Используйте netstat -a, чтобы увидеть активные соединения, когда это произойдет.Возможно, ваше серверное приложение не закрывает / не удаляет "закрытые" соединения.
Хорошие предложения от всех, спасибо за вашу помощь.
Итак, вот что происходило:Оказывается, у нас было несколько сервисов, конкурирующих за один и тот же порт, и в большинстве случаев "правильный" сервис получал порт.Иногда вторая служба перехватывала порт, а первая служба пыталась открыть другой порт.С этого времени службы продолжали бы захватывать новые порты каждый раз, когда они обслуживали запрос (поскольку они не использовали свои предпочтительные порты), и в конечном итоге мы исчерпали бы все доступные порты.
Конечно, на самом деле вопрос был таков:"Может ли приложение испортить весь стек TCP / IP?", и ответ на этот вопрос таков:ДА.Один из способов сделать это - прослушивать целую кучу портов.
Я предполагаю, что комментарий с номером порта от RichS верен.
Кроме этого, стек TCP / IP является всего лишь модулем в вашей операционной системе и, как таковой, может содержать ошибки, которые могут позволить приложению отключить его.Это был бы не первый драйвер, убитый программой.
(Снимаю шляпу перед Эндрю Таненбаумом за то, что он настаивал на том, что операционные системы должны быть модульными, а не монолитными.)
Я сам был в паре подобных ситуаций.Хорошим шагом по устранению неполадок является попытка подключения с уязвимого компьютера к хорошо известному месту назначения, которое в данный момент не испытывает никаких проблем с подключением.Если попытка подключения завершится неудачей, вы, скорее всего, получите более интересные подробности в сообщении об ошибке / коде.Например, это может означать, что не хватает дескрипторов или памяти.
С точки зрения службы поддержки и системного администратора, я видел это только в самых редких случаях (более одного раза), но это, безусловно, может случиться.
Когда вы диагностируете проблему, вам следует тщательно устранить возможные причины, а не слепо перезагружать систему при первых признаках неполадки.Я говорю это только потому, что многие клиенты, с которыми я работаю, испытывают искушение сделать это.
