Is it worth upgrading a long polling solution to SSE? Would I see much benefit? What I mean by that is client sends request, server responds in up to 2 minutes with result or a try again flag. Either way client resends request and then uses response data if provided.
Yes, since IE7 is out of the game long-polling is no longer needed. Comet-stream and SSE will save you alot of bandwidth and CPU!!!
With WebTransport around the corner I don't think is worth the time investing in learning a, what seems to me, obsolete technology. I can understand it for already big projects working with SSE that don't want to pay the cost of upgrading/changing but for anything new I cannot be bothered since Websockets work good enough for my use cases. What worries me though is the trend of dismissal of newer technologies as bein…
Around the corner? There seems to be nothing about this in any browser. [0] That would put this what, five years out before it could be used in straightforward fashion? Please be practical.
This is really interesting! I wonder why it never really took off, whereas websockets via Socket.IO/Engine.io did. At NodeBB, we ended up relying on websockets for almost everything, which was a mistake. We were using it for simple call-and-response actions, where a proper RESTful API would've been a better (more scalable, better supported, etc.) solution. In the end, we migrated a large part of our existing socket.i…
> At NodeBB, we ended up relying on websockets for almost everything, which was a mistake.
Would you please elaborate on the challenges/disadvantages you've encountered in comparison to REST/HTTP?
This seems fairly cool, and I appreciate the write up, but god I hate it so much when people write code samples that try and be fancy and use non-code-characters in their code samples. Clarity is much more important then aesthetics when it comes to code examples, if Im trying to understand something I've never seen before, having a bunch of extra non-existant symbols does not help.
Are you referring to the `!==` and `=>` in their code being converted to what appears to be a single symbol? Upon further inspection, it looks like the actual code on the page is `!==` and `=>` but the font ("Fira Code") seems to be somehow converting those sequences of characters into a single symbol, which is actually still the same number of characters but joined to appear as a single one. I had no idea fonts coul…
That's called a ligature[1], and clasically used for joining for example ff or fi into more readable symbols.
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…
>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.
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.
> 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.
Personally, while I appreciate the difference from a promotion-of-FOSS point of view, I find it obnoxious that FOSS idealists think they can dictate the usage of the generic phrase “open source” and start these kinds of arguments in threads where non-completely-free software whose source is open comes up. We haven’t all agreed on your terminology, and the argument is not “settled” except in the minds of the folks who think everyone should be on board with making this purity distinction. Some people find the distinction uninteresting and don’t need to bother themselves with the ideological argument or agree to its terminology. And trying to be the arbiters of language is not a good look for the “information wants to be free” crowd.
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…
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
Mind expanding on your experience and how are websockets more reliable than SSE? one of the main benefits of SSE is reliability from running on plain HTTP.
I've done both. One big one is Sse connections will eventually time out, and you WILL have to renegotiate, so there will be a huge latency spike on those events. They are easier in elixir than most pls, but honestly if you're using elixir, you might as well use phoenix's builtin we socket support.
How is this different from websockets? They will eventually close for various reasons, sometimes in not obvious ways.
I've done both. One big one is Sse connections will eventually time out, and you WILL have to renegotiate, so there will be a huge latency spike on those events. They are easier in elixir than most pls, but honestly if you're using elixir, you might as well use phoenix's builtin we socket support.
Not if you send "noop" messages.
In my experience, sse times out way more than ws, even if you are always sending (I was streaming jpegs using sse).