Сообщение Re: Socket KeepAlive или формирование второго канала передач от 03.10.2018 14:34
Изменено 03.10.2018 14:35 Nikolay_Ch
Re: Socket KeepAlive или формирование второго канала передачи данных.
Здравствуйте, LWhisper, Вы писали:
LW>В один прекрасный момент пропадает связь между клиентом и сервером. В этот момент отправитель отваливается на Socket.Send и закрывает коннекцию — информация о закрытии коннекции теряется. По этой причине получатель ничего не знает о том, что данных не будет и продолжает висеть.
Не совсем понятно, у Вас остается висеть recv на получателе? Если send отвалился, это еще не значит, что соединение оборвалось. Таймаут у TCP достаточно большой же.
LW>Спустя пару секунд сеть восстанавливается. Спустя ещё минуту начинают ходить кипалайвы. Но поскольку сеть и сокеты с обеих сторон живы, они успешно сигнализируют о том, что сетка жива.
Как сокет на отправителе жив, если Вы написала, что соединение закрывается?
LW>Проблема в том, что в протокол не заложена информация об изменении состояния запроса и отсутствует подтверждение доставки. Чтобы не ломать обратную совместимость и избавить себя от необходимости вкручивать различные таймауты на каждую операцию и механизмы их анализа для ретраев, хочется заиметь способ ручного управления кипалайвами. Раз в минуту поток из пула посылает в канал KeepAlive'а пакет. Если за 10 минут по каналу KeepAlive'а не пришло ни одного пакета, соединение рубится.
А почему нельзя тупо сделать тогда единый таймаут на получение данных? Если нет посылок, то рубить соединение?
LW>Повторное подключение не подходит — переделок будет столько, что проще сразу сделать хорошо. Сразу делать хорошо сейчас не хочется. Ищу адекватный костыль.
Почему не подходит? Открыть повторное подключение в независимом модуле/классе с событием — соединение потеряно. Если что не так — соединение перезапускается. В основную программу в трек отправления/получения данных встраивается один if и все.
LW>В один прекрасный момент пропадает связь между клиентом и сервером. В этот момент отправитель отваливается на Socket.Send и закрывает коннекцию — информация о закрытии коннекции теряется. По этой причине получатель ничего не знает о том, что данных не будет и продолжает висеть.
Не совсем понятно, у Вас остается висеть recv на получателе? Если send отвалился, это еще не значит, что соединение оборвалось. Таймаут у TCP достаточно большой же.
LW>Спустя пару секунд сеть восстанавливается. Спустя ещё минуту начинают ходить кипалайвы. Но поскольку сеть и сокеты с обеих сторон живы, они успешно сигнализируют о том, что сетка жива.
Как сокет на отправителе жив, если Вы написала, что соединение закрывается?
LW>Проблема в том, что в протокол не заложена информация об изменении состояния запроса и отсутствует подтверждение доставки. Чтобы не ломать обратную совместимость и избавить себя от необходимости вкручивать различные таймауты на каждую операцию и механизмы их анализа для ретраев, хочется заиметь способ ручного управления кипалайвами. Раз в минуту поток из пула посылает в канал KeepAlive'а пакет. Если за 10 минут по каналу KeepAlive'а не пришло ни одного пакета, соединение рубится.
А почему нельзя тупо сделать тогда единый таймаут на получение данных? Если нет посылок, то рубить соединение?
LW>Повторное подключение не подходит — переделок будет столько, что проще сразу сделать хорошо. Сразу делать хорошо сейчас не хочется. Ищу адекватный костыль.
Почему не подходит? Открыть повторное подключение в независимом модуле/классе с событием — соединение потеряно. Если что не так — соединение перезапускается. В основную программу в трек отправления/получения данных встраивается один if и все.
Re: Socket KeepAlive или формирование второго канала передач
Здравствуйте, LWhisper, Вы писали:
LW>В один прекрасный момент пропадает связь между клиентом и сервером. В этот момент отправитель отваливается на Socket.Send и закрывает коннекцию — информация о закрытии коннекции теряется. По этой причине получатель ничего не знает о том, что данных не будет и продолжает висеть.
Не совсем понятно, у Вас остается висеть recv на получателе? Если send отвалился, это еще не значит, что соединение оборвалось. Таймаут у TCP достаточно большой же.
LW>Спустя пару секунд сеть восстанавливается. Спустя ещё минуту начинают ходить кипалайвы. Но поскольку сеть и сокеты с обеих сторон живы, они успешно сигнализируют о том, что сетка жива.
Как сокет на отправителе жив, если Вы написали, что соединение закрывается?
LW>Проблема в том, что в протокол не заложена информация об изменении состояния запроса и отсутствует подтверждение доставки. Чтобы не ломать обратную совместимость и избавить себя от необходимости вкручивать различные таймауты на каждую операцию и механизмы их анализа для ретраев, хочется заиметь способ ручного управления кипалайвами. Раз в минуту поток из пула посылает в канал KeepAlive'а пакет. Если за 10 минут по каналу KeepAlive'а не пришло ни одного пакета, соединение рубится.
А почему нельзя тупо сделать тогда единый таймаут на получение данных? Если нет посылок, то рубить соединение?
LW>Повторное подключение не подходит — переделок будет столько, что проще сразу сделать хорошо. Сразу делать хорошо сейчас не хочется. Ищу адекватный костыль.
Почему не подходит? Открыть повторное подключение в независимом модуле/классе с событием — соединение потеряно. Если что не так — соединение перезапускается. В основную программу в трек отправления/получения данных встраивается один if и все.
LW>В один прекрасный момент пропадает связь между клиентом и сервером. В этот момент отправитель отваливается на Socket.Send и закрывает коннекцию — информация о закрытии коннекции теряется. По этой причине получатель ничего не знает о том, что данных не будет и продолжает висеть.
Не совсем понятно, у Вас остается висеть recv на получателе? Если send отвалился, это еще не значит, что соединение оборвалось. Таймаут у TCP достаточно большой же.
LW>Спустя пару секунд сеть восстанавливается. Спустя ещё минуту начинают ходить кипалайвы. Но поскольку сеть и сокеты с обеих сторон живы, они успешно сигнализируют о том, что сетка жива.
Как сокет на отправителе жив, если Вы написали, что соединение закрывается?
LW>Проблема в том, что в протокол не заложена информация об изменении состояния запроса и отсутствует подтверждение доставки. Чтобы не ломать обратную совместимость и избавить себя от необходимости вкручивать различные таймауты на каждую операцию и механизмы их анализа для ретраев, хочется заиметь способ ручного управления кипалайвами. Раз в минуту поток из пула посылает в канал KeepAlive'а пакет. Если за 10 минут по каналу KeepAlive'а не пришло ни одного пакета, соединение рубится.
А почему нельзя тупо сделать тогда единый таймаут на получение данных? Если нет посылок, то рубить соединение?
LW>Повторное подключение не подходит — переделок будет столько, что проще сразу сделать хорошо. Сразу делать хорошо сейчас не хочется. Ищу адекватный костыль.
Почему не подходит? Открыть повторное подключение в независимом модуле/классе с событием — соединение потеряно. Если что не так — соединение перезапускается. В основную программу в трек отправления/получения данных встраивается один if и все.