Простейший случай.
Есть сервер и клиент. Сервер только отвечат на вопросы. Запрос клиента — ответ сервера. Только так. И пока не получен ответ от сервера, клиент дальше делать ничего не может.

Вот все говорят: "Не отключайте алгоритм Нейгла. Ай-яй, как нехорошо отключать алгоритм Нейгла."
Но как реализовать эту функциональность не отключая его? Я не понимаю. Как это сделать если я не могу быть уверенным, что данные хотя бы были отосланы. Я сделаю send(запрос_к_серверу), буду ждать ответа, а запрос будет тихо себе сидеть в буфере tcp. И как быть?

Или в данном случае — вполне нормально отключить алгоритм Нейгла?

Тогда еще такой вопрос. А зачем мне вообще алгоритм Нейгла, если я сам могу реализовать его функциональность и при этом иметь столь желаемую функцию flush()? Возьму себе буфер, который буду отправлять в сеть только по накоплению, или же по требованию (flush()). Т.е. решается вопрос большого количества мелких пакетов (их не будет, мы же буферизируем) и в то же время я в любой момент, когда мне нужно могу сделать flush() и быть уверен, что все данные были отправлены в сеть.

Или для подобных задач лучше использовать протоколы более высокого уровня? А как тогда они это делают?


Я понимаю что у всех уже оскомина от таких вопросов, но будте милосердны

