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

201–210 of 266 posts

Re: Server-Sent Events: an alternative to WebSockets

#201

Post by bullen »

layer8 wrote: post #151
bullen wrote: post #54

Earlier quoted context omitted.

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!!!

What is particular about IE7? According to https://caniuse.com/eventsource , SSE is unsupported through IE11.

You don't need to use Event-Source to use SSE, look at how I implemented it here:

https://github.com/tinspin/fuse/blob/master/res/play.html#L1...

The XHR ready state 3 was wrongly implemented in IE7, they fixed it in IE8.

Re: Server-Sent Events: an alternative to WebSockets

#202

Post by jshen »

johnny22 wrote: post #189
jshen wrote: post #187

Question for those of you who build features on web using things like SSE or web sockets, how do you build those features in native mobile apps?

isn't that just an event dispatcher?

Huh? web sockets and SSE are part of the browser standards. When you build an ios or android app you aren't typically building against a browser. Do people typically build completely different solutions for ios and android compared to web?

Re: Server-Sent Events: an alternative to WebSockets

#203

Post by bullen »

hamburglar wrote: post #156
dragonwriter wrote: post #130

Earlier quoted context omitted.

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

I agree, but let's give them "source available" and maybe they'll be more inclined to help?

We all need to get out of the current legal/monetary system soon enough.

Re: Server-Sent Events: an alternative to WebSockets

#204

Post by Lorin »

DaiPlusPlus wrote: post #180
hishamp wrote: post #179

We moved away from WebSockets to SSE, realised it wasn't makings thing any better. In fact, it made things worse, so we switched back to WebSockets again and worked on scaling WebSockets. SSE will work much better for other cases, just didn't work out for our case. First reason was that it was an array of connections you loop through to broadcast some data. We had around 2000 active connections and needed a less than…

Your write-up sounds like your issues with SSE stemmed from the framework/platform/server-stack you're using rather than of any problems inherent in SSE. I haven't observed any latency or scaling issues with SSE - on the contrary: in my ASP.NET Core projects, running behind IIS (with QUIC enabled), I get better scaling and throughput with SSE compared to raw WebSockets (and still-better when compared to SignalR), tho…

Isn't QUIC for IIS still being tested https://techcommunity.microsoft.com/t5/networking-blog/enabl...

Re: Server-Sent Events: an alternative to WebSockets

#205

Post by bullen »

dlsa wrote: post #170
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…

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.

Re: Server-Sent Events: an alternative to WebSockets

#206

Post by bullen »

ByThyGrace wrote: post #142
anderspitman wrote: post #134

Earlier quoted context omitted.

Take this for what it's worth, but I see you share rupy on pretty much every thread that mentions WebSockets, and I click on the link pretty much every time, and I still have basically no idea what it is. Documentation probably isn't your priority at the moment, but even just a couple paragraphs could go a long way.

I had the same impression as you. I want to learn more about fuse but even their "sales pitch" page is in the same tone of "fuse can do a lot" (and that's fine, I'm sold!) except there is very little documentation at the moment.

I know, I just go by "the code is so small, you should have time to read it".

rupy is a minimalist, from scratch, HTTP app-server that uses non-blocking IO so it can scale comet-stream (SSE or not) which is much better than WebSockets: https://news.ycombinator.com/item?id=30313403

I will never make projects that you just download and double click to run.

I want my users to understand how it works more than I want them to use it!

Or maybe I'm just lazy... :S

Re: Server-Sent Events: an alternative to WebSockets

#208

Post by francislavoie »

U1F984 wrote: post #184

The extra setup step for websocket should not be required: https://caddyserver.com/docs/v2-upgrade#proxy I also had no problems with HAProxy, it worked with websockets without any issues or extra handling.

That's correct, just `reverse_proxy` alone is enough. The request matcher is only needed if you want to make the same request paths get proxied to your HTTP upstream if it doesn't have those websocket connection headers. But if you're always using a path like `/ws` for websockets then you don't need to match on headers.

Re: Server-Sent Events: an alternative to WebSockets

#209

Post by reactor »

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.

Is it possible to have many SSE channels within one tab? ie. within a webpage, lets say there are 10 different widgets need realtime update.

Re: Server-Sent Events: an alternative to WebSockets

#210

Post by noisy_boy »

mmcclimon wrote: post #61

SSEs are one of the standard push mechanisms in JMAP [1], and they're part of what make the Fastmail UI so fast. They're straightforward to implement, for both server and client, and the only thing I don't like about them is that Firefox dev tools make them totally impossible to debug. 1. https://jmap.io/spec-core.html#event-source

Funny because I love fastmail but literally the only complaint I have is their android app takes too long to load
Post reply on HN