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

131–140 of 186 posts

Re: It's Always TCP_NODELAY

#131

Post by mort96 »

mgaunard wrote: post #105
mort96 wrote: post #103

Earlier quoted context omitted.

Well, it also has the advantage of providing pretty decent encryption for free through WSS. But yeah, where that's unnecessary, it's probably just as easy to have a 4-byte length prefix, since TCP handles the checksum and retransmit and everything for you.

It's just a standard TLS layer, works with any TCP protocol, nothing WebSocket-specific in it. You should ideally design your messages to fit within a single Ethernet packet, so 2 bytes is more than enough for the size. Though I have sadly seen an increasing amount of developers send arbitrarily large network messages and not care about proper design.

Meh I've worked enough with OpenSSL's API to know that I never ever want to implement SSL over TCP myself. Better let the WebSocket library take care of it.

Re: It's Always TCP_NODELAY

#132

Post by derriz »

mgaunard wrote: post #127
derriz wrote: post #115

Earlier quoted context omitted.

For me, the “whole point” of TCP is to add various delivery guarantees on top of IP. It does not mandate or require a particular API. Of course, you can provide a stream API over TCP which suits many applications but it does not suit all and by forcing this abstraction over TCP you end up making message oriented applications (e.g request /response type protocols) more complex to implement than if you had simply expos…

TCP is not message-oriented. Retransmitted bytes can be at arbitrary offsets and do not need to align with the way the original transmission was fragmented or even an earlier retransmission.

I don’t understand your point here or maybe our understanding of the admittedly vague term “message oriented” differs.

I’m not suggesting exposing retransmission, fragmentation, etc to the API user.

The sender provides n bytes of data (a message) to the network stack. The receiver API provides the user with the block of n bytes (the message) as part of an atomic operation. Optionally the sender can be provided with notification when the n-bytes have been delivered to the receiver.

Re: It's Always TCP_NODELAY

#133

Post by readmodifywrite »

Gibbon1 wrote: post #72
CamperBob2 wrote: post #48

Earlier quoted context omitted.

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.

Reminds me of trying to do IoT stuff in hospitals before IoT was a thing. Send exactly one 205 byte packet. How do you really know? I can see it go out on a scope. And the other end receives a packet with bytes 0-56. Then another packet with bytes 142-204. Finally a packet a 200ms later with bytes 57-141. FfffFFFFffff You!

If you were using TCP, then this is absolutely normal and expected behavior. It is a stream protocol, not packet/message based.

Re: It's Always TCP_NODELAY

#134

Post by throwway120385 »

fulafel wrote: post #58
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…

Are you theorizing a CSMA related motivation or benefit in the Nagle algorithm or is this a tangential anecdote of those times?

CSMA further limits the throughput of the network in cases where you're sending lots of small transmissions by making sure that you're always contending for the carrier.

Re: It's Always TCP_NODELAY

#135

Post by BenjiWiebe »

mort96 wrote: post #87
silisili wrote: post #68

Earlier quoted context omitted.

> The programs that need it are mostly the ones nobody is maintaining Yes, as I mentioned, it should be kept around for this but off by default. Make it a sysctl param, done. > TCP_NODELAY can also make fingerprinting easier in various ways which is a reason to make it something you have to ask for Only because it's on by default for no real reason. I'm saying the default should be off.

>> TCP_NODELAY can also make fingerprinting easier in various ways which is a reason to make it something you have to ask for > Only because it's on by default for no real reason. I'm saying the default should be off. This is wrong. I'm assuming here that you mean that Nagle's algorithm is on by default, i.e TCP_NODELAY is off by default. It seems you think the only extra fingerprinting info TCP_NODELAY gives you is…

As of recently, OpenSSH prevents keystroke timing analysis on it's own.

Re: It's Always TCP_NODELAY

#136

Post by fulafel »

throwway120385 wrote: post #134
fulafel wrote: post #58

Earlier quoted context omitted.

Are you theorizing a CSMA related motivation or benefit in the Nagle algorithm or is this a tangential anecdote of those times?

