Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Server-Sent Events: an alternative to WebSockets

germano.dev

Post reply on HN
Print view View original

241–250 of 266 posts

Re: Server-Sent Events: an alternative to WebSockets

#241

Post by bullen »

dkersten wrote: post #226
bullen wrote: post #195

Earlier quoted context omitted.

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…

> 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 app…

I didn't know how small the MIT license was!!!

"Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:"

Became

"Permission is hereby granted, to any person obtaining a copy of this software and associated documentation files (the "Software"), to use the Software, including the rights to copy, modify, merge, publish and/or distribute the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:"

And then I list the stuff...

1) You have to show the logo on startup.

2) You have to sponsor the fuse tier on gumroad while you are using the Software, or any derived Software, commercially:

https://tinspin.gumroad.com/l/xwluh

3) The .html and graphics are proprietary examples except the javascript in play.html

4) The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

it feels completely meaningless to put it that way... laws are really the most superficial waste of time, it only took 5 minutes to edit but it's a lifetime of trouble!

But thanks I guess, if it works... but you only know that later... possibly eons later!

Re: Server-Sent Events: an alternative to WebSockets

#242

Post by bullen »

lelanthran wrote: post #239
bullen wrote: post #235

Earlier quoted context omitted.

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.

CAS?

Me neither, but I know it does in practice.

My intuition tells me the VM provides a layer decoupled from the hardware memory model so that there is less "friction" and the GC is required to reclaim shared memory that C++ would need to "stop the world" to reclaim anyhow! (all concurrent C++ objects leaks memory, see TBB concurrent_hash_map f.ex.) That means the code executes slower BUT the atomics can work better.

As I said; for 5 years I have been searching for answers from EVERYONE on the planet and nobody can answer. My guess is that this is so complicated, only a handfull can even begin to grook it, so nobody wants to explain it because it creates alot of wasted time.

The usual reaction is: Java is written in C, so how can Java be faster than C? Well I don't know how but I know it's true because I use it!

So my answer today is: Java is faster than C if you want to share memory between threads directly efficiently because you need a VM with GC to make the Java memory model (which everyone has copied so I guess it must be good?) work!

Here is someone who knows his concurrency and made C++ maps that might be better than TBB btw: https://github.com/preshing/junction

But no guarantees... you never get those with C/C++, I stopped downloading C/C++ code from the internet unless it has 100+ proved users! So stb/ttf and kuba/zip are my only dependencies.

Re: Server-Sent Events: an alternative to WebSockets

#243

Post by bullen »

bullen wrote: post #205
dlsa wrote: post #170

Earlier quoted context omitted.

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

Re: Server-Sent Events: an alternative to WebSockets

#244

Post by lelanthran »

bullen wrote: post #242
lelanthran wrote: post #239

Earlier quoted context omitted.

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.

CAS? Me neither, but I know it does in practice. My intuition tells me the VM provides a layer decoupled from the hardware memory model so that there is less "friction" and the GC is required to reclaim shared memory that C++ would need to "stop the world" to reclaim anyhow! (all concurrent C++ objects leaks memory, see TBB concurrent_hash_map f.ex.) That means the code executes slower BUT the atomics can work better…

> CAS?

https://en.wikipedia.org/wiki/Compare-and-swap

> My intuition tells me the VM provides a layer decoupled from the hardware memory model so that there is less "friction" and the GC is required to reclaim shared memory that C++ would need to "stop the world" to reclaim anyhow! (all concurrent C++ objects leaks memory, see TBB concurrent_hash_map f.ex.) That means the code executes slower BUT the atomics can work better.

I dunno about the GC bits; after all object pools are a thing in C++ so you have a consistent place (getting a new object) where reclamation of unused objects can be performed.

I think it might be down to mutex locking. In a native program, a failure to acquire the mutex causes a context-switch by performing a syscall (OS steps in, flushes registers, cache, everything, and runs some other thread).

In a VM language I would expect that a failure to acquire a mutex can be profiled by the VM with simple heuristics (Only one thread waiting for a mutex? Spin on the mutex until its released. More than five threads in the wait queue? Run some other thread).

Re: Server-Sent Events: an alternative to WebSockets

#245

Post by account42 »

Spivak wrote: post #167
smw wrote: post #114

Earlier quoted context omitted.

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.

Re: Server-Sent Events: an alternative to WebSockets

#246

Post by account42 »

smashah wrote: post #185
bullen wrote: post #16

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 hard…

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!

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

Re: Server-Sent Events: an alternative to WebSockets

#247

Post by dkersten »

bullen wrote: post #241
dkersten wrote: post #226

Earlier quoted context omitted.

> 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 app…

I didn't know how small the MIT license was!!! "Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software…

Great, that's all I wanted. I hope it didn't take you more than a few minutes to do.

> I didn't know how small the MIT license was!!!

This is kind of a problem, before you were saying its like the MIT license but if you didn't know how small it was, you couldn't have read it, so...

Anyway, no point in beating a dead horse, you have corrected the issue I had, so thank you!

> laws are really the most superficial waste of time

Until you need them, at least.

In any case, good luck with your project. It does technically look very interesting.

Re: Server-Sent Events: an alternative to WebSockets

#248

Post by jupp0r »

klabb3 wrote: post #223
homarp wrote: post #188

Earlier quoted context omitted.

https://www.youtube.com/watch?v=J4fR5aztSwQ - Securing the Next Version of HTTP: How QUIC and HTTP/3 Compare to HTTP/2 "QUIC is a new always-encrypted general-purpose transport protocol being standardized at the IETF designed for multiplexing multiple streams of data on a single connection. HTTP/3 runs over QUIC and roughly replaces HTTP/2 over TLS and TCP. QUIC combines the cryptographic and transport handshakes in…

I think the common definition of e2e encryption covers user-to-user communication, so I'm confused how a transport protocol can offer e2e encryption at all (it would only do so if Quic is used over p2p between users, but that's a property of the application). But even if the definition were different, http+tls would also be e2e encrypted (if used in conjunction which it pretty much always is). I appreciate Quic but f…

QUIC had 0-roundtrip handshakes and brought it to TLS 1.3.

Re: Server-Sent Events: an alternative to WebSockets

#249

Post by jupp0r »

bullen wrote: post #67
jupp0r wrote: post #56

Earlier quoted context omitted.

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:/…

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.

Re: Server-Sent Events: an alternative to WebSockets

#250

Post by kreetx »

coder543 wrote: post #70
kreetx wrote: post #40

SSEs had a severe connection limit, something like 4 connections per domain per browser (IIRC), so if you had four tabs open then opening new ones would fail.

Browsers also limit the number of websocket connections. But, if you're using HTTP/2, as you should be, then the multiplexing means that you can have effectively unlimited SSE connections through a limited number of TCP connections, and those TCP connections will be shared across tabs. (There's one person in this thread who is just ridiculously opposed to HTTP/2, but... HTTP/2 has serious benefits. It wasn't develope…

Right, but this article argues that SSE is simple and easy to debug on the wire - so is http1. Http2 is easy to set up, so are websockets, yet debugging the multiplexed http2 stream is is not that simple anymore.

The SSE connection limit is a nasty surprise once you run into it, it should have been mentioned.

Post reply on HN