История изменений
Исправление user_id_68054, (текущая версия) :
кстати именно такое использование было более популярно во времена Reno и именно по-этому это поведение по умолчанию.
[судя по всему речь о TCP Reno]..
что-то я запутался :) — какое поведение и когда-и-где было популярно?
выполнение определенных действий по таймеру это усложнение и доп расходы
мне кажется в ядре [в сетевой подсистеме] там уже столько всего по таймеру делается — что то не так важно если появится +ещё что-то новое :-) . кучу всех этих сетевых манипуляций связано с таймерами.
ну не обязятельно прям всё строго делать всё по таймеру (строго для всех TCP-сессий).. если так важна производительноть то можно было бы например «схалявить» следующим образом:
например проверять случайно каждые случайно-взятые 5%-от-всех-долгоживущих-открытых TCP-сессий, через каждые 2 часа, на предмет того что TCP-сессия точно не является сломанной (в случае обнаружения сломанной сессии — закрывать).
а) у keepalive есть ощутимый недостаток — если destination будет временно недоступен, то кипэлайв это обнаружит и разорвет сессию, и обрабатывать это прийдется на прикладном уровне
ну будет дисконнект,и всё делов-то [ну может с генерацией ошибки]. темболее это «временно» может затянуться на много минут. SO_KEEPALIVE не сразу отключает как только обанужит обрыв, а ещё долго пытается это опровергнуть:).
б) на сколько устанавливать таймер кипэлайвов? неясно. именно по этим двум причинам многие приложения предпочитают более гибкий контроль с кипэлайвами на уровне прикладного протокола.
ответ на этот вопрос — очень простой :) . сколько устанавливать таймер SO_KEEPALIVE — совершенно не важно совершенно. так как всё равно угодить на всех не получится — то нужно что бы это работало хотя бы как-то.
если программа сильно «умная» настолько что ей важны эти промежутки времени — то пусть такая «умная» программа умышленно отключает SO_KEEPALIVE (сразу же после инициализации сокета) и использует свои методы контроля разрывов.
в) _огромное_ количество легаси кода и интерфейс, заложенный в стандарт
а когда включили tcp_fastopen — почему же тогда не думали о legacy и интерфейсах? типа «программы расчитаны на медленное открытие, а мы тут бац и не тормозим при коннекте :)»
плюс смотри SCTP
ну а что-там в крадце опиши [то что касается найшей темы] — отслеживание физических обрывов — включено в SCTP умолчанию? если да — то это радует :)
Исправление user_id_68054, :
кстати именно такое использование было более популярно во времена Reno и именно по-этому это поведение по умолчанию.
[судя по всему речь о TCP Reno]..
что-то я запутался :) — какое поведение и когда-и-где было популярно?
выполнение определенных действий по таймеру это усложнение и доп расходы
мне кажется в ядре [в сетевой подсистеме] там уже столько всего по таймеру делается — что то не так важно если появится +ещё что-то новое :-) . кучу всех этих сетевых манипуляций связано с таймерами.
ну не обязятельно прям всё строго делать всё по таймеру (строго для всех TCP-сессий).. если так важна производительноть то можно было бы например «схалявить» следующим образом:
например проверять случайно каждые случайно-взятые 5%-от-всех-долгоживущих-открытых TCP-сессий, через каждые 2 часа, на предмет того что TCP-сессия точно не является сломанной (в случае обнаружения сломанной сессии — закрывать).
а) у keepalive есть ощутимый недостаток — если destination будет временно недоступен, то кипэлайв это обнаружит и разорвет сессию, и обрабатывать это прийдется на прикладном уровне
ну будет дисконнект,и всё делов-то [ну может с генерацией ошибки]. темболее это «временно» может затянуться на много минут. SO_KEEPALIVE не сразу отключает как только обанужит обрыв, а ещё долго пытается это опровергнуть:).
б) на сколько устанавливать таймер кипэлайвов? неясно. именно по этим двум причинам многие приложения предпочитают более гибкий контроль с кипэлайвами на уровне прикладного протокола.
ответ на этот вопрос — очень простой :) . сколько устанавливать таймер SO_KEEPALIVE — совершенно не важно совершенно. так как всё равно угодить на всех не получится — то нужно что бы это работало хотя бы как-то.
если программа сильно «умная» настолько что ей важны эти промежутки времени — то пусть такая «умная» программа умышленно отключает SO_KEEPALIVE (сразу же после инициализации сокета) и использует свои методы контроля разрывов.
в) _огромное_ количество легаси кода и интерфейс, заложенный в стандарт
а когда включили tcp_fastopen — почему же тогда не думали о legacy и интерфейсах? типа «программы расчитаны на медленное открытие, а мы тут бац и не тормозим при конекте :)»
плюс смотри SCTP
ну а что-там в крадце опиши [то что касается найшей темы] — отслеживание физических обрывов — включено в SCTP умолчанию? если да — то это радует :)
Исправление user_id_68054, :
кстати именно такое использование было более популярно во времена Reno и именно по-этому это поведение по умолчанию.
[судя по всему речь о TCP Reno]..
что-то я запутался :) — какое поведение и когда-и-где было популярно?
выполнение определенных действий по таймеру это усложнение и доп расходы
мне кажется в ядре [в сетевой подсистеме] там уже столько всего по таймеру делается — что то не так важно если появится +ещё что-то новое :-) . кучу всех этих сетевых манипуляций связано с таймерами.
ну не обязятельно прям всё строго делать всё по таймеру (трого для всех TCP-сессий).. если так важна производительноть то можно было бы например «схалявить» следующим образом:
например проверять случайно каждые случайно-взятые 5%-от-всех-долгоживущих-открытых TCP-сессий, через каждые 2 часа, на предмет того что TCP-сессия точно не является сломанной (в случае обнаружения сломанной сессии — закрывать).
а) у keepalive есть ощутимый недостаток — если destination будет временно недоступен, то кипэлайв это обнаружит и разорвет сессию, и обрабатывать это прийдется на прикладном уровне
ну будет дисконнект,и всё делов-то [ну может с генерацией ошибки]. темболее это «временно» может затянуться на много минут. SO_KEEPALIVE не сразу отключает как только обанужит обрыв, а ещё долго пытается это опровергнуть:).
б) на сколько устанавливать таймер кипэлайвов? неясно. именно по этим двум причинам многие приложения предпочитают более гибкий контроль с кипэлайвами на уровне прикладного протокола.
ответ на этот вопрос — очень простой :) . сколько устанавливать таймер SO_KEEPALIVE — совершенно не важно совершенно. так как всё равно угодить на всех не получится — то нужно что бы это работало хотя бы как-то.
если программа сильно «умная» настолько что ей важны эти промежутки времени — то пусть такая «умная» программа умышленно отключает SO_KEEPALIVE (сразу же после инициализации сокета) и использует свои методы контроля разрывов.
в) _огромное_ количество легаси кода и интерфейс, заложенный в стандарт
а когда включили tcp_fastopen — почему же тогда не думали о legacy и интерфейсах? типа «программы расчитаны на медленное открытие, а мы тут бац и не тормозим при конекте :)»
плюс смотри SCTP
ну а что-там в крадце опиши [то что касается найшей темы] — отслеживание физических обрывов — включено в SCTP умолчанию? если да — то это радует :)
Исходная версия user_id_68054, :
кстати именно такое использование было более популярно во времена Reno и именно по-этому это поведение по умолчанию.
[судя по всему речь о TCP Reno]..
что-то я запутался :) — какое поведение и когда-и-где было полурно?
выполнение определенных действий по таймеру это усложнение и доп расходы
мне кажется в ядре [в сетевой подсистеме] там уже столько всего по таймеру делается — что то не так важно если появится +ещё что-то новое :-) . кучу всех этих сетевых манипуляций связано с таймерами.
ну не обязятельно прям всё строго делать всё по таймеру (трого для всех TCP-сессий).. если так важна производительноть то можно было бы например «схалявить» следующим образом:
например проверять случайно каждые случайно-взятые 5%-от-всех-долгоживущих-открытых TCP-сессий, через каждые 2 часа, на предмет того что TCP-сессия точно не является сломанной (в случае обнаружения сломанной сессии — закрывать).
а) у keepalive есть ощутимый недостаток — если destination будет временно недоступен, то кипэлайв это обнаружит и разорвет сессию, и обрабатывать это прийдется на прикладном уровне
ну будет дисконнект,и всё делов-то [ну может с генерацией ошибки]. темболее это «временно» может затянуться на много минут. SO_KEEPALIVE не сразу отключает как только обанужит обрыв, а ещё долго пытается это опровергнуть:).
б) на сколько устанавливать таймер кипэлайвов? неясно. именно по этим двум причинам многие приложения предпочитают более гибкий контроль с кипэлайвами на уровне прикладного протокола.
ответ на этот вопрос — очень простой :) . сколько устанавливать таймер SO_KEEPALIVE — совершенно не важно совершенно. так как всё равно угодить на всех не получится — то нужно что бы это работало хотя бы как-то.
если программа сильно «умная» настолько что ей важны эти промежутки времени — то пусть такая «умная» программа умышленно отключает SO_KEEPALIVE (сразу же после инициализации сокета) и использует свои методы контроля разрывов.
в) _огромное_ количество легаси кода и интерфейс, заложенный в стандарт
а когда включили tcp_fastopen — почему же тогда не думали о legacy и интерфейсах? типа «программы расчитаны на медленное открытие, а мы тут бац и не тормозим при конекте :)»
плюс смотри SCTP
ну а что-там в крадце опиши [то что касается найшей темы] — отслеживание физических обрывов — включено в SCTP умолчанию? если да — то это радует :)