CSMA further limits the throughput of the network in cases where you're sending lots of small transmissions by making sure that you're always contending for the carrier.

So I guess the answer is that CSMA networks get congested more easily and Nagle saves some traffic. (Applies to modern world as well in wifi)

Re: It's Always TCP_NODELAY

#137

Post by silisili »

mort96 wrote: post #87
silisili wrote: post #68

Earlier quoted context omitted.

> The programs that need it are mostly the ones nobody is maintaining Yes, as I mentioned, it should be kept around for this but off by default. Make it a sysctl param, done. > TCP_NODELAY can also make fingerprinting easier in various ways which is a reason to make it something you have to ask for Only because it's on by default for no real reason. I'm saying the default should be off.

>> TCP_NODELAY can also make fingerprinting easier in various ways which is a reason to make it something you have to ask for > Only because it's on by default for no real reason. I'm saying the default should be off. This is wrong. I'm assuming here that you mean that Nagle's algorithm is on by default, i.e TCP_NODELAY is off by default. It seems you think the only extra fingerprinting info TCP_NODELAY gives you is…

> I'm assuming here that you mean that Nagle's algorithm is on by default, i.e TCP_NODELAY is off by default.

Correct, I wrote that backwards, good callout.

RE: fingerprinting, I'd concede the point in a sufficiently lazy implementation. I'd fully expect the application layer to handle this, especially in cases where this matters.

Re: It's Always TCP_NODELAY

#138

Post by jandrese »

paulsutter wrote: post #53
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…

False. It really was just intended to coalesce packets. I’ll be nice and not attack the feature. But making that the default is one of the biggest mistakes in the history of networking (second only to TCP’s boneheaded congestion control that was designed imagining 56kbit links)

TCP uses the worst congestion control algorithm for general networks except for all of the others that have been tried. The biggest change I can think of is adjusting the window based on RTT instead of packet loss to avoid bufferbloat (Vegas).

Unless you have some kind of special circumstance you can leverage it's hard to beat TCP. You would not be the first to try.

Re: It's Always TCP_NODELAY

#139

Post by josefx »

readmodifywrite wrote: post #133
Gibbon1 wrote: post #72

Earlier quoted context omitted.

Reminds me of trying to do IoT stuff in hospitals before IoT was a thing. Send exactly one 205 byte packet. How do you really know? I can see it go out on a scope. And the other end receives a packet with bytes 0-56. Then another packet with bytes 142-204. Finally a packet a 200ms later with bytes 57-141. FfffFFFFffff You!

If you were using TCP, then this is absolutely normal and expected behavior. It is a stream protocol, not packet/message based.

At the application layer you would not see the reordered bytes. However on the network you have IP beneath both UDP and TCP and network hardware is normally free to slice and reorder those IP packages however it wants.

Re: It's Always TCP_NODELAY

#140

Post by jasomill »

derriz wrote: post #132
mgaunard wrote: post #127

Earlier quoted context omitted.

TCP is not message-oriented. Retransmitted bytes can be at arbitrary offsets and do not need to align with the way the original transmission was fragmented or even an earlier retransmission.

I don’t understand your point here or maybe our understanding of the admittedly vague term “message oriented” differs. I’m not suggesting exposing retransmission, fragmentation, etc to the API user. The sender provides n bytes of data (a message) to the network stack. The receiver API provides the user with the block of n bytes (the message) as part of an atomic operation. Optionally the sender can be provided with n…

Is this a TCP API proposal or a protocol proposal?

Because TCP, by design, is a stream-oriented protocol, and the only out-of-band signal I'm aware of that's intended to be exposed to applications is the urgent flag/pointer, but a quick Google search suggests that many firewalls clear these by default, so compatibility would almost certainly be an issue if your API tried to use the urgent pointer as a message separator.

I suppose you could implement a sort of "raw TCP" API to allow application control of segment boundaries, and force retransmission to respect them, but this would implicitly expose applications to fragmentation issues that would require additional API complexity to address.

Post reply on HN