Hacker News new | ask | show | jobs
by bullen 1595 days ago
I made the backend for this MMO on SSE over HTTP/1.1:

https://store.steampowered.com/app/486310/Meadow/

We have had a total of 350.000 players over 6 years and the backend out-scales all other multiplayer servers that exist and it's open source:

https://github.com/tinspin/fuse

You don't need HTTP/2 to make SSE work well. Actually the HTTP/2 TCP head-of-line issue and all the workarounds for that probably make it harder to scale without technical debt.

9 comments

>backend out-scales all other multiplayer servers

Can you explain what you mean here? What was your peak active user count, what was peak per server instance, and why you think that beats anything else?

Agreed, I'm curious as well. We load tested with real-clients faux-users, up to 1 million concurrent. And only stopped at 1 million because the test was becoming cost prohibitive.
The data is here: http://fuse.rupy.se/about.html

Under Performance. Per watt the fuse/rupy platform completely crushes all competition for real-time action MMOs because of 2 reasons:

- Event driven protocol design, averages at about 4 messages/player/second (means you cannot do spraying or headshots f.ex. which is another feature in my game design opinion).

- Java's memory model with atomic concurrency parallelism over shared memory which needs a VM and GC to work (C++ copied that memory model in C++11, but it failed completely because they lack both VM and GC, but that model is still to this day the one C++ uses), you can read more about this here: https://github.com/tinspin/rupy/wiki

These keep the internal latency of the server below maybe 100 microseconds at saturation, which no C++ server can handle even remotely, unless they copy Java's memory model and add a VM + GC so that all cores can work on the same memory at the same time without locking!

You can argue those points are bad arguments, but if you look at performance per watt with some consideration for developer friendlyness, I'm pretty sure in 100 years we will still be coding minimalist JavaSE (or some copy without Oracle) on the server and vanilla C (compiled with C++ compiler gcc/cl.exe) on the client to avoid cache misses.

Energy is everything!

> - Java's memory model with atomic concurrency parallelism over shared memory which needs a VM and GC to work

Do you have a link that explains this bit?

Not other than the one linked in the comment above. I have been reaching out to EVERYONE, and nobody can explain this to me, but I'll implement it myself soon so I can explain it.
The links upthread don't actually explain why a VM + GC can do shared-memory concurrency faster[1].

I don't understand what particular piece of magic makes shared-memory concurrency under a VM+GC faster than a CAS implementation.

[1] I'm assuming a shared-memory threaded model of concurrency, not a shared-nothing message passing model of concurrency.

This is fantastic information.
Your license makes some sense, but it seems to include a variable perpetual subscription cost via gumroad. Without an account (assuming I found the right site), I have no idea what you would be asking for. I recommend making it a little clearer on the landing page.

That's said, it's very cool. Do you have a development blog for Meadow?

Added link in the readme! Thx.

No, no dev log but I'll tell you some things that where incredible during that project:

- I started the fuse project 4 months before I set foot in the Meadow project office (we had like 3 meetings during those 4 months just to touch base on the vision)! This is a VERY good way of making things smooth, you need to give tech/backend/foundation people a head start of atleast 6 months in ANY project.

- We spent ONLY 6 weeks (!!!) implementing the entire games multiplayer features because I was 100% ready for the job after 4 months. Not a single hickup...

