port

Alexey Vissarionov написал(а) к Oleg Redut в Apr 15 12:21:44 по местному времени:

Доброго времени суток, Oleg!
13 Apr 2015 12:50:46, ты -> All:

OR> Имеется ява-приложение. Запускается в screen. Иногда зависает и
OR> невыходит нормально. Приходится делать kill для screen с этим
OR> процессом. Но при повторном запуске сообщает, что порт, который
OR> оно использовала - уже занят. Приходится тупо перегружать машину.
OR> Можно ли освободить порт какой-то командой? Чтобы в командный файл
OR> запихнуть перед запуском явы.

killall -15 java && sleep 2 && killall -w -9 java


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

... Лучше пусть судят трое, чем несут четверо
--- /bin/vi

Serguei E. Leontiev написал(а) к Eric Pozharski в Apr 15 04:06:28 по местному времени:

From: "Serguei E. Leontiev" <leo@sai.msu.ru>

Привет Эрик,

От 18 апреля 2015 г., 17:00:53 в fido7.ru.linux.chainik ты писал:
SEL>> >:) И, если порт принадлежит соединению в TIME-WAIT,
SEL>> FIN_WAIT2, ..., lsof обнаружит на нём "пустоту"? Или есть
SEL>> варианты?
EP> su? Для CLOSE-WAIT работает, LAST-ACK -- упустил. Для
EP> TIME-WAIT и прочих проверить не могу -- у меня нету.

Ой! Ну да ладно, сам проверю :)

CentOS 7:
[leo@vmc7leom ~]$ nc -l 8901
ccc
Завершено

Mac OSX 10:
leom:_temp leo$ nc vmc7leom.local 8901
ccc

CentOS 7: (root)
[root@vmc7leom leo]# netstat -nap | grep 8901
tcp 0 0 10.228.12.26:8901 10.228.12.2:53138
ESTABLISНED 5113/nc
[root@vmc7leom leo]# lsof -i tcp:8901
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nc 5113 leo 5u IPv4 45284 0t0 TCP
vmc7leom:jmb-cds2->10.228.12.2:53138 (ESTABLISНED)
[root@vmc7leom leo]# killall nc
[root@vmc7leom leo]# netstat -nap | grep 8901
tcp 0 0 10.228.12.26:8901 10.228.12.2:53138
TIME_WAIT -
[root@vmc7leom leo]# lsof -i tcp:8901
[root@vmc7leom leo]#


--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru


--- ifmail v.2.15dev5.4

Eric Pozharski написал(а) к Serguei E Leontiev в Apr 15 11:09:53 по местному времени:

with <1187500704@ddt.demos.su> Serguei E Leontiev wrote:

SKIP [ уже не важно ]

SEL> Если память меня не подводит TIME-WAIT - это для того, кто соединение
SEL> закрывает (кто сокет закрывает или сам безвременно умирает).

Строго наоборот -- RFC761, page 21

SEL> На счёт java-way, да и насчёт POSIX-way (для тех, кто боится
SEL> SO_REUSEADDR). IMНO, единственный "платформенно независимый" путь
SEL> избежания состояния TIME-WAIT для сервера - это побуждать клиента
SEL> разрывать соединение. Однако, при сетевых проблемах, это может приводить
SEL> к длительному процессу завершения сервера (в просторечии "зависанию").
SEL> Если в этот момент такой "платформенно независимый" сервер убить -
SEL> получим TIME-WAIT и невозможность повторного запуска в течении примерно
SEL> 2*MSL секунд :)

Я перестаю понимать -- у тебя есть: процессы, порты, инструменты.
Посмотри кто что держит и по результатам разберись. Зачем спекуляции
разводить?

CUT

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
--- slrn/pre1.0.0-18 (Linux)

Serguei E. Leontiev написал(а) к Eric Pozharski в Apr 15 21:42:42 по местному времени:

From: "Serguei E. Leontiev" <leo@sai.msu.ru>

Привет Эрик,

От 19 апреля 2015 г., 11:09:53 в fido7.ru.linux.chainik ты писал:
EP> with <1187500704@ddt.demos.su> Serguei E Leontiev wrote:
EP> SKIP [ уже не важно ]
SEL>> Если память меня не подводит TIME-WAIT - это для того, кто
SEL>> соединение закрывает (кто сокет закрывает или сам
SEL>> безвременно умирает).
EP> Строго наоборот -- RFC761, page 21

