|
Занят ли порт в такой ситуации?
|
|||
---|---|---|---|
#18+
Запустил свой сервис, он слушает порт 8900, затем остановил его, изменил в конфигурации порт на 8910, стартонул всё ок. Запустил ресурс монитор, вижу в Listening ports: Image PID Address Port Protocol Firewall status -------- ---- ---------- ----- --------- ---------------- System 4 IPv6 unspecified 8900 TCP Allowed, not restricted Как это понять? порт остался занят системой? Его больше нельзя использовать другим приложениям? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.01.2018, 14:49 |
|
Занят ли порт в такой ситуации?
|
|||
---|---|---|---|
#18+
Монитор ресурсов показывает не мгновенное состояние, а статистику за некоторое время. Используй netstat. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
02.01.2018, 15:11 |
|
Занят ли порт в такой ситуации?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovМонитор ресурсов показывает не мгновенное состояние, а статистику за некоторое время. Используй netstat. да, спасибо, когда сервис стартован >netstat -ano показывает, что System слушает 8900 когда остановлен - пусто ... |
|||
:
Нравится:
Не нравится:
|
|||
02.01.2018, 15:24 |
|
Занят ли порт в такой ситуации?
|
|||
---|---|---|---|
#18+
Странно, что TCPView (Sysinternals) поазывает, что порт слушается системой вто же время. когда netstat не показывает. TCPView тоже дает не актуальное состояние? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.01.2018, 15:43 |
|
Занят ли порт в такой ситуации?
|
|||
---|---|---|---|
#18+
Выгрузка слушающего процесса ещё не означает закрытия сокета IP-стеком. По практическим наблюдениям - до 15 минут... Причина обычная - криворукость программера. Полагаются на чистильщиков и разгрузки ресурсов по умолчанию, а оно вона как... ... |
|||
:
Нравится:
Не нравится:
|
|||
02.01.2018, 17:17 |
|
Занят ли порт в такой ситуации?
|
|||
---|---|---|---|
#18+
AkinaВыгрузка слушающего процесса ещё не означает закрытия сокета IP-стеком. По практическим наблюдениям - до 15 минут... Причина обычная - криворукость программера. Полагаются на чистильщиков и разгрузки ресурсов по умолчанию, а оно вона как... в данном случае может и криворукость, но это виндоуз WCF SOAP сервис, там руками закрыть сокет негде, или как минимум я не вижу, где. Ну, и приложение завершается. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.01.2018, 18:05 |
|
Занят ли порт в такой ситуации?
|
|||
---|---|---|---|
#18+
256kAkinaВыгрузка слушающего процесса ещё не означает закрытия сокета IP-стеком. По практическим наблюдениям - до 15 минут... Причина обычная - криворукость программера. Полагаются на чистильщиков и разгрузки ресурсов по умолчанию, а оно вона как... в данном случае может и криворукость, но это виндоуз WCF SOAP сервис, там руками закрыть сокет негде, или как минимум я не вижу, где. Ну, и приложение завершается. Так это не бага, это фича , клиент должен закрыть соединение, чтобы порт освободился при остановке сервиса. А если клиент отвалился, а сервис остановился - Windows сама решит, когда по таймауту освободить занятый порт TCP. Я так себе представляю этот механизм, возможно, ошибаюсь. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.01.2018, 21:27 |
|
Занят ли порт в такой ситуации?
|
|||
---|---|---|---|
#18+
Andy_OLAP, И не исключено, что в данном случае TCPView - это клиент, который проверяет путем коннекта к TCP портам сервисов. Ну а как обычно написаны клиенты в Редмонде - это песня. Например, ASP.NET Web нужно помнить и все явно закрывать . ... |
|||
:
Нравится:
Не нравится:
|
|||
02.01.2018, 21:31 |
|
Занят ли порт в такой ситуации?
|
|||
---|---|---|---|
#18+
Andy_OLAPэто не бага, это фича, клиент должен закрыть соединение, чтобы порт освободился при остановке сервиса. Помнишь старый такой анекдот: Код: plaintext 1. 2. 3.
В данном случае - подходит на 100%. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.01.2018, 23:24 |
|
Занят ли порт в такой ситуации?
|
|||
---|---|---|---|
#18+
AkinaВыгрузка слушающего процесса ещё не означает закрытия сокета IP-стеком. По практическим наблюдениям - до 15 минут... Причина обычная - криворукость программера. Полагаются на чистильщиков и разгрузки ресурсов по умолчанию, а оно вона как...несколько лет назад пришлось немного столкнуться с данной темой. Если память не изменяет, то ситуация выглядит примерно так в Windows: после завершения работы процесса, слушающего порт, сетевой стек ОС не прибирает связанные процессы сразу, а переводит их в "полузакрытое" состояние. Реализовано с целью, если процесс запросит заново тот же самый порт, то чтобы инициализация прошла быстрее. По таймауту все естественно прибивается ... |
|||
:
Нравится:
Не нравится:
|
|||
03.01.2018, 10:12 |
|
Занят ли порт в такой ситуации?
|
|||
---|---|---|---|
#18+
bga83AkinaВыгрузка слушающего процесса ещё не означает закрытия сокета IP-стеком. По практическим наблюдениям - до 15 минут... Причина обычная - криворукость программера. Полагаются на чистильщиков и разгрузки ресурсов по умолчанию, а оно вона как...несколько лет назад пришлось немного столкнуться с данной темой. Если память не изменяет, то ситуация выглядит примерно так в Windows: после завершения работы процесса, слушающего порт, сетевой стек ОС не прибирает связанные процессы сразу, а переводит их в "полузакрытое" состояние. Реализовано с целью, если процесс запросит заново тот же самый порт, то чтобы инициализация прошла быстрее. По таймауту все естественно прибивается это похоже на мой случай ... |
|||
:
Нравится:
Не нравится:
|
|||
03.01.2018, 11:10 |
|
Занят ли порт в такой ситуации?
|
|||
---|---|---|---|
#18+
Andy_OLAP256kпропущено... в данном случае может и криворукость, но это виндоуз WCF SOAP сервис, там руками закрыть сокет негде, или как минимум я не вижу, где. Ну, и приложение завершается. Так это не бага, это фича , клиент должен закрыть соединение, чтобы порт освободился при остановке сервиса. А если клиент отвалился, а сервис остановился - Windows сама решит, когда по таймауту освободить занятый порт TCP. Я так себе представляю этот механизм, возможно, ошибаюсь. частично так, но: у меня wcf сервис с конфиг файлом, не рукопашным созданием/закрытием каналов и т.д. Следовательно - вся надежда на wcf среду. Всё, что я могу - стартонуть сервисы на старте винсервиса и остановить их на стопе. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.01.2018, 11:14 |
|
Занят ли порт в такой ситуации?
|
|||
---|---|---|---|
#18+
Нормальное (gracefully) закрытие сокета делается в два этапа этапа: 1. Сервер закрывает канал записи (shutdown send); 2. Клиент дочитывает данные и делает "shutdown full" со своей стороны - сервер получает EOF на канале чтения и делает или "shutdown read" или "shutdown full". На уровне IP-стека это всё означает обмен пакетами с FIN-флагом с обоих сторон. Клиента и сервера IP-стек различает по (соответственно) отправке и приёму пакета с SYN-флагом. При быстром (dirty) завершении сервер сразу закрывает и канал записи и канал чтения (делает shutdown full), не ожидая реакции клиента. В этой ситуации клиент может получить исключение ввода-вывода в канале записи и, по хорошему, должен быть готов к обработке такой ситуации. Обмен пакетами требует времени и возможен вариант, когда процесс сервера завершился, но финальные пакеты от клиентов ещё не пришли. Такие сокеты будут "прибраны" IP-стеком "серверной стороны" по получении FIN-пакетов клиента или по таймеру. Вроде, новый процесс без проблем может занять порт полузакрытых сокетов "слушающим", если предыдущий процесс корректно освободил свои ресурсы. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.01.2018, 12:30 |
|
|
start [/forum/topic.php?fid=26&msg=39578898&tid=1492866]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
140ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
others: | 272ms |
total: | 494ms |
0 / 0 |