- Then for 7 months they finished the game client without me and released without ANY problems (I came back to the office that week and that's when I solved the anti-virus/proxy cacheing/buffering problem!).

I think Meadow is the only MMO in history so far to have ZERO breaking bugs on release (we just had one UTF-8 client bug that we patched after 15 minutes and nobody noticed except the poor person that put a strange character in their name).

> MIT but [bunch of stuff]

Not MIT then. The beauty of MIT is that there is no stuff.

We already discussed this in an earlier thread, and however bad this looks it's better than my own license.

Here it's clear, you can either use the code without money involved and then you have MIT (+ show logo and some example code is still mine).

If you want money then you have to share some of it.

While I get and support the intent, I don't like this usage of the name of the MIT license. I personally like the license because it tells me at a glance that I can use it for any purpose, commercial or otherwise, as long as the copyright and license is included and that there is no warranty. That's it, no complications, no other demands, no "if it makes X money or not", just I include the copyright and license terms and that's it, I can use the software whichever way I like.

Your license is not that. You have extra conditions that add complexity. I can no longer go "oh like MIT" and immediately use it for any purpose, because you require extras especially if I were to make money. That seems completely against the spirit of the simplicity of the MIT license which says you can do whatever you like, commercial or otherwise, as long as the copyright and license are included.

I think you should make your own license that includes the text of the MIT license, except removing the irrelevant parts (ie the commercial aspects include a caveat about requiring payment). You can still have a separate line of text explaining that the license is like the MIT license but with XYZ changes (basically the text you have now). But the license is not the MIT license and you should therefore have a separate license text that spells it out exactly. Not "its this, except scratch half of it because these additional terms override a good chunk of it".

Ok, I agree but then I also have less time to work on real things and honestly I feel the whole legal/money part of our civilization is a huge waste of time in the face of energy problems that can't go away (2nd law of thermodynamics and sunlight + photosyntesis) and that my platform tries to help with elegantly by being the most efficient solution for MMO networking.

I'm also sad that nobody has solved this license problem yet, there is obviously a need for it. Sometimes time solves all problems though, so I probably just have to wait a while and somebody makes exactly the right license.

But I'm going to allocate some time if somebody who is willing to pay approaches me with the same concerns (it's actually why I switched to MIT in the first place, Unreal does not allow you to use client plugins that are LGPL)...

Small steps, we'll get there!

> then I also have less time to work on real things

What? To keep your existing license you copy the text of the MIT license, add the statement about requiring a logo and remove the parts about being able to use the code commercially, and add an extra paragraph that has the text you already have: to use commercially you have to sponsor. It’s not about changing your terms, it’s about being clear about what license applies. Hybrid with MIT and other implies that the MIT license somehow applies yet it does not since your “other” invalidates a chunk of what the MIT license allows. Just removing those bits and not calling it MIT is enough.

If that significantly cuts into your time to do other stuff then I don’t know what to say.

> if somebody who is willing to pay approaches me with the same concerns

I’m not concerned about the license per se. It wouldn’t stop me from paying if I wanted to use your software. It’s just that to everyone looking, before even evaluating it, you’re sending a dishonest message, that somehow the MIT license applies when it clearly does not.

I would create a license.txt file that contains a copy of the MIT license text with the commercial use phrasing removed, the need for displaying logo added a second paragraph before the warranty disclaimer stating that you may use the software commercially so long as you sponsor (same text you already have). Then I would link it from the readme with an explanation: proprietary license that is similar to the MIT license except with the conditions of logo and for commercial use requiring sponsorship (existing text more or less). Clear, simple and should take you no more than ten minutes to fix.

My objection is that you are claiming it’s under MIT license and using the MIT licenses name recognition, while applying changes that very clearly make it not MIT license at all.

I respect your right to license you product however you want, but please don't call that open source.
Requiring attribution doesn’t make something not open source. At best this means that the example code isn’t open source.
Requiring attribution is not the problem, but restricting commercial use makes this not an open source license.
Open-source also means the source is open, what you are looking for is free and honestly nothing is free... if you have a better term I'm open for suggestions.

But really open-source (as in free) is the misnomer here, it should be called free open-source, or FOSS as some correctly name it.

That battle has been fought already, and the accepted term is "source available", not "open source". (And gnu adds Free or "libre" software, which is software licence in a way that tries to ensure the "four freedoms" for all downstream users of software - such as freedom zero - the right to run software (no need for eg: cryptographic signature/trusted software - without a way for the user to define trust).
I've seen these referred to as "Source-available licenses". This would cover things like Mongo's SSPL.

The bare reality is that it's just a commercial license.

> FOSS

FOSS or F/OSS is a combination of Free (as defined by the FSF) and Open Source (as defined by the OSI) (the last S is Software), which recognizes that the two terms, while they come from groups with different ideological motivations, refer to approximately the same substantive licensing features and almost without exception the same set of licenses.

Can you explain how H2 would make it harder to scale SSE?
The mistake they did was to assume only one TCP socket should be used; the TCP has it's own head-of-line limitations just like HTTP/1.1 has if you limit the number of sockets (HTTP/1.1 had 2 sockets allowed per client, but Chrome doesn't care...) it's easily solvable by using more sockets but then you get into concurrency problems between the sockets.

That said if you, like SSE on HTTP/1.1; use 2 sockets per client (breaking the RFC, one for upstream and one for downstream) you are golden but then why use HTTP/2 in the first place?