По моему, ты плохо прочитал:

TIME-WAIT - represents waiting for enough time to pass to be sure
the remote TCP received the acknowledgment of its connection
termination request.

Или поясни, как ты это понимаешь.

Но простой эксперимент, который ты сам можешь провести, например, с
помощью netcat, показывает, что TIME_WAIT свойственен стороне, которая
закрывает сокет:

CentOS 7: (сервер)
[leo@vmc7leom ~]$ nc -l 8901
mmm
^C
[leo@vmc7leom ~]$ netstat -na | grep 8901
tcp 0 0 10.228.12.26:8901 10.228.12.2:52577
TIME_WAIT

Mac OSX 10: (клиент)
leom:_temp leo$ nc vmc7leom.local 8901
mmm
leom:_temp leo$ netstat -na | grep 8901
leom:_temp leo$


Видим, что убивая "сервер" под Linux получаем TIME-WAIT на его серверном
сокете.

Заметим, что, строго говоря, поведение зависит от реализации сервера
и/или TCP.

FreeBSD 10: (сервер)
[leo@vmfb10leom ~]$ nc -l 8901
lll
^C
[leo@vmfb10leom ~]$ netstat -na | grep 8901
tcp4 0 0 10.228.12.3.8901 10.228.12.26.41971 FINWAIT2
(после убийства клиента)
[leo@vmfb10leom ~]$ netstat -na | grep 8901
tcp4 0 0 10.228.12.3.8901 10.228.12.26.41971 TIME_WAIT
[leo@vmfb10leom ~]$

CentOS 7: (клиент)
[leo@vmc7leom ~]$ nc vmfb10leom.local 8901
lll
^Z
[1]+ Stopped nc vmfb10leom.local 8901
[leo@vmc7leom ~]$ netstat -na | grep 8901
tcp 0 0 10.228.12.26:41971 10.228.12.3:8901
CLOSE_WAIT
[leo@vmc7leom ~]$ fg
nc vmfb10leom.local 8901
^C
[leo@vmc7leom ~]$ netstat -na | grep 8901
[leo@vmc7leom ~]$


Правда, есть ещё, третий вариант, без TIME_WAIT, но я его видел только
на Mac OSX серверах:
Mac OSX 10: (сервер)
leom:_temp leo$ nc -l 8901
mmm
^C
leom:_temp leo$ netstat -na | grep 8901
tcp4 0 0 10.228.12.2.8901 10.228.12.26.40341
FINWAIT2
leom:_temp leo$ netstat -na | grep 8901
leom:_temp leo$

CentOS 7: (клиент)
[leo@vmc7leom ~]$ nc leom.local 8901
mmm
^Z
[1]+ Stopped nc leom.local 8901
[leo@vmc7leom ~]$ netstat -na | grep 8901
tcp 0 0 10.228.12.26:40341 10.228.12.2:8901
CLOSE_WAIT
[leo@vmc7leom ~]$ fg
nc leom.local 8901
^C
[leo@vmc7leom ~]$ netstat -na | grep 8901
[leo@vmc7leom ~]$


SEL>> На счёт java-way, да и насчёт POSIX-way (для тех, кто
SEL>> боится SO_REUSEADDR). IMНO, единственный "платформенно
SEL>> независимый" путь избежания состояния TIME-WAIT для
SEL>> сервера - это побуждать клиента разрывать соединение.
SEL>> Однако, при сетевых проблемах, это может приводить к
SEL>> длительному процессу завершения сервера (в просторечии
SEL>> "зависанию"). Если в этот момент такой "платформенно
SEL>> независимый" сервер убить - получим TIME-WAIT и
SEL>> невозможность повторного запуска в течении примерно 2*MSL
SEL>> секунд :)
EP> Я перестаю понимать -- у тебя есть: процессы, порты,
EP> инструменты. Посмотри кто что держит и по результатам
EP> разберись. Зачем спекуляции разводить?

Голова рукам покоя не даёт, истина дороже :)

--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru


--- ifmail v.2.15dev5.4

Serguei E. Leontiev написал(а) к Serguei E. Leontiev в Apr 15 21:58:13 по местному времени:

From: "Serguei E. Leontiev" <leo@sai.msu.ru>

P.S.

