История изменений
Исправление pon4ik, (текущая версия) :
Плохой пример, но с большими пакетами данных такая ситуация(залипон на keep-alive), хоть и менее вероятна, но имеет место быть.
Вот допустим у тебя есть фид с данными(ну пусть те же презренные sms). Ты подключился к серверу, авторизовался, на этом ваши взаимные движения кончились(дальше клиент только читает). Sms лезет в mtu, и вообще для наглядности - выравнивается по `mtu - <служебные заголовки>`.
Ситуация когда ты будешь ждать отработки механизма keep-alive весь таймаут:
Для read(на стороне клиента заблокируется на keep-alive):
- Сервер послал последнее sms из своей очереди
- Ты его принял
- Ты послал ack
- Сервер умер без fin/fin не долетел по другой причине
- Ты вызвал read(заблокировался на keep-alive)
Для write (на стороне сервера, следующий send заблокируется на keep-alive):
- Сервер послал последнее sms из своей очереди
- Ты его принял
- Ты послал ack
- Ты умер без fin/fin не долетел по другой причине
- Сервер послал ещё одно sms (вызвал send)
- Сервер послал ещё одно sms (вызвал send, заблокировался на keep-alive, после того, как переполнил буфер)
Исправление pon4ik, :
Плохой пример, но с большими пакетами данных такая ситуация(залипон на keep-alive), хоть и менее вероятна, но имеет место быть.
Вот допустим у тебя есть фид с данными(ну пусть те же презренные sms). Ты подключился к серверу, авторизовался, на этом ваши взаимные движения кончились(дальше клиент только читает). Sms лезет в mtu, и вообще для наглядности - выравнивается по `mtu - <служебные заголовки>`.
Ситуация когда ты будешь ждать отработки механизма keep-alive весь таймаут:
Для read(на стороне клиента заблокируется на keep-alive):
- Сервер послал последнее sms из своей очереди
- Ты его принял
- Ты послал ack
- Сервер умер без fin
- Ты вызвал read(заблокировался на keep-alive)
Для write (на стороне сервера, следующий send заблокируется на keep-alive):
- Сервер послал последнее sms из своей очереди
- Ты его принял
- Ты послал ack
- Ты умер без fin
- Сервер послал ещё одно sms (вызвал send)
- Сервер послал ещё одно sms (вызвал send, заблокировался на keep-alive, после того, как переполнил буфер)
Исправление pon4ik, :
Плохой пример, но с большими пакетами данных такая ситуация(залипон на keep-alive), хоть и менее вероятна, но имеет место быть.
Вот допустим у тебя есть фид с данными(ну пусть те же презренные sms). Ты подключился к серверу, авторизовался, на этом ваши взаимные движения кончились(дальше клиент только читает). Sms лезет в mtu, и вообще для наглядности - выравнивается по `mtu - <служебные заголовки>`.
Ситуация когда ты будешь ждать отработки механизма keep-alive весь таймаут:
Для read(на стороне клиента заблокируется на keep-alive):
- Сервер послал последнее sms из своей очереди
- Ты его принял
- Ты послал ack
- Сервер умер без fin
- Ты вызвал read(заблокировался на keep-alive)
Для write (на стороне сервера, следующий send заблокируется на keep-alive):
- Сервер послал последнее sms из своей очереди
- Ты его принял
- Ты послал ack
- Ты умер без fin
- Сервер послал ещё одно sms (вызвал send)
- Сервер послал ещё одно sms (вызвал send, заблокировался на keep-alive, после того, как переполнил буффер)
Исправление pon4ik, :
Плохой пример, но с большими пакетами данных такая ситуация(залипон на keep-alive), хоть и менее вероятна, но имеет место быть.
Вот допустим у тебя есть фид с данными(ну пусть те же презренные sms). Ты подключился к серверу, авторизовался, на этом ваши взаимные движения кончились(дальше клиент только читает). Sms лезет в mtu, и вообще для наглядности - выравнивается по `mtu - <служебные заголовки>`.
Ситуация когда ты будешь ждать отработки механизма keep-alive весь таймаут:
Для read(на стороне клиента заблокируется на keep-alive):
- Сервер послал последнее sms из своей очереди
- Ты его принял
- Ты послал ack
- Сервер умер без fin
- Ты вызвал read(заблокировался на keep-alive)
Для write (на стороне сервера, следующий send заблокируется на keep-alive):
- Сервер послал последнее sms из своей очереди
- Ты его принял
- Ты послал ack
- Ты умер без fin
- Сервер послал ещё одно sms (вызвал send)
- Сервер послал ещё одно sms (вызвал send, заблокировался на keep-alive)
Исправление pon4ik, :
Плохой пример, но с большими пакетами данных такая ситуация(залипон на keep-alive), хоть и менее вероятна, но имеет место быть.
Вот допустим у тебя есть фид с данными(ну пусть те же презренные sms). Ты подключился к серверу, авторизовался, на этом ваши взаимные движения кончились(дальше клиент только читает). Sms лезет в mtu, и вообще для наглядности - выравнивается по `mtu - <служебные заголовки>`.
Ситуация когда ты будешь ждать отработки механизма keep-alive весь таймаут:
Для read(на стороне клиента):
- Сервер послал последнее sms из своей очереди
- Ты его принял
- Ты послал ack
- Сервер умер без fin
- Ты вызвал read
Для write (на стороне сервера):
- Сервер послал последнее sms из своей очереди
- Ты его принял
- Ты послал ack
- Ты умер без fin
- Сервер послал ещё одно sms (вызвал send)
Исправление pon4ik, :
Плохой пример, но с большими пакетами данных такая ситуация(залипон на keep-alive), хоть и менее вероятна, но имеет место быть.
Вот допустим у тебя есть фид с данными(ну пусть те же презренные sms). Ты подключился к серверу, авторизовался, на этом ваши взаимные движения кончились. Sms лезет в mtu, и вообще для наглядности - выравнивается по `mtu - <служебные заголовки>`.
Ситуация когда ты будешь ждать отработки механизма keep-alive весь таймаут:
Для read(на стороне клиента):
- Сервер послал последнее sms из своей очереди
- Ты его принял
- Ты послал ack
- Сервер умер без fin
- Ты вызвал read
Для write (на стороне сервера):
- Сервер послал последнее sms из своей очереди
- Ты его принял
- Ты послал ack
- Ты умер без fin
- Сервер послал ещё одно sms (вызвал send)
Исправление pon4ik, :
Плохой пример, но с большими пакетами данных такая ситуация(залипон на keep-alive), хоть и менее вероятна, но имеет место быть.
Вот допустим у тебя есть фид с данными(ну пусть те же презренные sms). Ты подключился к серверу, авторизовался, на этом ваши взаимные движения кончились. Sms лезет в mtu, и вообще для наглядности - выравнивается по `mtu - <служебные заголовки>`.
Ситуация когда ты будешь ждать отработки механизма keep-alive весь таймаут:
Для read(на стороне клиента):
- Сервер послал последнее sms из своей очереди
- Ты его принял
- Ты послал ack
- Сервер умер без fin
Для write (на стороне сервера):
- Сервер послал последнее sms из своей очереди
- Ты его принял
- Ты послал ack
- Ты умер без fin
- Сервер послал ещё одно sms
Исходная версия pon4ik, :
Плохой пример, но с большими пакетами данных такая ситуация(залипон на keep-alive), хоть и менее вероятна, но имеет место быть.
Вот допустим у тебя есть фид с данными(ну пусть те же презренные sms). Ты подключился к серверу, авторизовался, на этом ваши взаимные движения кончились. Sms лезет в mtu, и вообще для наглядности - выравнивается по `mtu - <служебные заголовки>`.
Ситуация когда ты будешь ждать отработки механизма keep-alive весь таймаут:
Для read:
- Сервер послал последнее sms из своей очереди
- Ты его принял
- Ты послал ack
- Сервер умер без fin
Для write (на стороне сервера):
- Сервер послал последнее sms из своей очереди
- Ты его принял
- Ты послал ack
- Ты умер без fin
- Сервер послал ещё одно sms