|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Igor Sysoev 2:5020/400 29 Jan 2004 19:33:18
To : Lev Walkin
Subject : Re: незакрытые сокеты
--------------------------------------------------------------------------------
Lev Walkin <vlm@netli.com> wrote:
>
> Lev Walkin wrote:
>>
>> Igor Sysoev wrote:
>>
>>> Lev Walkin <vlm@netli.com> wrote:
>>>
>>>
>>>> Igor Sysoev wrote:
>>>>
>>>>> Lev Walkin <vlm@netli.com> wrote:
>>>>>
>>>>>
>>>>>> Slawa Olhovchenkov wrote:
>>>>>>
>>>>>>
>>>>>>> А как можно уменьшить количество болтающихся сокетов в состоянии
>>>>>>> TIME_WAIT/FIN_WAIT_2?
>>>>>>
>>>>>>
>>>>>> SO_REUSEADDR использовать в программе.
>>>>>> Лучше _после_ accept()'а.
>>>>>
>>>>>
>>>>> А как SO_REUSEADDR этому поможет ?
>>>>
>>>>
>>>> я ждал этого вопроса ;)
>>>>
>>>> поможет тем, что включает широко известный в узких кругах сайд-эффект.
>>>> он заключается в том, что для новых сокетов могут использоваться
>>>> закрытые сокеты, сидящие в TIME_WAIT. Обычно они так и сидят в этом
>>>> состоянии 2MSL, но при наличии флага SO_REUSEADDR вместо создания
>>>> нового сокета ядро может выбрать вариант их реиспользования.
>>>> это не значит, что в системе совсем не будет TIME_WAIT, но это
>>>> количество
>>>> имеет достаточно четкую верхнюю границу при известной загрузке.
>>>>
>>>> почему нужно делать после accept()'а? потому что флаг должен быть на
>>>> сокете сидящем в TIME_WAIT, а не в LISTEN, а некоторых других OS
>>>> (обладающих тем же сайд-эффектом, впрочем) флаги на listen-сокете
>>>> не наследуются на сокеты, получающиеся через accept(). поэтому нужно
>>>> либо #ifdef'ить, либо перестраховаться и устанавливать SO_REUSEADDR
>>>> всегда после каждого accept()'а.
>>>
>>>
>>>
>>> А где такое есть ? Поиск по фрёвым листам и lkml на предмет SO_REUSEADDR
>>> и TIME_WAIT подобной особенности SO_REUSEADDR не выявил.
>
> О, вот и авторитет:
>
> From: rstevens@noao.edu (W. Richard Stevens)
> Subject: Re: TLI: Provider tcp, FIN_WAIT_2 problem, how set SO_REUSEADDR in
> TLI Date: 1995/08/22 Message-ID: <41bf56$8e9@noao.edu>#1/1 distribution: inet
> references: <412fqr$4th@kannews.ca.newbridge.com> <413c65$3vc@noao.edu>
> <41b13u$rms@dawn.mmm.com> organization: National Optical Astronomy
> Observatories, Tucson, AZ, USA newsgroups:
> comp.unix.questions,comp.unix.programmer,comp.unix.solaris,comp.protocols.tcp-
> ip She said that SO_REUSEADDR had to do with allowing a port to be bound on a
> network interface which was already bound with INADDR_ANY (somewhere in her
> explanation she mentioned multiple interfaces also) or something such like. I
> never fully understood. She said that the correct way to handle the problem
> was to turn off SO_LINGER. Can anyone clear this up for me? SO_LINGER has
> nothing to do with this. Setting the linger option with a linger time of 0
> causes an RST to be sent upon close, instead of a FIN. SO_REUSEADDR allows the
> process to bind a port that's already in use, typically the bind is done by a
> server (with a wildcard IP address) and the port may exist in a connection
> that's in the TIME_WAIT state. SO_REUSEADDR does *not* just allow a TCP socket
> pair to be reused--all it affects is the bind. Also, could someone explain the
> reason why the port lingers in the WAIT state after the server has
> exited? There are two reasons for TCP's TIME_WAIT state. (1) To let
> TCP's full-duplex close occur reliably (handles the case of the final FIN
> or final ACK being lost). (2) To allow any linger duplciates from
> this incarnation expire in the network before initiating another incarnation.
Да, но эта цитата, равно как и server_wont_start.doc описывают лишь
ситуацию, когда есть процесс, который использует в соединении локальную
пару адрес:порт (или же это соединение уже в состоянии TIME_WAIT) и нам
нужно запустить другой процесс, который хочет сделать bind() на ту же пару.
Это классический случай использования SO_REUSEADDR, но к уменьшению
TIME_WAIT он не имеет никакого отношения.
--
Игорь Сысоев
http://sysoev.ru
--- ifmail v.2.15dev5.2
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