От 19 апреля 2015 г., 21:42:42 в fido7.ru.linux.chainik ты писал:
SL> Видим, что убивая "сервер" под Linux получаем TIME-WAIT на его
SL> серверном сокете.
SL> Заметим, что, строго говоря, поведение зависит от реализации
SL> сервера и/или TCP.
SL> FreeBSD 10: (сервер)

Да, забыл, поведение Linux(клиент) - Linux(сервер) выглядит аналогичным
поведению Linux(клиент) - FreeBSD 10(сервер)

CentOS 7: (сервер)
[leo@vmc7leom ~]$ nc -l 8901
lll
^C
[leo@vmc7leom ~]$ netstat -na | grep 8901
tcp 0 0 10.228.12.26:38632 10.228.12.26:8901
CLOSE_WAIT
tcp 0 0 10.228.12.26:8901 10.228.12.26:38632
FIN_WAIT2
(после убийства клиента)
[leo@vmc7leom ~]$ netstat -na | grep 8901
tcp 0 0 10.228.12.26:8901 10.228.12.26:38632
TIME_WAIT
[leo@vmc7leom ~]$


CentOS 7: (клиент)
[leo@vmc7leom ~]$ nc vmc7leom.local 8901
lll
^Z
[1]+ Stopped nc vmc7leom.local 8901
[leo@vmc7leom ~]$ netstat -na | grep 8901
tcp 0 0 10.228.12.26:38632 10.228.12.26:8901
CLOSE_WAIT
tcp 0 0 10.228.12.26:8901 10.228.12.26:38632
FIN_WAIT2
[leo@vmc7leom ~]$ fg
nc vmc7leom.local 8901
^C
[leo@vmc7leom ~]$ netstat -na | grep 8901
tcp 0 0 10.228.12.26:8901 10.228.12.26:38632
TIME_WAIT
[leo@vmc7leom ~]$

--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru


--- ifmail v.2.15dev5.4

Eric Pozharski написал(а) к Serguei E Leontiev в Apr 15 10:16:50 по местному времени:

with <1187500713@ddt.demos.su> Serguei E Leontiev wrote:

SEL>>> Если память меня не подводит TIME-WAIT - это для того, кто
SEL>>> соединение закрывает (кто сокет закрывает или сам
SEL>>> безвременно умирает).
EP>> Строго наоборот -- RFC761, page 21
SEL> По моему, ты плохо прочитал:
SEL> TIME-WAIT - represents waiting for enough time to pass to be
SEL> sure the remote TCP received the acknowledgment of its connection
SEL> termination request.
SEL> Или поясни, как ты это понимаешь.

Двумя страницами ниже (page 22 реально короткий) есть flow-chart. Из
него следует, что в состояние TIME-WAIT переход из состояния FIN-WAIT-2
и только из этого состояния. Далее:

FIN-WAIT-2 - represents waiting for a connection termination
request from the remote TCP.

Теперь, сокет привязан к дескриптору, дескриптор к процессу. Положим
процесс умер, и, действительно, ядро может доделать всю FIN-вакханалию.
По идее, должен быть зомби. Иначе, получается что должен быть порт в
состоянии отличном от CLOSED для которого нет процесса, пусть даже
зомби.

Теперь, получается такая херня -- для сервера это не должно быть
проблемой (accept(2) возвращает дескриптор отличный от того на котором
висит listen(2); TCB, in essence, это две пары IP-port -- локальная и
удаленная; положим, сервер отвалил и оставил после себя соединения не в
CLOSED -- это не проблема (потому что соединение это две пары
IP-port), иначе рестарт регулярно занимал бы до четырех минут (тот самый
2MSL))).

Однако, если клент (тот самый мистический java-что-то) абсолютно
настаивает на том, что бы создавать соединение с того же самого порта (а
IP, ессно, тот же самый), то, действительно, может быть проблема
продолжительностью до 2MSL (IP:port принимающей стороны один и тот же --
иначе это не было бы сервером). (761-го со-товарищи (а их есть) читал
давно, и точных формулировок ессно не помню, но ощущение такое, что там
(в со-товарищах) прямо сказано, что исходящий порт должен выбираться
рандомно, иначе кирдык.)

SKIP
EP>> Я перестаю понимать -- у тебя есть: процессы, порты,
EP>> инструменты. Посмотри кто что держит и по результатам
EP>> разберись. Зачем спекуляции разводить?
SEL> Голова рукам покоя не даёт, истина дороже :)

