Nagle's molasses tar pit algorithm, default

[e-dant]

Leaving nodelay on tcp sockets is a common source of accidental latency.

I think all socket libraries should consider disabling it by default or otherwise leave a note about it in the readme.

I think Go's rationale here is fitting.

Enough of the "I think"s -- What do you think? I imagine the rationale for not doing so already is that this is a lowish-level socket library, and I think that makes sense. But that's just my imagination.

[fpagliughi]

I totally agree with Go's rationale... If you're writing networking RPC code, you probably want NO_DELAY as the default.

Interestingly, I have a PR up on the Eclipse Paho MQTT C library to set NO_DELAY on the MQTT socket because I am using it a lot these days to write RPC-driven microservices over MQTT. And I really want to reduce the latency.

But if you're not coding RPCs, and rather doing a lot of small writes to push data upstream, then NO_DELAY can significantly increase the network usage and degrade performance.

So, what are people using this library to do? I have no idea. None. We get so little feedback on how our open-source projects are used! Right?

So... with that in mind, the intent of this library is to have no surprises. This is meant to be as thin a C++ layer around the C socket library as possible. So, on that note, I would prefer to keep the defaults the same as the OS. So no default NO_DELAY.

But...

I do think it should be easier to get and set some of the common socket options without resorting to really low level set_option() calls. I intend to make a bunch of new functions on the base socket() class for things like this:

set_nonblocking()
set_nosigpipe()
set_only_v6()
set_reuse_address()
set_reuse_port()
...

And then it would be nice to add some of these calls to some of the example apps to remind people that they're available.

[e-dant]

We get so little feedback on how our open-source projects are used! Right?

Totally there with you

no surprises

Sounds great

I intend to make a bunch of new functions

I have to hope that they'll all be there. I know plenty of Rust libraries that just kind of skip the bulk of them for reasons I'm not keen to. (I'm aware this isn't Rust, just pointing out that it's incongruous and evidently a "thing" to do.)

---

Issue closable?

[e-dant]

Also, thanks for your work, and happy holidays if you're into them this time of year.

[fpagliughi]

I know plenty of Rust libraries that just kind of skip the bulk of them for reasons I'm not keen to.

Actually I just copy-pasted those function names from the Rust socket2 library! I only discovered it recently and used it to re-implement some of the internals of the Rust socketcan crate - since socket2 has raw sockets and the std library does not. When I saw the setter/getter functions for the options, I just though... yeah.