Live data from Hacker News

We improved the performance of a userspace TCP stack in Go

coder.com

111–120 of 133 posts

Re: We improved the performance of a userspace TCP stack in Go

#111
post #88
post #84

Earlier quoted context omitted.

I think it is a valid question on why not use unprivileged ports, though? Or am I also missing something?

"Unprivileged ports" is just a case in point for everything you would need privileges to do, from binding arbitrary ports to adding arbitrary addresses and running local servers on them, etc, etc, etc. The point is: turning "complicated" network features that require privilege into simple unprivileged socket code.

Right, per my other thread below, my understanding was the "privileged" ports were mainly ones that were allowed for off machine communication by standard policy/convention long time ago. As such, using higher number ports should be just as easy in the code as using lower ports, outside of the discovery that was implied by following the other conventions. But, introducing new network addresses seems to have already side stepped the discovery affordances?

I'll offer the same caveat here, btw, I am not trying to torpedo the idea of trying this. I'm genuinely curious why you would need to do this. Not necessarily why you would want to.

Re: We improved the performance of a userspace TCP stack in Go

#112

Earlier quoted context omitted.

It seems like a great product. I'm wondering why they don't offer more "startup-oriented" plans. It's like either Self Hosted or "Talk to sales". Is it maybe to not compete against Github codespaces?

Founder of Coder here. Many small (or teams at big) companies use Coder for free with We’ve tried to align our pricing with the value of the product. In small teams the productivity gains seem to be much lower, so we target Enterprise!

Speaking of ... https://coder.com/docs -- what's next is empty.

Re: We improved the performance of a userspace TCP stack in Go

#113

Earlier quoted context omitted.

The quote - is this yet another issue caused by abysmal FFI overhead in Go?

https://www.reddit.com/r/golang/comments/12nt2le/when_dealin... If your C doesn't fight the scheduler it isn't that bad.

Great find! Specifically:

On a goroutine not locked to an OS thread (the default), don't take more than 1 microsecond in a single C call. If you need to take longer in C, lock the goroutine to an OS thread (runtime.LockOSThread), but then don't do things in Go that would park that goroutine (time.Sleep, blocking channel read/write, etc).

Re: We improved the performance of a userspace TCP stack in Go

#114
post #58

Earlier quoted context omitted.

> The gVisor/perf thing is a tendentious argument Interesting to dismiss it as such. The gvisor netstack is a (big) part of gvisor and this article is discussing how the performance of that component was, and could well still be, garbage. These tools bring marginal capability and performance gains, shoved down peoples throat by manufacturing security paranoia. Oh an it all happens to cost you like 10x time, but look…

> The gvisor netstack ... this article is discussing how the performance of that component was ... garbage. The article and a related GitHub discussion (linked from TFA) points out that the default congestion algorithm (reno) wasn't good for long-distance (over Internet) workloads. The gvisor team never noticed it because they test/tune for in-datacenter usecases. > These tools bring marginal capability and performan…

Linux kernel LPEs do not routinely sell for millions. There's a market value on a specific subset of vulnerabilities that root flagship Google phones.

Re: We improved the performance of a userspace TCP stack in Go

#116
post #111
post #88

Earlier quoted context omitted.

"Unprivileged ports" is just a case in point for everything you would need privileges to do, from binding arbitrary ports to adding arbitrary addresses and running local servers on them, etc, etc, etc. The point is: turning "complicated" network features that require privilege into simple unprivileged socket code.

Right, per my other thread below, my understanding was the "privileged" ports were mainly ones that were allowed for off machine communication by standard policy/convention long time ago. As such, using higher number ports should be just as easy in the code as using lower ports, outside of the discovery that was implied by following the other conventions. But, introducing new network addresses seems to have already s…

We did it because we run WireGuard gateways to the public cloud we operate, and our CLI wants to talk to things on customer networks (like remote Docker server instances to build new versions of apps). Our options were:

* Do user-mode WireGuard (and thus TCP/IP) and talk "natively" to the infrastructure deployed on our platform.

* Write case-by-case application gateways for each of those pieces of infrastructure tunneled somehow through HTTP.

Re: We improved the performance of a userspace TCP stack in Go

#117
post #110
post #108

Earlier quoted context omitted.

Both reasons have nothing to do with technical capability and everything with organisational policies.

Right... but that just seems to imply that this is getting around policies by the letter? I should hasten to add that I am not offering this as reason this shouldn't be done.

I know this is subtle but if you take a step back, user-mode TCP/IP moots the policies we're talking about; it doesn't subvert them. There are no security or policy implications to e.g. binding a low-numbered port on an IP address unrelated to your physical computer that is allocated directly to a running instance of your program. There are (archaic) implications to binding that port on an actual interface of your machine, because that binding (archaically) stood in for an assertion of identity/authority back in the 1990s.

Re: We improved the performance of a userspace TCP stack in Go

#118
post #110

Earlier quoted context omitted.

Right... but that just seems to imply that this is getting around policies by the letter? I should hasten to add that I am not offering this as reason this shouldn't be done.

I know this is subtle but if you take a step back, user-mode TCP/IP moots the policies we're talking about; it doesn't subvert them. There are no security or policy implications to e.g. binding a low-numbered port on an IP address unrelated to your physical computer that is allocated directly to a running instance of your program. There are (archaic) implications to binding that port on an actual interface of your ma…

Sorta? If it renders them moot, why not attack the policies? For that matter, if there are no implications to the number of the port, I'm again forced to ask why not just use the higher numbers? Wouldn't that have let you use the "simplicity of standard socket code" with no extra effort?

(This is also a new use of "moot" to me? You seem to be offering it as a synonym of obsolete? But a "moot" debate is one that is closer to "overcome by events" than one that is not relevant. Right?)

Re: We improved the performance of a userspace TCP stack in Go

#119
post #118

Earlier quoted context omitted.

I know this is subtle but if you take a step back, user-mode TCP/IP moots the policies we're talking about; it doesn't subvert them. There are no security or policy implications to e.g. binding a low-numbered port on an IP address unrelated to your physical computer that is allocated directly to a running instance of your program. There are (archaic) implications to binding that port on an actual interface of your ma…

Sorta? If it renders them moot, why not attack the policies? For that matter, if there are no implications to the number of the port, I'm again forced to ask why not just use the higher numbers? Wouldn't that have let you use the "simplicity of standard socket code" with no extra effort? (This is also a new use of "moot" to me? You seem to be offering it as a synonym of obsolete? But a "moot" debate is one that is cl…

You get that these are just people shipping a program that random people are going to run on random computers, right? If your go-to-market involves "reversing longstanding Unix network policy rules", you have problems.

Respectfully, if at this point the situation hasn't been made clear to you, I don't think there's much more to productively discuss.

Re: We improved the performance of a userspace TCP stack in Go

#120
help me understand something.

> we’d need a way for the TCP packets to get from the operating system back into Coder for encryption.

yes, this is commonly done via OpenSSL for example.

> This is called a TUN device in unix-style operating systems and creating one requires elevated permissions

waitasec, wut? sure you could use a TUN device I guess, but assuming some kind of multi-tenant separation is an underlying assumption they didn't mention in their intro, couldn't you also use cgroup'd containers? sorry if I'm not fluent in the terminology.

i'm struggling to understand the constraints that push them towards gVisor. simply needing to do encryption doesn't seem like justification. i'm sure they have very good reasons, but needing to satisfy a financial regulator seems orthogonal at best. i would just like to understand those reasons.

Post reply on HN