HTTP/2 creates more problems than solutions and so does HTTP/3 unfortunately until their protocol fossilizes which is the real feature of a protocol, to become stable so everyone can rely on things working.

In that sense HTTP/1.1 is THE protocol of human civilization until the end of times; together with SMTP (the oldest protocol of the bunch) and DNS (which is centralized and should be replaced btw).

The issues with TCP head-of-line blocking are resolved in HTTP/3 (QUIC).
Sure but then HTTP/3 is still binary and it's in flux meaning most routers don't play nice with it yet and since HTTP/1.1 works great for 99.9% of the usecases I would say it's a complete waste of time, unless you have some new agenda to push.

Really people should try and build great things on the protocols we have instead of always trying to re-discover the wheel, note: NOT the same as re-inventing the wheel: http://move.rupy.se/file/wheel.jpg

TCP is not perfect. There is ambiguity between the acknowledgement of a segment and the retransmission of a segment that we have tried to address with extensions and heuristics. It can introduce latency for upper protocols which are comprised of fixed-length messages. SACK reneging is a crime against humanity.

It's amazing that we've been able to adapt the protocol in a backwards-compatible fashion for over 30 years, but QUIC addresses problems with TCP in ways that could not be done in a backwards-compatible fashion. Personally I wish the protocol were simpler, but I lack the expertise to say what should be removed.

For FANG scale, a 1% performance improvement for certain services has measurable business results.

Take Snap. Say they reduced time to view a snap by 10ms. After 100 snaps that’s an additional 1 second of engagement. This could equate to an additional ad impression every week per user. Which is many millions of additional revenue.

HTTP/3 is E2E encrypted and built on UDP. What does “most routers don’t play nice with it yet” mean in that context? Do you mean middleware boxes/routers rather than end user routers?
For me the question is not so much "yet" as "maybe never", since some networks block UDP altogether, and HTTP/3 has a robust fallback mechanism.
It means they don't actually understand networking, but think they do.
> HTTP/3 is E2E encrypted

Please elaborate.

While I agree, we shouldn't discount one less RTT for encrypted connections. Latency is a problem that never really goes away, and we can only try to reduce RTTs.
If people had tried to build great things on the protocols we have instead of re-discovering the wheel, we'd still have gopher, FTP and telnet for most things. Technology evolves and that's a good thing.
Routers are operating on the IP layer of the network stack, they don't have anything to do with application level protocols.
> and DNS (which is centralized and should be replaced btw

So much nonsense in a single paragraph, amazing.

If anything DNS is less centralized then http and SMTP. Its a surprisingly complicated system for what it does because of all the caching etc, but calling it more centralized then http is just is just ignorant to a silly degree

Sorry, what do you mean by "one for upstream and one for downstream"? You can't send messages back to the server with SSE.
Couldn't find a license file in the root folder of that github. I found a license in a cpp file buried in the sec folder. You should consider putting the licensing for this kind of project in a straightforward and locatable place.
That license in the cpp file is for the SHA256 code.

My license is messy but if you search for "license" on the main github page you'll eventually find MIT + some ugly modifications I made.

I now added a license.txt
Not just great for games but for large scale webrtc signaling for p2p.
Love your hybrid model via gumroad! I do something similar for my own open-source project

https://github.com/open-wa/wa-automate-nodejs

There should be some sort of support group for those of us trying to monetize (sans donations) our open source projects!

I just found out gumroad pays VAT on recurring payments a couple of weeks ago.

We probably need a new license though because piggybacking on MIT (or any other license) like I try to do is rubbing people the wrong way.

But law and money are my least favourite passtimes, so I'm going to let somebody else do it first unless somebody is willing to force this change by buying a license and asking for a better license text.

> open source projects

Your source-available projects. Nothing wrong with licensing your work that way (in the sense that you can make that choice, not in the sense that I think its a good idea) but please don't muddle the term "open source".

Well technically rupy is open-source (ALGPL, yet another license that still doesn't exist) and since fuse (source-available) is built on top, you can maybe call it open-source, specially since rupy is like 90% of the code.
Thanks for your input I will still continue to use whatever phrasing I see fit :)
Its a lot easier to scale than websockets where you need a pub sub solution and a controller to published shared state changes. See is really simply incomparision
Probably not the same person, but did you ever play on RoD by any chance?
Probably not, since I dont know what RoD is.
I thought so, thanks!
Nice work, thanks for sharing.