= Сообщение: 841 из 3153 ================================== RU.LINUX.CHAINIK = От : Eric Pozharski 2:463/94.101 20 Apr 15 10:16:50 Кому : Serguei E Leontiev 20 Apr 15 10:16:50 Тема : Re: port FGHI : area://RU.LINUX.CHAINIK?msgid=2:463/94.101+01c8de82 На : area://RU.LINUX.CHAINIK?msgid=<1187500713@ddt.demos.su>+5a65c224 = Кодировка сообщения определена как: CP866 ================================== ============================================================================== 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 на стороне клиента; второе ты не знаешь как фактически умирает клиент (после горячего рестарта).
Или знаешь. Hо скрываешь.
-- Torvalds' goal for Linux is very simple: World Domination Stallman's goal for GNU is even simpler: Freedom --- slrn/pre1.0.0-18 (Linux) * Origin: orphan.zombinet (2:463/94.101)
