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

61–70 of 186 posts

Re: It's Always TCP_NODELAY

#61

Post by eieio »

sail0rm00n wrote: post #18
eieio wrote: post #2

I found this article while debugging some networking delays for a game that I'm working on. It turns out that in my case it wasn't TCP_NODELAY - my backend is written in go, and go sets TCP_NODELAY by default! But I still found the article - and in particular Nagle's acknowledgement of the issues! - to be interesting. There's a discussion from two years ago here: https://news.ycombinator.com/item?id=40310896 - but I…

Any details on the game you’ve been working on? I’ve been really enjoying Ebitengine and Golang for game dev so would love to read about what you’ve been up to!

I've been playing with multiplayer games that run over SSH; right now I'm trying to push the framerate on the games as high as I can, which is what got me thinking about my networking stack.

I mostly use go these days for the backend for my multiplayer games, and in this case there's also some good tooling for terminal rendering and SSH stuff in go, so it's a nice choice.

(my games are often pretty weird, I understand that "high framerate multiplayer game over SSH" is a not a uhhh good idea, that's the point!)

Re: It's Always TCP_NODELAY

#63

Post by calineczka »

derriz wrote: post #47
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…

> message oriented

Very well said. I think there is enormous complexity in many layers because we don't have that building block easily available.

Re: It's Always TCP_NODELAY

#64

Post by mikestorrent »

Hikikomori wrote: post #23
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…

Just to add, ethernet uses csma/cd, WiFi uses csma/ca. Upgraded our DC switches to new ones around 2014 and needed to keep a few old ones because the new ones didn't support 10Mbit half duplex.

What did you still need to connect with 10mbit half duplex in 2014? I had gigabit to the desktop for a relatively small company in 2007, by 2014 10mb was pretty dead unless you had something Really Interesting connected....

Re: It's Always TCP_NODELAY

#65

Post by nospice »

neomantra wrote: post #52
0xbadcafebee wrote: post #27

Earlier quoted context omitted.

Only if you're sending data you don't mind losing and getting out of order

This is true for simple UDP, but reliable transports are often built over UDP. As with anything in computing, there are trade-offs between the approaches. One example is QUIC now widespread in browsers. MoldUDP64 is used by various exchanges (that's NASDAQ's name, others do something close). It's a simple UDP protocol with sequence numbers; works great on quality networks with well-tuned receivers (or FPGAs). This is…

Strictly speaking, you can put any protocol on top of UDP, including a copy of TCP...

But I took parent's question as "should I be using UDP sockets instead of TCP sockets". Once you invent your new protocol instead of UDP or on top of it, you can have any features you want.

Re: It's Always TCP_NODELAY

#67

Post by stephen_g »

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…

> 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, where n>2. How do you mediate ethernet traffic without CSMA - its how the actual electrical signals are mediated?

CSMA/CD is specifically for a shared medium (shared collision domain in Ethernet terminology), putting a switch in it makes every port its own collision domain that are (in practice these days) always point-to-point. Especially for gigabit Ethernet, there was some info in the spec allowing for half-duplex operation with hubs but it was basically abandoned.

As others have said, different mechanisms are used to manage trying to send more data than a switch port can handle but not CSMA (because it's not doing any of it using Carrier Sense, and it's technically not Multiple Access on the individual segment, so CSMA isn't the mechanism being used).

> That's full duplex as opposed to half duplex.

No actually they're talking about something more complex, 100Mbps Ethernet had full duplex with separate transmit and receive pairs, but with 1000Base-T (and 10GBase-T etc.) the four pairs all simultaneously transmit and receive 250 Mbps (to add up to 1Gbps in each direction). Not that it's really relevant to the discussion but it is really cool and much more interesting than just being full duplex.

Re: It's Always TCP_NODELAY

#68

Post by silisili »

AnthonyMouse wrote: post #54
silisili wrote: post #32

Earlier quoted context omitted.

At this point, this is an application level problem and not something the kernel should be silently doing for you IMO. An option for legacy systems or known problematic hosts fine, but off by default and probably not a per SOCKOPT. Every modern language has buffers in their stdlib. Anyone writing character at a time to the wire lazily or unintentionally should fix their application.

The programs that need it are mostly the ones nobody is maintaining. TCP_NODELAY can also make fingerprinting easier in various ways which is a reason to make it something you have to ask for.

> 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.

Re: It's Always TCP_NODELAY

#69

Post by stephen_g »

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.

A hybrid is a type of RF transformer - https://en.wikipedia.org/wiki/Hybrid_transformer

Re: It's Always TCP_NODELAY

#70

Post by consp »

mikestorrent wrote: post #64
Hikikomori wrote: post #23

Earlier quoted context omitted.

Just to add, ethernet uses csma/cd, WiFi uses csma/ca. Upgraded our DC switches to new ones around 2014 and needed to keep a few old ones because the new ones didn't support 10Mbit half duplex.

What did you still need to connect with 10mbit half duplex in 2014? I had gigabit to the desktop for a relatively small company in 2007, by 2014 10mb was pretty dead unless you had something Really Interesting connected....

There is always some legacy device which does weird/old connections. I distinctly remember the debit card terminals in the late '00 required a 10mbit capable ethernet connection which allowed x25 to be transmitted over the network. It is not a stretch to add 5 to 10 more years to those kind of devices.
Post reply on HN