4 ms·
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 hav
by DaiPlusPlus 5y ago
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), though latency is already minimal so I don't think that can be improved upon.
That said, I do prefer using the existing pre-built SignalR libraries (both server-side and client-side: browser and native executables) because the library's design takes away all the drudgery.
- Lorin 5y agoIsn't QUIC for IIS still being tested https://techcommunity.microsoft.com/t5/networking-blog/enabling-http-3-support-on-windows-server-2022/ba-p/2676880 https://techcommunity.microsoft.com/t5/networking-blog/enabl...
- DaiPlusPlus 5y agoHuh - that article is weird, I've been using QUIC in IIS on Windows Server "2004" (2020-04) for almost 2 years now, see https://serverfault.com/questions/824278/can-iis-serve-my-net-app-over-the-quic-protocol https://serverfault.com/questions/824278/can-iis-serve-my-ne... Maybe it's still in testing in Server 2022 but fine in 2004?
- hishamp 5y agoYes, that might be the case, it might be due to the implementation issues from my part. And in that case, instead of taking too much time configuring SSE, we decided to move back to WS which already had resources in place to easily get things done, which worked well for us. Not against SSE, just saying it didn’t work out for us for our specific requirements with our team size and expertise. Just a heads up, that’s all.