uWebSockets

Can you just store the shard id for each user in a database? Each server could check if it is authorative for each incoming connection, and redirect if not.

That way, you can migrate users one by one (sending a 'redirectUserConnections(userId)' to the original server, and even pick a shard that is geographically close to the user. (If you care about race conditions during migrations, you need to be really careful though.)

Linux has TCP connection repair, which can be used to transparently migrate an active TCP session between two Linux boxes. The TCP traffic will be paused for the duration of the migration, but the other endpoint will not notice as long as the migration is complete before TCP timeouts kick in.

https://lwn.net/Articles/495304/

migrating an open socket to me sounds like it'd be more hassle than it's worth. It's possible to do, but unusual.

Can't you not involve the client and send it an explicit "reconnect to server XYZ" message, only move clients that really need to move?

By curiosity, can I ask you which sharded message broker you are using? (The one "above in the stack")

We're solving exactly this problem with Hathora. Checkout a blog post that we recently wrote: https://blog.hathora.dev/scalable-websocket-architecture/

You're welcome to checkout the docs and get started: https://docs.hathora.dev/#/buildkit/README

If you'd like to get in touch, feel free to shoot me a message: sid [at] hathora.dev

I am one of the co-founders of https://ably.com. We have built a Serverless websockets platform that is near infinitely scalable and designed to handle the complexity you’re describing such as cluster resizing, connection failures, automatic sharding and reallocations using hash rings across our global edge service etc. I’d be really interested to hear why you wouldn’t consider offloading this to a service like ours which powers the likes of HubSpot, Expedia, Spotify etc. Feel free to contact me directly @mattheworiordan if you’d prefer not to comment here. I’m really keen to hear different perspectives on what we’re doing right and where we can improve!

The simplest might be an endpoint which asks 'which server should I connect to?'

Then you can use whatever logic you want for it. If the client disconnects, it just asks again and reconnects.

Use a token from the directory endpoint to authorize the connection so they have to do it.

Any sufficiently advanced programming language is indistinguishable from JavaScript... for the better and for the worse.

I'll upvote you. That's a fine reason not to use a library.

This is a valid choice. I doubt that the developer will lose any sleep over it.

is this an inside joke that I'm too cool to understand?

Thanks

Here here, my dear fellow! Doubly so, for that awful logo.

The first link on the page explains exactly what it is, and what the motivations are.

https://github.com/uNetworking/uWebSockets/blob/master/misc/...

It's an extremely fast library for creating websocket servers. It's used by some crypto exchanges for it's high performance and low latency.

Header-only libraries are a common thing in C++. They allow pretty easy consumption, because the consumer only needs to specify the include path. That's fairly easy with any build system (and C++ has a lot of them).

Any binary library would also require building the library itself using the same toolchain and then linking to it - which requires a lot more configuration on the consuming side. It might be easy if both projects use the same build system (e.g. cmake), but that's far from guaranteed in C++.

I think things have changed, but back when I was doing C++, templates (generics) were implemented in header files, so it was not unusual to have entire programs written in .h files.

I don't think you have less dep when building other c++ projects. People also use automake, autoconf or whatever to generate makefiles. It is just that the author choose python here. I never see anybody writes makefile manually and build moderate or big size project. There are always tons of tools used.

That's why the library ships prebuilt binaries with no dependencies at all. No compiler is even needed.

It's pretty common to use a u instead of mu in situations that need just plain ascii. I don't think anyone's confused. uTorrent comes to mind, too.

I used to vehemently agree with stuff like this, but now I just cringe. Yeah software today sucks, but comparing it with the 70s/80s/90s is just stupid. We don't ship software for one piece of incredibly simple hardware and a few thousand customers anymore. Elitism isn't going to make the situation any better and frankly unproductive whining like this is just getting exhausting.

I mean you can be critical about performance and lack of optimization without punching down. People like this have never worked on applications in a normal corporation, I'm sure.

As if whoever wrote this would survive on a farm

Clearly someone didn’t use software from even the 90s.. a lot of it was pure crashing garbage.

> but author has an ego the size of Wolfram's

Stephen Wolfram is going to be so pleased that he finally has his own unit named after him!

Mathematics, physics, computing, and now psychometrics, is there anything that man can’t make groundbreaking progress on?

To be fair to the author, that quote is part of a longer passage about how one should not optimize for free form ascii first when fixed size buffers are an option. At least that how I read it, it's clearly opinionated writing.

Yeah I have a look, really difficult to work with i'll pass.

> In the 1970s, programming was an elite's task. Today programming is done by uneducated "farmers" and as a result, the care for smart algorithms, memory usage, CPU-time usage and the like has dwindled in comparison.

What's wrong with that statement? In 1970's, the number of people who dealt with programming was significantly smaller than today. It's a matter of fact. And people who worked with computers back then were highly educated and pioneers of the technology, there was no room for half-hearted effort or "let's copy the first result from stackoverflow.com".

Today, programmers who are meticulous, detail-oriented and who genuinely recognize the problem first are in minority and that's how I read the above.

The author might have stated it abruptly, but it does not mean he's wrong. You're using the "cool little library", yet you have this kind of resentment for the person who made it, have you even tried to look at the situation from their perspective before you passed the judgement?

I'm asking out of curiosity, because I can relate to having to work with under-skilled individuals who spend more time sorting out their CV and online presence than their work.

Did his sentence hit close home with you? He's mostly right.

As an uneducated farmer this gave me a giggle, it suggests if I filed a ticket about a performance problem in the project it'd likely be fixed instantaneously. That quote is basically an advert, if the author wishes to establish such a high bar for themselves it'd be foolish not to avail of it.

How to not agree?

"uneducated farmer" are those who can survive on a piece of land dependency-free. They know weather, season, plant, animal, chemistry, machinery and many more. Us engineers without 30mins of internet are less useful than a sprouting potato. I'm not sure what the author meant.

It is a really poor take, not least because "memory usage, CPU-time..." was more important when computers had less resource.

We can instead spend our time doing really cool things with massive amounts of data, beyond the wildest dreams of the early coders.

The uWebSocket's authors take is SO bad in SO many other ways too. They should be prescribed a dose of real world.

Lol, easy to nitpick but if you'll read the whole document this guy really knows his stuff. It's not a coincidence that uWebSockets is continuously being used by most trading platforms.

"It's not bragging if you can back it up." - Muhammad Ali

> We have had standardized, time-zone neutral representation of time in binary, efficient, 4-byte representation since the 1970s. [...] This is just an example of how we have regressed in our algorithmic thinking.

Now I'm wondering if uWebSockets will fail spectacularly in 2038.

What a low hanging fruit. Is this haternews or hackernews?

I find it interesting that everybody in this thread seems to take exception to the comparison to "farmers". I mean, farming is brutal hard work but it also does not require a high degree of thinking, so I can see his point even if he has made it in an offensive way. Personally, I'm much happier sitting in a warm comfortable place thinking hard about code instead of being out in a cold field 20 hours a day, but meh.

Much more offensive (to me) is this gem from later on:

> Designing clever, binary and minimally repetitive protocols saves enormous amounts of CPU-time otherwise lost to compression.

Well yes, but also, and more importantly no. This is technically true - not compressing the data is more efficient in terms of computation per bit on the wire. But it is also wrong in a much more subtle way.

The advantage of using JSON (or an equivalent) and then compressing it down is that we inject a large amount of redundancy into the format. The CPU is taking that redundancy back out for us to save bandwidth, but we get to exploit it in much more valuable ways. The encoder/decoder are generic, simple and highly optimized. We can use them everywhere and trust them to work. This has value in itself, and it means that we can spend our limited budget of programmer time in optimizing other code where the payoff is higher. It means less time tracking down bugs in "super 10x programmer's one-off encoder that was only written for this specific application". And lastly, but my favourite - it means that when something goes wrong we have a hope of repairing the damage to the data. Because redundancy gives us options for error checking and recovery, while optimizing the binary format generally does not.

Also, if you want the format to really be optimal it should not be designed as byte streams (as low-level binary formats generally are) and instead should be a stream of variable-sized tokens that are fed through an arithmetic encoder.

The first half of this week I spent repairing data corruption caused by some of my code. Luckily there is a lot of redundancy in how I encoded the data (in a structure that is described in JSON inside the records) so I could write a tool that repaired the damage. I guess I'm lucky that I'm just a "farmer" :)

is he wrong?

Yikes! Imagine believing this and yet still having 20 open issues. Sounds like a bit of delusion.

You find what you look for. If you look for humble posts they are there to be found. But you don't want to, so you won't find them.

Me 2