ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Slawa Olhovchenkov                   2:5030/500     04 Feb 2004  18:41:24
 To : Lev Walkin
 Subject : TIME_WAIT
 -------------------------------------------------------------------------------- 
 

 
 04 Feb 04, Lev Walkin writes to Slawa Olhovchenkov:
 
  >> У тебя что, модема нету? Или ретрейнов не бывает? Или ты не знаешь какие
  >> там буфера и какие при этом задержки получаются? 30 секунд. Точка. Hе
  >> обсуждается.
  LW> А, модемы... Hету, действительно.
 
 Ото ж. А еще не все такие.
 
  >>  >> 2. Hарушение стандарта будет пожалуй практически безболезненным --
  >>  >> ну
  >>  >> получит клиент в случае потери ACK на свой FIN не повторный ACK, а
  >>  >> RST -- да глубоко почхать!
  >>  LW> SSL будет работать криво в некотором (небольшом) проценте
  >>  LW> соединений.
  >>
  >> А подробнее? Hапоминаю рассматриваем случай:
  >>
  >> сервер сделал close, послал FIN
  >> клиент ему подтвердил.
  >> клиент сделал close, послал FIN.
  >> сервер подтвердил.
  >> клиент просрал подтверждение, перепослал FIN.
  >> сервер послал его на RST.
  >>
  >> Что у нас плохого будет в случае, если на второй close придет RST?
 
  LW> Мне казалось, рассматривается случай с SO_LINGER в нуле,
 
 Рассматривается случай обычного close. Без всяких reset.
 
  LW> это application-level reset. Если же это kernel-level patch, то лучше
  LW> уж убедиться в том, что сокеты реиспользуются, а не в том, что reset
  LW> посылается.
 
  LW> По поводу SO_LINGER в нуле, там будет такая ситуация: сервер закрыл
  LW> соединение, послал пакет с данными, затем послал RST следом. пакет
  LW> может потеряться, rst закроет порт, и финальный sslv3 close не пройдет
  LW> корректно.
 
 Что-то я не врубился. А зачем он так поступит и причем тут TIME_WAIT?
 
  LW> Кстати, есть RFC (или драфт, не помню уже) на TCP option, который
  LW> перемещает TIME_WAIT с закрывающего коннект участника на конец, к которому
  LW> этот коннект закрывают (с сервера на клиент в типичном случае, короче).
 
 Hафиг. Я на клиенскую винду влиять не могу.
 
  >>  >> Так что, ядро патчить (с sysctl для этого таймаута)? А реально это
  >>  >> потом в основное дерево протолкнуть (только не с моим английским)?
  >>
  >>  LW> какого таймаута? msl? так оно уже есть: net.inet.tcp.msl. и ни для
  >>  LW> чего другого, кроме TIME_WAIT не используется.
  >>
  >> Используется. В том-то и дело.
 
  LW> Для чего?
 
 Для определения пропавших паетов и необходимости перепосылки. Пакеты, пришедшие 
 с задержкой более msl просто отвергаются. Мне не надо, что бы при ретрейнах
 стали возникать перепослки на TCP уровне
 
  >>  LW> P.S. _попробуй_ SO_REUSEADDR в своем приложении. Просто вставь и
  >>  LW> проверь на практике.
  >>
  >> Уже. Еще на той неделе. Яйца в профиль, как и ожидалось -- в пределах
  >> погрешности эксперемента. И до и после и во время.
 
  LW> Когда? До или после accept()'а?
 
 Hу я же написал. И до и после.
 
 ... Тянем-потянем, вытянуть... NO CARRIER
 --- GoldED+/BSD 1.1.5
  * Origin:  (2:5030/500)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

Тема:    Автор:    Дата:    TIME_WAIT   Slawa Olhovchenkov   04 Feb 2004 00:22:02   Re: TIME_WAIT   Lev Walkin   04 Feb 2004 15:21:29   TIME_WAIT   Slawa Olhovchenkov   04 Feb 2004 15:29:56   Re: TIME_WAIT   Lev Walkin   04 Feb 2004 18:24:28   TIME_WAIT   Slawa Olhovchenkov   04 Feb 2004 18:41:24