FAQ
http://nodejs.org/api/net.html#net_socket_setnodelay_nodelay

Can anyone explain use case, when default buffering is really useful? IMHO,
it just make to place additional code every time, to disable it:

1. If one send data with single block (render template, and return all
page), then Nagle will not help, and will cause double buffering.
2. If one send data as stream, there are 2 subcases:
- small messaging - delay must be disabled to deliver each message ASAP
- big files via pipes - they already have internal buffers (and it's
more effective to increase file buffers)

I don't pretend on 100% coverage. That's just the most used cases, IMHO.
So, looks like it's better to disable Naggle by default
Any ideas?

Vitaly

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Search Discussions

  • Simon at Oct 19, 2012 at 5:08 am
    It looks like noDelay is true by default, which means buffering is off.
    On Thursday, October 18, 2012 8:44:32 PM UTC+7, Vitaly Puzrin wrote:

    http://nodejs.org/api/net.html#net_socket_setnodelay_nodelay

    Can anyone explain use case, when default buffering is really useful?
    IMHO, it just make to place additional code every time, to disable it:

    1. If one send data with single block (render template, and return all
    page), then Nagle will not help, and will cause double buffering.
    2. If one send data as stream, there are 2 subcases:
    - small messaging - delay must be disabled to deliver each message ASAP
    - big files via pipes - they already have internal buffers (and it's
    more effective to increase file buffers)

    I don't pretend on 100% coverage. That's just the most used cases, IMHO.
    So, looks like it's better to disable Naggle by default
    Any ideas?

    Vitaly
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Vitaly Puzrin at Oct 19, 2012 at 5:08 am
    Simon, that's default function param, not default buffering state.

    "By default TCP connections use the Nagle algorithm, they buffer data
    before sending it off." - from the link above.

    пятница, 19 октября 2012 г., 9:00:22 UTC+4 пользователь Simon написал:
    It looks like noDelay is true by default, which means buffering is off.
    On Thursday, October 18, 2012 8:44:32 PM UTC+7, Vitaly Puzrin wrote:

    http://nodejs.org/api/net.html#net_socket_setnodelay_nodelay

    Can anyone explain use case, when default buffering is really useful?
    IMHO, it just make to place additional code every time, to disable it:

    1. If one send data with single block (render template, and return all
    page), then Nagle will not help, and will cause double buffering.
    2. If one send data as stream, there are 2 subcases:
    - small messaging - delay must be disabled to deliver each message ASAP
    - big files via pipes - they already have internal buffers (and it's
    more effective to increase file buffers)

    I don't pretend on 100% coverage. That's just the most used cases, IMHO.
    So, looks like it's better to disable Naggle by default
    Any ideas?

    Vitaly
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Greelgorke at Oct 19, 2012 at 7:14 am
    nagle is a tradeoff. Nagle tries to increase bandwidth usage and increases
    latency for this. thats the desired behavior for the most www use cases
    without realtime requirements (realtime as it meaned, not the
    server-push-communication). opposite to it realtime apps like games are
    more latency dependent their users have usualy enough bandwidth, so nagel
    is contra-productive here.

    And Nagle behaviour is what most developers are expecting for web apps. I'd
    prefer not to turn it off by default. if you know you don't use it in your
    app, just set it off, it is not that hard.

    greez

    Am Freitag, 19. Oktober 2012 07:08:36 UTC+2 schrieb Vitaly Puzrin:
    Simon, that's default function param, not default buffering state.

    "By default TCP connections use the Nagle algorithm, they buffer data
    before sending it off." - from the link above.

    пятница, 19 октября 2012 г., 9:00:22 UTC+4 пользователь Simon написал:
    It looks like noDelay is true by default, which means buffering is off.
    On Thursday, October 18, 2012 8:44:32 PM UTC+7, Vitaly Puzrin wrote:

    http://nodejs.org/api/net.html#net_socket_setnodelay_nodelay

    Can anyone explain use case, when default buffering is really useful?
    IMHO, it just make to place additional code every time, to disable it:

    1. If one send data with single block (render template, and return all
    page), then Nagle will not help, and will cause double buffering.
    2. If one send data as stream, there are 2 subcases:
    - small messaging - delay must be disabled to deliver each message
    ASAP
    - big files via pipes - they already have internal buffers (and it's
    more effective to increase file buffers)

    I don't pretend on 100% coverage. That's just the most used cases, IMHO.
    So, looks like it's better to disable Naggle by default
    Any ideas?

    Vitaly
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Vitaly Puzrin at Oct 19, 2012 at 7:31 am
    IMHO you mix abstract "buffering" and double buffering in real life.
    Buffering is needed, no question. But when you write

    var s = renderTemplate(...)

    then `s` is buffer for your output data. And Nagle will not improve things.
    It will add just useless secondary buffer.

    Can anyone explain, when Nagle will be really useful? Or where is a mistake
    in my example.

    пятница, 19 октября 2012 г., 11:14:22 UTC+4 пользователь greelgorke написал:
    nagle is a tradeoff. Nagle tries to increase bandwidth usage and increases
    latency for this. thats the desired behavior for the most www use cases
    without realtime requirements (realtime as it meaned, not the
    server-push-communication). opposite to it realtime apps like games are
    more latency dependent their users have usualy enough bandwidth, so nagel
    is contra-productive here.

    And Nagle behaviour is what most developers are expecting for web apps.
    I'd prefer not to turn it off by default. if you know you don't use it in
    your app, just set it off, it is not that hard.

    greez

    Am Freitag, 19. Oktober 2012 07:08:36 UTC+2 schrieb Vitaly Puzrin:
    Simon, that's default function param, not default buffering state.

    "By default TCP connections use the Nagle algorithm, they buffer data
    before sending it off." - from the link above.

    пятница, 19 октября 2012 г., 9:00:22 UTC+4 пользователь Simon написал:
    It looks like noDelay is true by default, which means buffering is off.
    On Thursday, October 18, 2012 8:44:32 PM UTC+7, Vitaly Puzrin wrote:

    http://nodejs.org/api/net.html#net_socket_setnodelay_nodelay

    Can anyone explain use case, when default buffering is really useful?
    IMHO, it just make to place additional code every time, to disable it:

    1. If one send data with single block (render template, and return all
    page), then Nagle will not help, and will cause double buffering.
    2. If one send data as stream, there are 2 subcases:
    - small messaging - delay must be disabled to deliver each message
    ASAP
    - big files via pipes - they already have internal buffers (and it's
    more effective to increase file buffers)

    I don't pretend on 100% coverage. That's just the most used cases,
    IMHO. So, looks like it's better to disable Naggle by default
    Any ideas?

    Vitaly
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Greelgorke at Oct 19, 2012 at 9:39 am
    here:
    "In general, since Nagle's algorithm is only a defense against careless
    applications, it will not benefit a carefully written application that
    takes proper care of buffering; the algorithm has either no effect, or
    negative effect on the application."

    taken from Wikipedia btw. If your app is careful, then go and turn it off.
    But i guess most of devs are focusing on business first and don't care
    about details like how tcp works until they have to. so i guess it's ok to
    set it on by default :). to set it off by default sounds for me like a
    premature optimization.

    Am Freitag, 19. Oktober 2012 09:31:07 UTC+2 schrieb Vitaly Puzrin:
    IMHO you mix abstract "buffering" and double buffering in real life.
    Buffering is needed, no question. But when you write

    var s = renderTemplate(...)

    then `s` is buffer for your output data. And Nagle will not improve
    things. It will add just useless secondary buffer.

    Can anyone explain, when Nagle will be really useful? Or where is a
    mistake in my example.

    пятница, 19 октября 2012 г., 11:14:22 UTC+4 пользователь greelgorke
    написал:
    nagle is a tradeoff. Nagle tries to increase bandwidth usage and
    increases latency for this. thats the desired behavior for the most www use
    cases without realtime requirements (realtime as it meaned, not the
    server-push-communication). opposite to it realtime apps like games are
    more latency dependent their users have usualy enough bandwidth, so nagel
    is contra-productive here.

    And Nagle behaviour is what most developers are expecting for web apps.
    I'd prefer not to turn it off by default. if you know you don't use it in
    your app, just set it off, it is not that hard.

    greez

    Am Freitag, 19. Oktober 2012 07:08:36 UTC+2 schrieb Vitaly Puzrin:
    Simon, that's default function param, not default buffering state.

    "By default TCP connections use the Nagle algorithm, they buffer data
    before sending it off." - from the link above.

    пятница, 19 октября 2012 г., 9:00:22 UTC+4 пользователь Simon написал:
    It looks like noDelay is true by default, which means buffering is off.
    On Thursday, October 18, 2012 8:44:32 PM UTC+7, Vitaly Puzrin wrote:

    http://nodejs.org/api/net.html#net_socket_setnodelay_nodelay

    Can anyone explain use case, when default buffering is really useful?
    IMHO, it just make to place additional code every time, to disable it:

    1. If one send data with single block (render template, and return all
    page), then Nagle will not help, and will cause double buffering.
    2. If one send data as stream, there are 2 subcases:
    - small messaging - delay must be disabled to deliver each message
    ASAP
    - big files via pipes - they already have internal buffers (and
    it's more effective to increase file buffers)

    I don't pretend on 100% coverage. That's just the most used cases,
    IMHO. So, looks like it's better to disable Naggle by default
    Any ideas?

    Vitaly
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Vitaly Puzrin at Oct 19, 2012 at 9:52 am
    It's not a religion question, "do you beleive in nagle power or not". So,
    abstract talks will not make anything useful.

    Just give one example from the real life, when nagle in node is useful. If
    you know.

    пятница, 19 октября 2012 г., 13:39:28 UTC+4 пользователь greelgorke написал:
    here:
    "In general, since Nagle's algorithm is only a defense against careless
    applications, it will not benefit a carefully written application that
    takes proper care of buffering; the algorithm has either no effect, or
    negative effect on the application."

    taken from Wikipedia btw. If your app is careful, then go and turn it off.
    But i guess most of devs are focusing on business first and don't care
    about details like how tcp works until they have to. so i guess it's ok to
    set it on by default :). to set it off by default sounds for me like a
    premature optimization.

    Am Freitag, 19. Oktober 2012 09:31:07 UTC+2 schrieb Vitaly Puzrin:
    IMHO you mix abstract "buffering" and double buffering in real life.
    Buffering is needed, no question. But when you write

    var s = renderTemplate(...)

    then `s` is buffer for your output data. And Nagle will not improve
    things. It will add just useless secondary buffer.

    Can anyone explain, when Nagle will be really useful? Or where is a
    mistake in my example.

    пятница, 19 октября 2012 г., 11:14:22 UTC+4 пользователь greelgorke
    написал:
    nagle is a tradeoff. Nagle tries to increase bandwidth usage and
    increases latency for this. thats the desired behavior for the most www use
    cases without realtime requirements (realtime as it meaned, not the
    server-push-communication). opposite to it realtime apps like games are
    more latency dependent their users have usualy enough bandwidth, so nagel
    is contra-productive here.

    And Nagle behaviour is what most developers are expecting for web apps.
    I'd prefer not to turn it off by default. if you know you don't use it in
    your app, just set it off, it is not that hard.

    greez

    Am Freitag, 19. Oktober 2012 07:08:36 UTC+2 schrieb Vitaly Puzrin:
    Simon, that's default function param, not default buffering state.

    "By default TCP connections use the Nagle algorithm, they buffer data
    before sending it off." - from the link above.

    пятница, 19 октября 2012 г., 9:00:22 UTC+4 пользователь Simon написал:
    It looks like noDelay is true by default, which means buffering is off.
    On Thursday, October 18, 2012 8:44:32 PM UTC+7, Vitaly Puzrin wrote:

    http://nodejs.org/api/net.html#net_socket_setnodelay_nodelay

    Can anyone explain use case, when default buffering is really useful?
    IMHO, it just make to place additional code every time, to disable it:

    1. If one send data with single block (render template, and return
    all page), then Nagle will not help, and will cause double buffering.
    2. If one send data as stream, there are 2 subcases:
    - small messaging - delay must be disabled to deliver each message
    ASAP
    - big files via pipes - they already have internal buffers (and
    it's more effective to increase file buffers)

    I don't pretend on 100% coverage. That's just the most used cases,
    IMHO. So, looks like it's better to disable Naggle by default
    Any ideas?

    Vitaly
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Bert Belder at Oct 21, 2012 at 12:32 am
    Can anyone explain use case, when default buffering is really useful?
    IMHO, it just make to place additional code every time, to disable it:

    I'm going to assume that you mean "delay" instead of "buffering" here.
    It's on by default because all (modern) operating systems have it on by
    default. Node doesn't do anything to enable Nagle, it just makes a specific
    syscall to turn it off when you use .setNoDelay().
    1. If one send data with single block (render template, and return all
    page), then Nagle will not help, and will cause double buffering.

    There is no "double buffering" - the TCP stack will always buffer your data
    so it can retransmit your data when delivery fails. The (in certain
    circumstances) problematic part is - literally - the delay. When nagle is
    enabled the tcp stack will sometimes hold your data for a small amount of
    time (typically in the order of 100ms) before putting it on the wire.

    Please note that when you send a not-very-small amount of data (such that
    it fills up at least 1 TCP packet - typically around 1.5kb) your data will
    be transmitted without any delay.
    2. If one send data as stream, there are 2 subcases:
    - small messaging - delay must be disabled to deliver each message ASAP
    If you are sending small messages over a persistent connection, that is
    indeed the situation where you might want to use setNoDelay. Note that if
    you send a small amount of data and tear down the connection afterwards
    (such as sending a small http response) the delay doesn't occur.
    - big files via pipes - they already have internal buffers (and it's
    more effective to increase file buffers)

    Pipes and unix sockets do not use (or even support) the Nagle algorithm. So
    it's off by default already.
    I don't pretend on 100% coverage. That's just the most used cases, IMHO.
    So, looks like it's better to disable Naggle by default.
    We are not going to change anything about this.
    It's not a religion question, "do you beleive in nagle power or not". So,
    abstract talks will not make anything useful.

    It answered your question "why is nagle on by default" quite adequately imo
    ...
    Just give one example from the real life, when nagle in node is useful.
    If you know.

    ```
    require('net').createServer(function(sock) {
    sock.write('hello');
    sock.end('world');
    }).listen(1234);
    ```

    With nagle enabled the entire message will be sent in a single tcp packet.
    With nagle off, 2 packets will be sent.

    - Bert

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Vitaly Puzrin at Oct 21, 2012 at 12:31 am

    It's on by default because all (modern) operating systems have it on by
    default. Node doesn't do anything to enable Nagle, it just makes a specific
    syscall to turn it off when you use .setNoDelay().
    ...

    We are not going to change anything about this.
    >

    Ok. I can understand this position. Thanks for explanation.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupnodejs @
categoriesnodejs
postedOct 18, '12 at 1:44p
activeOct 21, '12 at 12:32a
posts9
users4
websitenodejs.org
irc#node.js

People

Translate

site design / logo © 2022 Grokbase