Здравствуйте, Андрей Елсуков, Вы писали:
АЕ>В статье рассматривается один из способов контроля над работоспособностью TCP/IP-соединения под Windows – создание keep-alive таймера.
А сама статья будет на сайте? Или только в журнале?
Вы писали 26 марта 2004 г., 10:10:10:
MC> А сама статья будет на сайте? Или только в журнале?
Я так-то писал её для того чтобы на сайте разместить
Её в журнал поместили.. если принять во внимание темп с которым статьи
размещаются в электронном виде, то наверно через полгодика поместят..
Здравствуйте, butcher, Вы писали:
B>Я так-то писал её для того чтобы на сайте разместить B>Её в журнал поместили.. если принять во внимание темп с которым статьи B>размещаются в электронном виде, то наверно через полгодика поместят..
Покритиковать хоцца
Нас ведь пивом не корми, дай что-нибудь покритиковать...
Вы писали 26 марта 2004 г., 10:22:44:
B>>Я так-то писал её для того чтобы на сайте разместить B>>Её в журнал поместили.. если принять во внимание темп с которым статьи B>>размещаются в электронном виде, то наверно через полгодика поместят..
MC> Покритиковать хоцца MC> Нас ведь пивом не корми, дай что-нибудь покритиковать...
я особо ни на что и не претендую, первая статья как никак..
а критиковать там наверно есть что, могу выслать экземпляр
Здравствуйте, butcher, Вы писали:
MC>> Покритиковать хоцца MC>> Нас ведь пивом не корми, дай что-нибудь покритиковать...
B> B>я особо ни на что и не претендую, первая статья как никак.. B>а критиковать там наверно есть что, могу выслать экземпляр
Буду очень благодарен. Адрес в профайле (без "спам.маст.дай", ессно).
И мне, будьте добры, вышлите! задолбался воевать с сокетами...
stas_karpenko@mail.ru
Здравствуйте, GarikTot, Вы писали:
GT>Здравствуйте, butcher, Вы писали:
B>>а критиковать там наверно есть что, могу выслать экземпляр
GT>И мне, пожалуйста
GT>gariktot<at>rambler.ru
GT>заранее спасибо
Здравствуйте, бонифаций, Вы писали:
Б>И мне, будьте добры, вышлите! задолбался воевать с сокетами... Б>stas_karpenko@mail.ru B>>>а критиковать там наверно есть что, могу выслать экземпляр GT>>И мне, пожалуйста GT>>gariktot<at>rambler.ru GT>>заранее спасибо
если можно то и мне тоже dmitriy<at>kazimirow<dot>pp<dot>ru
Здравствуйте, Андрей Елсуков, Вы писали:
АЕ>Статья:
АЕ>Авторы: АЕ> Андрей Елсуков
АЕ>Аннотация: АЕ>В статье рассматривается один из способов контроля над работоспособностью TCP/IP-соединения под Windows – создание keep-alive таймера.
Статья весьма интересна в плане того. как можно провести точные настройки TCP/IP соединения.
Но, если я не ошибаюсь, таким образом невозможно понизить время ожидания до посылки первого keep-alive пакета, т. е. функцией setsockopt ты включаеш или выключаеш посулку пакетов (и произойдет это через те самые примерные 2 часа), а функцией WSAIoctl ты задаеш интеревал между посылками, но не до первой посылки. Получается. что первая посылка пакета произойдет через те же самые 2 часа, а вот повторяться они будут через твой интервал.
И второе. функция WSAIoctl с параметром SIO_KEEPALIVE_VALS уже включает (или выключает) опцию keep-alive, так что дополнительный вызов setsockopt в данной ситуации не требуется.
Но естественно я могу и ошибаться в своих высказываниях, так что прошу сильно палками не кидаться
Здравствуйте, Александр, Вы писали:
А>Статья весьма интересна в плане того. как можно провести точные настройки TCP/IP соединения.
Спасибо
А>Но, если я не ошибаюсь, таким образом невозможно понизить время ожидания до посылки первого keep-alive пакета,
Можно.
А>т. е. функцией setsockopt ты включаеш или выключаеш посулку пакетов (и произойдет это через те самые примерные 2 часа),
Да, так.
А>а функцией WSAIoctl ты задаеш интеревал между посылками, но не до первой посылки. Получается. что первая посылка пакета произойдет через те же самые 2 часа, а вот повторяться они будут через твой интервал.
Нет.
alive.keepalivetime = 10000; // <- время между посылками keep-alive (мс)
alive.keepaliveinterval = 1000;// <- время между посылками при отсутсвии ответа
keepalivetime — собственно, то время, через которое будет происходить посылка с момента установки SIO_KEEPALIVE_VALS. keepaliveinterval — это интервал времени между посылками, когда ответ не будет получен.
А>И второе. функция WSAIoctl с параметром SIO_KEEPALIVE_VALS уже включает (или выключает) опцию keep-alive, так что дополнительный вызов setsockopt в данной ситуации не требуется.
Да.
Здравствуйте, butcher, Вы писали:
А>>а функцией WSAIoctl ты задаеш интеревал между посылками, но не до первой посылки. Получается. что первая посылка пакета произойдет через те же самые 2 часа, а вот повторяться они будут через твой интервал. B>Нет. B>
B> alive.keepalivetime = 10000; // <- время между посылками keep-alive (мс)
B> alive.keepaliveinterval = 1000;// <- время между посылками при отсутсвии ответа
B>
B>keepalivetime — собственно, то время, через которое будет происходить посылка с момента установки SIO_KEEPALIVE_VALS. keepaliveinterval — это интервал времени между посылками, когда ответ не будет получен.
Так вот в том то и дело, что keepaliveinterval — это интервал времени между посылками, когда ответ не будет получен. а keepalivetime — интервал между посылками приполученном ответе, но это не интервал времени между началом простоя соединения и первой посылкой.
А>>И второе. функция WSAIoctl с параметром SIO_KEEPALIVE_VALS уже включает (или выключает) опцию keep-alive, так что дополнительный вызов setsockopt в данной ситуации не требуется. B>Да.
Это я написал исключительно к "заключению" статьи — "После практических испытаний я обнаружил, что функция WSAIoctl перекрывает действие setsockopt"
Здравствуйте, Александр, Вы писали:
А>Так вот в том то и дело, что keepaliveinterval — это интервал времени между посылками, когда ответ не будет получен. а keepalivetime — интервал между посылками приполученном ответе, но это не интервал времени между началом простоя соединения и первой посылкой.
не, ну вы программу пробовали? Через 10 секунд простоя посылается keep-alive пакет. Через 10 секунд ещё..
А>>>И второе. функция WSAIoctl с параметром SIO_KEEPALIVE_VALS уже включает (или выключает) опцию keep-alive, так что дополнительный вызов setsockopt в данной ситуации не требуется. А>Это я написал исключительно к "заключению" статьи — "После практических испытаний я обнаружил, что функция WSAIoctl перекрывает действие setsockopt"
И, на сколько я помню, setsockopt уже не может выключить keep-alive, если они были включены через WSAIoctl. Хотя надо бы проверить, когда время будет свободное.
Здравствуйте, butcher, Вы писали:
B>Здравствуйте, Александр, Вы писали:
А>>Так вот в том то и дело, что keepaliveinterval — это интервал времени между посылками, когда ответ не будет получен. а keepalivetime — интервал между посылками приполученном ответе, но это не интервал времени между началом простоя соединения и первой посылкой. B> B>не, ну вы программу пробовали? Через 10 секунд простоя посылается keep-alive пакет. Через 10 секунд ещё..
Да, спасибо... значит я не правельно понимал эти настройки.... всегда считал, что единственный способ это посылка своих контроллеров
Здравствуйте, butcher, Вы писали:
B> B>я особо ни на что и не претендую, первая статья как никак.. B>а критиковать там наверно есть что, могу выслать экземпляр
B>-- B>С уважением, butcher
И мне пож-ста!
mali@rhitech.com
Re: Определение разрыва TCP-соединения
От:
Аноним
Дата:
23.09.06 11:04
Оценка:
Настраивал сегодня DHCP — в его настройках есть возможность установить оба интервала
АЕ>Авторы: АЕ> Андрей Елсуков
АЕ>Аннотация: АЕ>В статье рассматривается один из способов контроля над работоспособностью TCP/IP-соединения под Windows – создание keep-alive таймера.
Маленькое дополнение: в .NET эти функции обернуты в Socket.IOControl и Socket.SetSocketOption.
АЕ>Авторы: АЕ> Андрей Елсуков
АЕ>Аннотация: АЕ>В статье рассматривается один из способов контроля над работоспособностью TCP/IP-соединения под Windows – создание keep-alive таймера.
А что происходит при определении разрыва соединения? Применяется какой-то асинхронный механизм уведомления или что?
Я так понимаю, если какой-то поток блокирован на recv() на этом сокете, то при разрыве соединения он отвалится с кодом возврата -1. А вот если никто не блокирован на recv(), то что?
АЕ>Авторы: АЕ> Андрей Елсуков
АЕ>Аннотация: АЕ>В статье рассматривается один из способов контроля над работоспособностью TCP/IP-соединения под Windows – создание keep-alive таймера.
сколько запросов посылается при отсутсвии ответа на keep-alive? то есть после того как пропала связь через какое время прийдет сообщение FD_CLOSE?
Здравствуйте, Аноним, Вы писали:
А>сколько запросов посылается при отсутсвии ответа на keep-alive? то есть после того как пропала связь через какое время прийдет сообщение FD_CLOSE?
Спецификация Keep-Alives описана в секции 4.2.3.6 of RFC 1122 (http://rfc.net/rfc1122.html#p101), однако не все провайдеры следуют ей. Например (из RFC 1122):
Keep-alive packets MUST only be sent when no data or acknowledgement packets have been received for the connection within an interval.
Тем не менее TCP стек Windows (проверено в Windows XP SP2) реализует это таким образом: если после начала посыла Keep-Alives (как результата отсутствия входящих пакетов, включая acks, в течение KEEP_ALIVE_TIME), однако до достижения максимального значения неподтвержденных Keep-Alive ретрансмиссий (то есть когда связь считается инвалидной) TCP стек ретрансмитит недошедший пакет, то Keep-Alive процесс начинается сначала. Так как интервал между ретрансмиссиями с каждыи разом растет (см. алгоротм в RFC 2998), у Keep-Alive-а с каждым разом повышается шанс втиснуться и между ретрансмиссиями данных, то есть успеть отработать в отведенное ему время равное KEEP_ALIVE_TIME + KEEP_ALIVE_INTERVAL* KEEPALIVE_PROBES и сообщить о разрыве связи. Куда хуже обстоят дела у стека Linux (проверял для 2.6.5): как только стек начал ретрансмиссию неподтвержденных данных, Keep-Alive уже не включится вне зависимости от интервала между ретрансмиссиями.
Как следствие, в Linux-е Keep-Alive имеет смысл использовать только если интервалы между записью в сокет больше чем KEEP_ALIVE_TIME + KEEP_ALIVE_INTERVAL* KEEPALIVE_PROBES. При большей частоте посылки Keep-Alives просто не будут иметь смысла. Таким образом стек Linux расчитывает на retransmission limit для определения разрыва связи.
Количество неудачных попыток, после которого соединение считается невалиндым, можно устанавливить в Win32 только глобально-системно (хранится в HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters, параметр TcpMaxDataRetransmissions (значение по умолчанию = 5); для оставшихся параметров уже есть возможность устанавки для каждого соединения индивидуально через ::WSAIoctl). В Linux все keep-alive параметры можно устанавливать индивидуально для каждого соединения через setsockopt.
-- Андрей
Re[3]: Определение разрыва TCP-соединения
От:
Аноним
Дата:
28.10.06 15:46
Оценка:
Здравствуйте, Андрей Коростелев
То есть получается, что после того как прошло время, равно KEEP_ALIVE_TIME и за это время никаких данные не передавалось и не принималось посылается keep-alive пакет и если в течении KEEP_ALIVE_INTERVAL интервала ответа на keep-alive пакет не поступилу соединение признается инвалидным. так?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Андрей Коростелев А>То есть получается, что после того как прошло время, равно KEEP_ALIVE_TIME и за это время никаких данные не передавалось и не принималось посылается keep-alive пакет
Почти. Если данные не принимались и не было отослано ни одного подтвержденного пакета.
А> и если в течении KEEP_ALIVE_INTERVAL интервала ответа на keep-alive пакет не поступилу соединение признается инвалидным. так?
Соединение признается инвалидным по прошествию KEEPALIVE_PROBES безответных посылок keep-alive пакета с интервалом между посылками KEEP_ALIVE_INTERVAL.
-- Андрей
Re[5]: Определение разрыва TCP-соединения
От:
Аноним
Дата:
28.10.06 16:19
Оценка:
Здравствуйте, Андрей Коростелев, Вы писали:
АК>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, Андрей Коростелев А>>То есть получается, что после того как прошло время, равно KEEP_ALIVE_TIME и за это время никаких данные не передавалось и не принималось посылается keep-alive пакет
АК>Почти. Если данные не принимались и не было отослано ни одного подтвержденного пакета.
то есть если никакие данные не передавались длительное время и на последний пакет с данными пришло подтверждение то keep-alive пакет не посылается?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Андрей Коростелев, Вы писали:
АК>>Здравствуйте, Аноним, Вы писали:
А>>>Здравствуйте, Андрей Коростелев А>>>То есть получается, что после того как прошло время, равно KEEP_ALIVE_TIME и за это время никаких данные не передавалось и не принималось посылается keep-alive пакет
АК>>Почти. Если данные не принимались и не было отослано ни одного подтвержденного пакета.
А>то есть если никакие данные не передавались длительное время и на последний пакет с данными пришло подтверждение то keep-alive пакет не посылается?
Просто отсчет KEEP_ALIVE_TIME начнется заново.
-- Андрей
Re[7]: Определение разрыва TCP-соединения
От:
Аноним
Дата:
28.10.06 16:34
Оценка:
Здравствуйте, Андрей Коростелев, Вы писали:
АК>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, Андрей Коростелев, Вы писали:
АК>>>Здравствуйте, Аноним, Вы писали:
А>>>>Здравствуйте, Андрей Коростелев А>>>>То есть получается, что после того как прошло время, равно KEEP_ALIVE_TIME и за это время никаких данные не передавалось и не принималось посылается keep-alive пакет
АК>>>Почти. Если данные не принимались и не было отослано ни одного подтвержденного пакета.
А>>то есть если никакие данные не передавались длительное время и на последний пакет с данными пришло подтверждение то keep-alive пакет не посылается?
АК>Просто отсчет KEEP_ALIVE_TIME начнется заново.
Ну, предположим что нам ничего не шлют и на последний отосланный пакет пришло подтверждение, тогда с этого момента начинается новый отсчет KEEP_ALIVE_TIME. по истечении которого посылается keep-alive пакет так?
а что будет если на последний отосланный пакет не пришло подтверждение?
Здравствуйте, Аноним, Вы писали:
А>Ну, предположим что нам ничего не шлют и на последний отосланный пакет пришло подтверждение, тогда с этого момента начинается новый отсчет KEEP_ALIVE_TIME. по истечении которого посылается keep-alive пакет так?
Именно так.
А>а что будет если на последний отосланный пакет не пришло подтверждение?
Keep-alive таймер взводится начиная с последнего пришедшего пакета (в т.ч. ack-a на отправленный). Если таковых еще не было (приложение еще не получало не передавало никаких данных, которые были подтверждены), то это время отсчитывается от начала установки соединения (входящий syn+ack для активного открытия или входящий ack для пассивного открытия соединения).
Все извини, пошел пить пиво, если еще вопросы — отвечу не раньше понедельника.
-- Андрей
Re[9]: Определение разрыва TCP-соединения
От:
Аноним
Дата:
28.10.06 16:56
Оценка:
Здравствуйте, Андрей Коростелев, Вы писали:
АК>Все извини, пошел пить пиво, если еще вопросы — отвечу не раньше понедельника.
Да нет, все ясно... я так чисто, уточнить... спасибо большое.
АЕ>Авторы: АЕ> Андрей Елсуков
АЕ>Аннотация: АЕ>В статье рассматривается один из способов контроля над работоспособностью TCP/IP-соединения под Windows – создание keep-alive таймера.
наследуются ли эти установки в сокетах? например такой код
sok = socket(...);
WSAIoctl(sok, ...);
sok2 = accept(sok, ...);
на sok2 будет распространяться установка keep-alive? или же у него все будет по умолчанию и прийдется вызывать WSAIoctl?
АЕ>Авторы: АЕ> Андрей Елсуков
АЕ>Аннотация: АЕ>В статье рассматривается один из способов контроля над работоспособностью TCP/IP-соединения под Windows – создание keep-alive таймера.
а почему рассмотрен только виндовс?
Posix.1g расписывает как установить время до первой проверки и периодичность.
это setsockopt, уровень IPPROTO_TCP, параметры:
— TCP_KEEPALIVE — время до первой проверки, по умолчанию 2 часа
— TCP_MAXRT — периодичность проверок при отсутствии ответов, по умолчанию 75 сек
всего проверок 9.
однако не расписывается, как должны применяться эти параметры, и разные ядра реализуют разное поведение, иногда просто не реализуют
нужно быть готовыми к тому, что настройки буду задействованы для всех сокетов со включенным SO_KEEPALIVE, несмотря на указание сокета