Это не science-way. Должно быть в такой последовательности: [1]
провести наблюдения; [2] сформулировать гипотезу; [3] сформулировать и
провести мысленный эксперимент; [4] провести реальный эксперимент; [5]
сравнить результаты мысленного и реального эксперимента; [6] по
резульатам сравнения либо перейти к пункту [1] (гипотеза отвергнута),
либо к пункту [1] (гипотеза требует уточнения), либо принять гипотезу
как подтвержденную и перейти к пункту [1] (в поисках нового геморроя).
Ты находишься в пункте [4], при этом ты не знаешь кто держит (и держит
ли вообще) IP:port на стороне клиента; второе ты не знаешь как
фактически умирает клиент (после горячего рестарта).

Или знаешь. Но скрываешь.

--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
--- slrn/pre1.0.0-18 (Linux)

Serguei E. Leontiev написал(а) к Eric Pozharski в Apr 15 13:42:16 по местному времени:

From: "Serguei E. Leontiev" <leo@sai.msu.ru>

Привет Эрик,

От 20 апреля 2015 г., 10:16:50 в fido7.ru.linux.chainik ты писал:
SEL>>>> Если память меня не подводит TIME-WAIT - это для
SEL>>>> того, кто соединение закрывает (кто сокет
SEL>>>> закрывает или сам безвременно умирает).
EP>>> Строго наоборот -- RFC761, page 21

Прошу прощения, сразу не отметил, что следует читать не RFC 761, а RFC
793, в деле TIME-WAIT они немного отличаются.

SEL>> По моему, ты плохо прочитал:
SEL>> TIME-WAIT - represents waiting for enough time to pass
SEL>> to be sure the remote TCP received the acknowledgment
SEL>> of its connection termination request.
SEL>> Или поясни, как ты это понимаешь.
EP> Двумя страницами ниже (page 22 реально короткий) есть
EP> flow-chart. Из него следует, что в состояние TIME-WAIT переход
EP> из состояния FIN-WAIT-2 и только из этого состояния.

Строго говоря, если мне не изменяет память, это была ошибка в RFC 761,
которую исправили в действующем RFC 793, т.е. в TIME-WAIT попадают, как
из FIN-WAIT-2, так из CLOSING.

EP> Далее:
EP> FIN-WAIT-2 - represents waiting for a connection termination
EP> request from the remote TCP.
EP> Теперь, сокет привязан к дескриптору, дескриптор к процессу.
EP> Положим процесс умер, и, действительно, ядро может доделать всю
EP> FIN-вакханалию. По идее, должен быть зомби. Иначе, получается
EP> что должен быть порт в состоянии отличном от CLOSED для
EP> которого нет процесса, пусть даже зомби.

Всё правильно (с точностью до ошибки в RFC 761), только зачем процессу
становится зомби? (Впрочем, во времена оные на каких-то системах вроде
бы так бывало, у меня есть какие-то смутные, смутные воспоминания).
Состояние TIME_WAIT - чисто "защитное" состояние протокола TCP,
завершение которого практически никак не влияет на процесс (хотя смотри
ниже, если подходить математически строго, то каждое TCP соединение
должно закрываться 2MSL секунд).

Как легко видеть в предыдущих экспериментах с netcat на Linux и FreeBSD
таки появляется порт в состоянии TIME_WAIT, для которого нет процесса.

Впрочем, точно так же происходит, и на Windows 8.1:
C:\Program Files>nc -l 8901
mmmm
(здесь Ctrl-C)
C:\Program Files>netstat -an | grep 8901
TCP 10.228.12.6:8901 10.228.12.2:61025 TIME_WAIT

И на Solaris 11:
Oracle Corporation SunOS 5.11 11.2 September 2014
leo@vms11leom:~$ nc -l 8901
mmm
^C
leo@vms11leom:~$ netstat -na | grep 8901
10.228.12.12.8901 10.228.12.2.61684 131744 0 128872 0
TIME_WAIT
leo@vms11leom:~$

Только на Mac OSX, настроенной по умолчанию, происходит немного иначе
(смотри предыдущие сообщения), Apple большие оптимизаторы, надо будет
как нибудь посмотреть какие sysctl и как они настроили.

