Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's Always TCP_NODELAY

brooker.co.za

Post reply on HN
Print view View original

41–50 of 186 posts

Re: It's Always TCP_NODELAY

#41

Post by anonymousiam »

gerdesj wrote: post #40
anonymousiam wrote: post #4

The Nagle algorithm was created back in the day of multi-point networking. Multiple hosts were all tied to the same communications (Ethernet) channel, so they would use CSMA ( https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_... ) to avoid collisions. CSMA is no longer necessary on Ethernet today because all modern connections are point-to-point with only two "hosts" per channel. (Each host can have any nu…

I think you are confusing network layers and their functionality. "CSMA is no longer necessary on Ethernet today because all modern connections are point-to-point with only two "hosts" per channel." Ethernet really isn't ptp. You will have a switch at home (perhaps in your router) with more than two ports on it. At layer 1 or 2 how do you mediate your traffic, without CSMA? Take a single switch with n ports on it, wh…

It's P2P as far as the physical layer (L1) is concerned.

Usually, full duplex requires two separate channels. The introduction of a hybrid on each end allows the use of the same channel at the same time.

Some progress has been made in doing the same thing with radio links, but it's harder.

Nagle's algorithm is somewhat intertwined with the backoff timer in the sense that it prevents transmitting a packet until some condition is met. IIRC, setting the TCP_NODELAY flag will also disable the backoff timer, at least this is true in the case of TCP/IP over AX25.

Re: It's Always TCP_NODELAY

#42

Post by gerdesj »

anonymousiam wrote: post #41
gerdesj wrote: post #40

Earlier quoted context omitted.

I think you are confusing network layers and their functionality. "CSMA is no longer necessary on Ethernet today because all modern connections are point-to-point with only two "hosts" per channel." Ethernet really isn't ptp. You will have a switch at home (perhaps in your router) with more than two ports on it. At layer 1 or 2 how do you mediate your traffic, without CSMA? Take a single switch with n ports on it, wh…

It's P2P as far as the physical layer (L1) is concerned. Usually, full duplex requires two separate channels. The introduction of a hybrid on each end allows the use of the same channel at the same time. Some progress has been made in doing the same thing with radio links, but it's harder. Nagle's algorithm is somewhat intertwined with the backoff timer in the sense that it prevents transmitting a packet until some c…

Sorry?

Ethernet has had the concept of full duplex for several decades and I have no idea what you mean by: "hybrid on each end allows the use of the same channel at the same time."

The physical electrical connections between a series of ethernet network ports (switch or end point - it doesn't matter) are mediated by CSMA.

No idea why you are mentioning radios. That's another medium.

Re: It's Always TCP_NODELAY

#43

Post by Dylan16807 »

gerdesj wrote: post #42
anonymousiam wrote: post #41

Earlier quoted context omitted.

It's P2P as far as the physical layer (L1) is concerned. Usually, full duplex requires two separate channels. The introduction of a hybrid on each end allows the use of the same channel at the same time. Some progress has been made in doing the same thing with radio links, but it's harder. Nagle's algorithm is somewhat intertwined with the backoff timer in the sense that it prevents transmitting a packet until some c…

Sorry? Ethernet has had the concept of full duplex for several decades and I have no idea what you mean by: "hybrid on each end allows the use of the same channel at the same time." The physical electrical connections between a series of ethernet network ports (switch or end point - it doesn't matter) are mediated by CSMA. No idea why you are mentioning radios. That's another medium.

> Ethernet has had the concept of full duplex for several decades and I have no idea what you mean by: "hybrid on each end allows the use of the same channel at the same time."

Gigabit (and faster) is able to do full duplex without needing separate wires in each direction. That's the distinction they're making.

> The physical electrical connections between a series of ethernet network ports (switch or end point - it doesn't matter) are mediated by CSMA.

Not in a modern network, where there's no such thing as a wired collision.

> Take a single switch with n ports on it, where n>2. How do you mediate ethernet traffic without CSMA - its how the actual electrical signals are mediated?

Switches are not hubs. Switches have a separate receiver for each port, and each receiver is attached to one sender.

Re: It's Always TCP_NODELAY

#44

Post by loeg »

x2rj wrote: post #20

I've always thought a problem with Nagel's algorithm is, that the socket API does not (really) have a function to flush the buffers and send everything out instantly, so you can use that after messages that require a timely answer. For stuff where no answer is required, Nagel's algorithm works very well for me, but many TCP channels are mixed use these days. They send messages that expect a fast answer and other that…

TCP_CORK?

Re: It's Always TCP_NODELAY

#45

Post by switchbak »

gerdesj wrote: post #42
anonymousiam wrote: post #41

Earlier quoted context omitted.

It's P2P as far as the physical layer (L1) is concerned. Usually, full duplex requires two separate channels. The introduction of a hybrid on each end allows the use of the same channel at the same time. Some progress has been made in doing the same thing with radio links, but it's harder. Nagle's algorithm is somewhat intertwined with the backoff timer in the sense that it prevents transmitting a packet until some c…

Sorry? Ethernet has had the concept of full duplex for several decades and I have no idea what you mean by: "hybrid on each end allows the use of the same channel at the same time." The physical electrical connections between a series of ethernet network ports (switch or end point - it doesn't matter) are mediated by CSMA. No idea why you are mentioning radios. That's another medium.

My understanding is that no one used hubs anymore, so your collision domain goes from a number of machines on a hub to a dedicated channel between the switch and the machine. There obviously won’t be collisions if you’re the only one talking and you’re able to do full duplex communications without issue.

Re: It's Always TCP_NODELAY

#46

Post by saltcured »

gerdesj wrote: post #40
anonymousiam wrote: post #4

The Nagle algorithm was created back in the day of multi-point networking. Multiple hosts were all tied to the same communications (Ethernet) channel, so they would use CSMA ( https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_... ) to avoid collisions. CSMA is no longer necessary on Ethernet today because all modern connections are point-to-point with only two "hosts" per channel. (Each host can have any nu…

I think you are confusing network layers and their functionality. "CSMA is no longer necessary on Ethernet today because all modern connections are point-to-point with only two "hosts" per channel." Ethernet really isn't ptp. You will have a switch at home (perhaps in your router) with more than two ports on it. At layer 1 or 2 how do you mediate your traffic, without CSMA? Take a single switch with n ports on it, wh…

In modern ethernet, there is also flow-control via the PAUSE frame. This is not for collisions at the media level, but you might think of it as preventing collisions at the buffer level. It allows the receiver to inform the sender to slow down, rather than just dropping frames when its buffers are full.

Re: It's Always TCP_NODELAY

#47

Post by derriz »

x2rj wrote: post #20

I've always thought a problem with Nagel's algorithm is, that the socket API does not (really) have a function to flush the buffers and send everything out instantly, so you can use that after messages that require a timely answer. For stuff where no answer is required, Nagel's algorithm works very well for me, but many TCP channels are mixed use these days. They send messages that expect a fast answer and other that…

Yeah, I’ve always felt that the stream API is a leaky abstraction for providing access to networking. I understand the attraction of making network I/O look like local file access given the philosophy of UNIX.

The API should have been message oriented from the start. This would avoid having the network stack try to compensate for the behavior of the application layer. Then Nagel’s or something like it would just be a library available for applications that might need it.

The stream API is as annoying on the receiving end especially when wrapping (like TLS) is involved. Basically you have to code your layers as if the underlying network is handing you a byte at a time - and the application has to try to figure out where the message boundaries are - adding a great deal of complexity.

Re: It's Always TCP_NODELAY

#48

Post by CamperBob2 »

immibis wrote: post #24
anonymousiam wrote: post #4

The Nagle algorithm was created back in the day of multi-point networking. Multiple hosts were all tied to the same communications (Ethernet) channel, so they would use CSMA ( https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_... ) to avoid collisions. CSMA is no longer necessary on Ethernet today because all modern connections are point-to-point with only two "hosts" per channel. (Each host can have any nu…

Nagle is quite sensible when your application isn't taking any care to create sensibly-sized packets, and isn't so sensitive to latency. It avoids creating stupidly small packets unless your network is fast enough to handle them.

If by "latency" you mean a hundred milliseconds or so, that's one thing, but I've seen Nagle delay packets by several seconds. Which is just goofy, and should never have been enabled by default, given the lack of an explicit flush function.

A smarter implementation would have been to call it TCP_MAX_DELAY_MS, and have it take an integer value with a well-documented (and reasonably low) default.

Re: It's Always TCP_NODELAY

#50

Post by amluto »

x2rj wrote: post #20

I've always thought a problem with Nagel's algorithm is, that the socket API does not (really) have a function to flush the buffers and send everything out instantly, so you can use that after messages that require a timely answer. For stuff where no answer is required, Nagel's algorithm works very well for me, but many TCP channels are mixed use these days. They send messages that expect a fast answer and other that…

The socket API is all kinds of bad. The way streams should work is that, when sending data, you set a bit indicating whether it’s okay to buffer the data locally before sending. So a large send could be done as a series of okay-to-buffer writes and then a flush-immediately write.

TCP_CORK is a rather kludgey alternative.

The same issue exists with file IO. Writing via an in-process buffer (default behavior or stdio and quite a few programming languages) is not interchangeable with unbuffered writes — with a buffer, it’s okay to do many small writes, but you cannot assume that the data will ever actually be written until you flush.

I’m a bit disappointed that Zig’s fancy new IO system pretends that buffered and unbuffered IO are two implementations of the same thing.

Post reply on HN