A>Вот все говорят: "Не отключайте алгоритм Нейгла. Ай-яй, как нехорошо отключать алгоритм Нейгла."
A>Но как реализовать эту функциональность не отключая его? Я не понимаю. Как это сделать если я не могу быть уверенным, что данные хотя бы были отосланы. Я сделаю send(запрос_к_серверу), буду ждать ответа, а запрос будет тихо себе сидеть в буфере tcp. И как быть?
Тихо сидеть он там не будет. Посидит совсем чуть-чуть времени, и отправится. Но вообще для протоколов активно юзающих режим запрос/ответ короткими данными нагл и вправда стоит отключать — для повышения скорости. Для того это отключение и предусмотрели (а не для того чтобы превращать tcp в datagram oriented как некоторые пытаются сделать(.

A>Или в данном случае — вполне нормально отключить алгоритм Нейгла?
A>Тогда еще такой вопрос. А зачем мне вообще алгоритм Нейгла, если я сам могу реализовать его функциональность и при этом иметь столь желаемую функцию flush()?
Затем что вы не знаете тонких деталей физ линии чтобы эффективно буферизовать траффик.

Здравствуйте, Аноним, Вы писали:

А>Тихо сидеть он там не будет. Посидит совсем чуть-чуть времени, и отправится.
Так можно на это полагаться? Или в общем случае это все-таки не гарантируется.

А>Затем что вы не знаете тонких деталей физ линии чтобы эффективно буферизовать траффик.
Гм.. да, верно

Здравствуйте, Aris, Вы писали:

A>Здравствуйте, Аноним, Вы писали:

А>>Тихо сидеть он там не будет. Посидит совсем чуть-чуть времени, и отправится.
A>Так можно на это полагаться?
да

А>>Затем что вы не знаете тонких деталей физ линии чтобы эффективно буферизовать траффик.
A>Гм.. да, верно

nagle-алгоритм использует блокировки, но это не хорошо. почему бы не юзать non-blocking socket? Т.е. нужно сделать так что-бы сервер не ждал, а работал в потоке. К тому же tcp- это stream протокол.

Здравствуйте, Аноним, Вы писали:

А>nagle-алгоритм использует блокировки, но это не хорошо. почему бы не юзать non-blocking socket? Т.е. нужно сделать так что-бы сервер не ждал, а работал в потоке. К тому же tcp- это stream протокол.

Nagle не использует блокировки

Здравствуйте, Aris, Вы писали:

A>Или в данном случае — вполне нормально отключить алгоритм Нейгла?

Ну отключите. Только старайтесь тогда свой запрос не писать в сокет мелкими кусками по пять байт, а то с них станется уехать каждый в своем пакете

Если вы задаетесь вопросами включения / отключения алгоритма Нагла, то что-то с вашей программной конструкцией нехорошо .. не встают такие вопросы при адекватном проектировании, а если и встают, то от праздного любопытства и пофиг там TCP_NODELAY выставлен или нет .. все пашет

Здравствуйте, Pepel, Вы писали:

P>Если вы задаетесь вопросами включения / отключения алгоритма Нагла, то что-то с вашей программной конструкцией нехорошо .. не встают такие вопросы при адекватном проектировании, а если и встают, то от праздного любопытства и пофиг там TCP_NODELAY выставлен или нет .. все пашет

По-вашему, TCP_NODELAY придумали для неадекватных программистов?

именно так .. в точку, опция TCP_NODELAY используется неадекватными разработчиками .. жизнь подверждает ежедневно .. нигде и никому еще не помогла ..

Здравствуйте, Аноним, Вы писали:

А>nagle-алгоритм использует блокировки, но это не хорошо. почему бы не юзать non-blocking socket? Т.е. нужно сделать так что-бы сервер не ждал, а работал в потоке. К тому же tcp- это stream протокол.
Алгоритм Нейгла не имеет ничего общего с неблокирующими сокетами, ровно как и с блокирующими. Это ортогональные понятия.
Я что-то вообще не могу понять, к чему ваш комментарий.

>Nagle не использует блокировки
ok, тогда таймауты

Алгоритм Нейгла не дает отправителю передавать новые данные, пока он не получает недостающие ACK, в то время
как стратегия отложенных ACK не дает получателю передавать ACK, пока не прибудут новые
данные. Рано или поздно, блокировка по времени (таймаут) для задержанных ACK разорвет
эту тупиковую ситуацию, но при этом возрастут задержки для тех операций, которые без
этого могли бы завершиться намного быстрее

Здравствуйте, Аноним, Вы писали:

>>Nagle не использует блокировки
А>ok, тогда таймауты

Это не те таймауты. Внутри TCP много разных таймаутов, "пользователю" (т.е., программисту) они более-менее не видны, но отказаться от них нельзя.

Здравствуйте, Pepel, Вы писали:

P>именно так .. в точку, опция TCP_NODELAY используется неадекватными разработчиками .. жизнь подверждает ежедневно .. нигде и никому еще не помогла ..

Включение NO_DELAY помогает в случае, когда протокол взаимодействия подразумевает активные вычисления в ходе обмена данными. Например, в SSL, при установке соединения (хэндшейке), сервер отправляет свой сертификат клиенту, следом генерится и отправляется клиенту пакет ServerKeyExchange, генерация которого занимает основное время хэндшейка. Суть в том, что клиент простаивает, пока не получит сертификат сервера и оптимизацией будет немедленная отправка сертификата клиенту (с тем, чтобы он мог выполнить его валидацию) и только потом генерация и отправка ServerKeyExchange message. В этом случае Nagle должен быть отключен.

Здравствуйте, Pepel, Вы писали:

P>Если вы задаетесь вопросами включения / отключения алгоритма Нагла, то что-то с вашей программной конструкцией нехорошо .. не встают такие вопросы при адекватном проектировании, а если и встают, то от праздного любопытства и пофиг там TCP_NODELAY выставлен или нет .. все пашет

Отключение Nagle используется для повышения параллелизма вычислений на клиенте и сервере.

Здравствуйте, g_i, Вы писали:

g_i>Отключение Nagle используется для повышения параллелизма вычислений на клиенте и сервере.

Прошу обосновать минусы.

Здравствуйте, g_i, Вы писали:

g_i>Включение NO_DELAY помогает в случае, когда протокол взаимодействия подразумевает активные вычисления в ходе обмена данными. Например, в SSL, при установке соединения (хэндшейке), сервер отправляет свой сертификат клиенту, следом генерится и отправляется клиенту пакет ServerKeyExchange, генерация которого занимает основное время хэндшейка. Суть в том, что клиент простаивает, пока не получит сертификат сервера и оптимизацией будет немедленная отправка сертификата клиенту (с тем, чтобы он мог выполнить его валидацию) и только потом генерация и отправка ServerKeyExchange message. В этом случае Nagle должен быть отключен.

Обычно Наггл посылает первый сегмент сразу, при условии, что больше нет неподтвержденных сегментов. А вот следующий он посылает либо с задержкой до подтверждения, либо если сегмент набрался уже достаточно большой. Кроме того, ответ от другой стороны принесет и подтверждение, что разблокирует Наггл.

Поэтому для протоколов, которым нужен быстрый обмен короткими сообщениями (т.е., укладывающимися в один сегмент), выставлять опцию NODELAY не имеет смысла, она не повлияет на результат. Другое дело, если сообщения достаточно длинные, больше одного сегмента. Тут, да, Наггл может мешать и выключение его может иметь смысл.

Здравствуйте, Аноним, Вы писали:

g_i>>Отключение Nagle используется для повышения параллелизма вычислений на клиенте и сервере.
А>Прошу обосновать минусы.

Трудно обосновать несогласие с непонятным утверждением
"... для уменьшения времени отклика" еще куда ни шло, но "... для повышения параллелизма вычислений на клиенте и сервере" — бред какой-то. Извините.

Здравствуйте, Michael Chelnokov, Вы писали:

http://rsdn.ru/forum/network/3475612.1.aspx

Автор: g_i
Дата: 21.07.09

Здравствуйте, Michael Chelnokov, Вы писали:

MC>Трудно обосновать несогласие с непонятным утверждением
MC>"... для уменьшения времени отклика" еще куда ни шло, но "... для повышения параллелизма вычислений на клиенте и сервере" — бред какой-то. Извините.

"Не понял, но несогласен!"