EP> Теперь, получается такая херня -- для сервера это не должно быть
EP> проблемой (accept(2) возвращает дескриптор отличный от того на
EP> котором висит listen(2); TCB, in essence, это две пары IP-port
EP> -- локальная и удаленная; положим, сервер отвалил и оставил
EP> после себя соединения не в CLOSED -- это не проблема (потому
EP> что соединение это две пары IP-port), иначе рестарт регулярно
EP> занимал бы до четырех минут (тот самый 2MSL))).

Строго говоря, для сервера это может быть проблемой, т.к. он открывает
сокет для приёма соединений. И может так получится, если мне не изменяет
память, что он воспримет отставшие пакеты закрытого соединения
предыдущего сервера как пакеты открытия нового соединения.

Собственно поэтому, "строгие" разработчики стека TCP/IP и настаивают,
либо на задержке 2MSL секунд, либо на использовании SO_REUSEADDR, а
"мягкие" разработчики предусматривают всяческие нестандартные флаги
SO_REUSEPORT и прочие отклонения от стандарта POSIX.

Если мы взглянем в FAQ эхи RU.UNIX.PROG
https://groups.google.com/forum/#!to...og/MEDYd9pCOGk ,
то увидим соответствующий вопрос и ответ:

================================================================
Q: Пишу демона, если демон перезапускается - не может сделать bind()
A: Смотреть в сторону setsockopt с опциями SOREUSEADDR, SOREUSEPORT.
SO_REUSEPORT есть не везде.

EP> Однако, если клент (тот самый мистический java-что-то)
EP> абсолютно настаивает на том, что бы создавать соединение с
EP> того же самого порта (а IP, ессно, тот же самый), то,
EP> действительно, может быть проблема продолжительностью до 2MSL
EP> (IP:port принимающей стороны один и тот же -- иначе это не было

Тот самый мистический java-что-то, поскольку он Java, вероятно написан
без использования нестандартных SO_REUSEPORT и т.п., таким образом ему
предписано соблюдать задержку 2MSL между убийством и повторным запуском,
либо требуется настроить sysctl в Linux.

EP> бы сервером). (761-го со-товарищи (а их есть) читал давно, и
EP> точных формулировок ессно не помню, но ощущение такое, что там
EP> (в со-товарищах) прямо сказано, что исходящий порт должен
EP> выбираться рандомно, иначе кирдык.) SKIP

Честно говоря, не помню такого. Да и диапазон клиентских портов в районе
15 бит, ну даже если случайно, всё равно вероятность конфликтов будет
порядка 10^-2, т.е. "кирдык".

Разве что как дополнительная мера защита от "хакеров" класса "пионер" :)

EP>>> Я перестаю понимать -- у тебя есть: процессы, порты,
EP>>> инструменты. Посмотри кто что держит и по результатам
EP>>> разберись. Зачем спекуляции разводить?
SEL>> Голова рукам покоя не даёт, истина дороже :)
EP> Это не science-way. Должно быть в такой последовательности:
EP> [1] провести наблюдения; [2] сформулировать гипотезу; [3]
EP> сформулировать и провести мысленный эксперимент; [4] провести
EP> реальный эксперимент; [5] сравнить результаты мысленного и
EP> реального эксперимента; [6] по резульатам сравнения либо
EP> перейти к пункту [1] (гипотеза отвергнута), либо к пункту [1]
EP> (гипотеза требует уточнения), либо принять гипотезу как
EP> подтвержденную и перейти к пункту [1] (в поисках нового
EP> геморроя). Ты находишься в пункте [4], при этом ты не знаешь
EP> кто держит (и держит ли вообще) IP:port на стороне клиента;
EP> второе ты не знаешь как фактически умирает клиент (после
EP> горячего рестарта). Или знаешь. Но скрываешь.

Вообще-то, это Олег Редут убивает ява-приложения.

А я же только дал анализ его следующего утверждения (который ты вроде
как частично подтвердил):

"...Кстати, если я убиваю нормально работающий процесс, то порт не
захватывается. А если процесс крэшнулся по внутренним причинам и не
работает нормальный выход из него, то тогда после убиения и порт не
освобождается..."

С советом использовать, либо:
sleep 240 # 2*msl
, либо:
man sysctl
+ документация на ядро Linux
и по результатам
sysctl net.ipv4.tcptwrecycle
sysctl net.ipv4.tcp_timestamps
sysctl net.ipv4.tcptwreuse
sysctl net.ipv4.tcp_rfc1337

--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru


--- ifmail v.2.15dev5.4

Serguei E. Leontiev написал(а) к Serguei E. Leontiev в Apr 15 14:13:48 по местному времени:

From: "Serguei E. Leontiev" <leo@sai.msu.ru>

P.S.

"Serguei E. Leontiev" <leo@sai.msu.ru> wrote:
> От 20 апреля 2015 г., 10:16:50 в fido7.ru.linux.chainik ты писал:
>> бы сервером). (761-го со-товарищи (а их есть) читал давно, и
>> точных формулировок ессно не помню, но ощущение такое, что там
>> (в со-товарищах) прямо сказано, что исходящий порт должен
>> выбираться рандомно, иначе кирдык.) SKIP
> Честно говоря, не помню такого. Да и диапазон клиентских портов в районе
> 15 бит, ну даже если случайно, всё равно вероятность конфликтов будет
> порядка 10^-2, т.е. "кирдык".

Вот вспомнилось, в деле тестирования серверов на предмет C10Kproblem, а так
же в рекомендациях по конфигурации прокси серверов, встречалась как раз
обратная рекомендация: по возможности расширить диапазон разрешённых
клиентских портов и отменить их рандомизацию.

--
Успехов, Сергей Леонтьев, <http://www.cryptopro.ru> (NewsTap)
--- ifmail v.2.15dev5.4

Eric Pozharski написал(а) к Serguei E Leontiev в Apr 15 19:24:51 по местному времени:

with <1187500739@ddt.demos.su> Serguei E Leontiev wrote:

SKIP
SEL> Прошу прощения, сразу не отметил, что следует читать не RFC 761, а RFC
SEL> 793, в деле TIME-WAIT они немного отличаются.

Я сам виноват -- поленился, думал там сразу в заголовке будут отсылки (я
так привык). А RFC старый и в заголовке ни слова не сказано, ну я и
пошел дальше. Будет уроком.

SKIP
SEL> Строго говоря, если мне не изменяет память, это была ошибка в RFC
SEL> 761, которую исправили в действующем RFC 793, т.е. в TIME-WAIT попадают,
SEL> как из FIN-WAIT-2, так из CLOSING.

ACK

EP>> Далее:
EP>> FIN-WAIT-2 - represents waiting for a connection termination
EP>> request from the remote TCP.
EP>> Теперь, сокет привязан к дескриптору, дескриптор к процессу.
EP>> Положим процесс умер, и, действительно, ядро может доделать всю
EP>> FIN-вакханалию. По идее, должен быть зомби. Иначе, получается
EP>> что должен быть порт в состоянии отличном от CLOSED для
EP>> которого нет процесса, пусть даже зомби.
SEL> Всё правильно (с точностью до ошибки в RFC 761), только зачем процессу
SEL> становится зомби? (Впрочем, во времена оные на каких-то системах
SEL> вроде бы так бывало, у меня есть какие-то смутные, смутные воспоминания).
SEL> Состояние TIME_WAIT - чисто "защитное" состояние протокола TCP,
SEL> завершение которого практически никак не влияет на процесс (хотя
SEL> смотри ниже, если подходить математически строго, то каждое TCP соединение
SEL> должно закрываться 2MSL секунд).

Моя идея с зомби в том, что пока соединение не в CLOSED TCB не удален, а
к TCB привязан дескриптор, а дескриптор привязан к процессу. И, как по
мне это выглядит безопаснее, нельзя удалить процесс. Вместе с тем, если
таких TIME-WAIT зомби будет много, то могут произойти разные
неприятности. И что бы этих неприятностей избежать не CLOSED TCB
отрывают от дескриптора. Вместе с тем, для remote что происходит с
таблицей процессов не должно иметь значения.

SEL> Как легко видеть в предыдущих экспериментах с netcat на Linux и FreeBSD
SEL> таки появляется порт в состоянии TIME_WAIT, для которого нет процесса.
SKIP

(Я извиняюсь, что не подыгрываю в проведении экспериментов --
штурмовщина, а в не-рабочее время работаю над собой.) А что будет, если
локально соединение в TIME-WAIT, и открывать с того же IP:port с той
стороны?

SKIP
SEL> Вообще-то, это Олег Редут убивает ява-приложения.

Да. Тут вот. Совершенно это упустил из виду. Приношу свои извинения
-- упреки были совершенно не по адерсу.

CUT


--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
--- slrn/pre1.0.0-18 (Linux)