Show HN: Realtime Server-Sent Events in Go(sse.getgin.io)
sse.getgin.io
Show HN: Realtime Server-Sent Events in Go
http://sse.getgin.io
13 comments
Yeah, your precious benchmark was well appreciated by the folks on the HN "room". Thank you.
Anyone want to take a stab on exactly what happened that made this test crash it? 4k requests / second would mean that if you had 100 people connected, it would spawn 400,000 outbound messages per second on the server side, or 4,000 for each user. That wouldn't overwhelm an http connection limit but I guess it would overwhelm the processors on the server side. Plus perhaps make some browsers crash from JS trying to process so much incoming information without disconnecting.
it uses a 2 cores machine.
You sir made my browser crash.
we noticed
lmfao
Cool! I love net/http.
Below is my stab from a while ago. It's more of an example than a library.
https://github.com/wyc/go-server-sent-events-example/blob/ma...
I think it's great that the language makes the implementations so similar.
Below is my stab from a while ago. It's more of an example than a library.
https://github.com/wyc/go-server-sent-events-example/blob/ma...
I think it's great that the language makes the implementations so similar.
IP blocking running. It is a Gin middleware for rate limiting.
It doesn't seem to be doing a great job. User "hello" keeps sending several thousand message bursts. On the flip side, the rest of the backend seems to be doing a fantastic job handling the bursts.
yeah! it took me some time to get it right. I did not planned it well.
It is stable now. I will post my thoughts after the storm. Now I am too busy managing the threats.
I'm curious what the bounds are on the client-side use case. For instance, machines can handle tons of simultaneous http connections, but it's easier to reach that limit if you hold SSE connections open for a while.
I've used SSE in the context where we sent chunked pages of one output stream (where the stream was generated server-side all at once), but not where the connection is opened and then actually waiting for additional server information. Is it common for SSE connections to be held open for 30 seconds or even several minutes to be able to stream information?
I've used SSE in the context where we sent chunked pages of one output stream (where the stream was generated server-side all at once), but not where the connection is opened and then actually waiting for additional server information. Is it common for SSE connections to be held open for 30 seconds or even several minutes to be able to stream information?
Both Chrome and Firefox limit you to 6 simultaneous http connections to the same host. Try opening this app in 7 separate tabs, and you'll see the 7th one just spin and not even load the page's HTML.
At least in Firefox, the limit for websockets is much more generous (200, but shared across the whole browser, IIRC).
Both the Chrome and Firefox dev teams WONTFIXed my suggestion to increase the limit for Server Sent Event connections.
https://code.google.com/p/chromium/issues/detail?id=275955
https://bugzilla.mozilla.org/show_bug.cgi?id=906896
At least in Firefox, the limit for websockets is much more generous (200, but shared across the whole browser, IIRC).
Both the Chrome and Firefox dev teams WONTFIXed my suggestion to increase the limit for Server Sent Event connections.
https://code.google.com/p/chromium/issues/detail?id=275955
https://bugzilla.mozilla.org/show_bug.cgi?id=906896
SSE lets you keep the connection as long as you want. I am not sure what you mean by client-side. If you mean Web Browser then I believe there is certain limit of parallel HTTP connections that you can have depending on the browser. http://stackoverflow.com/questions/985431/max-parallel-http-....
I'm more wondering about the number of open HTTP connections that a server can support. Googling around, I see mentions of 64,000 for vanilla servers, perhaps millions depending on the server (affected by # of processor...?)
So if your SSE connection is 10 minutes long and you might have more than 64,000 simultaneous connections to your vanilla box in those 10 minutes, you just need to start load-balancing I guess.
So if your SSE connection is 10 minutes long and you might have more than 64,000 simultaneous connections to your vanilla box in those 10 minutes, you just need to start load-balancing I guess.
There's a common misconception about the number of TCP connections a server can handle being limited by the number of local ports (~64K). The real limit is in the number of LocalIP+LocalPort+RemoteIP+RemotePort pairs. If your traffic is coming from arbitrary Internet addresses, then you are not limited by ports.
Of course you'll be limited by other factors such as kernel fd limits (which are adjustable) and the CPU needed to monitor lots of sockets.
Of course you'll be limited by other factors such as kernel fd limits (which are adjustable) and the CPU needed to monitor lots of sockets.
The issue with maximum open connections will go away with HTTP/2, and you can get around it today using SPDY since both multiplex connections to a domain.
Awesome demo, although the troll comments are obnoxious. But I guess they're doing their part in showing off the "realtime" nature of the demo.
SSE is awesome, and Gin seems to have a nice implementation. I definitely like the usage for realtime streaming stats since that's a one-way stream.
Chat, however, would be better served with websockets. If it's bidirectional, use websockets and avoid both upstream and downstream cost of setting up a connection.
SSE works, but you should consider it tech debt if you decide to go that way.
</psa>
Chat, however, would be better served with websockets. If it's bidirectional, use websockets and avoid both upstream and downstream cost of setting up a connection.
SSE works, but you should consider it tech debt if you decide to go that way.
</psa>
WebSockets will definitely provide the lowest latency for client->server transmission, but calling SSE "technical debt" for a chat service is a bit harsh. Many chat services get by just fine with HTTP POST for message submission. It's a case of trading low latency for simpler tooling.
Here's a recent article about Secret using POST for sending: https://medium.com/@davidbyttow/scaling-secret-real-time-cha...
Here's a recent article about Secret using POST for sending: https://medium.com/@davidbyttow/scaling-secret-real-time-cha...
It's not so much latency to me. It's the waste. There's both extra latency and extra byte overhead. It's a trivial implementation difference (in all the frameworks I'm familiar with) and as developers, I think we have a responsibility to be efficient and not waste energy and bandwidth.
At scale, you might be talking hundreds or even thousands more clients per server (depending on the server size). On mobile, you use less data which fires up the radio less which directly translates to battery life.
Assuming that your application gets any sort of traction, the 30 minutes of dev time you saved may have a much higher net impact on the world purely by the multiplicative effect. When your product affects that many people, you should remember that you have a responsibility to be sustainable.
At scale, you might be talking hundreds or even thousands more clients per server (depending on the server size). On mobile, you use less data which fires up the radio less which directly translates to battery life.
Assuming that your application gets any sort of traction, the 30 minutes of dev time you saved may have a much higher net impact on the world purely by the multiplicative effect. When your product affects that many people, you should remember that you have a responsibility to be sustainable.
Gives me opportunity to showcase a tiny app I made for Christmas to remotely present photos over the web using SSE and Go: https://github.com/julienschmidt/remotephotoshow
It doesn't use Gin, but httprouter, which is also the basis for Gin.
It doesn't use Gin, but httprouter, which is also the basis for Gin.
Neat .. is it supposed to show next/previous photo's in the slideshow, though? Because that doesn't seem to be working for me.
Thanks for providing the link - I'll definitely learn me some httprouter soon ..
Thanks for providing the link - I'll definitely learn me some httprouter soon ..
SSE is awesome...except for the fact that IE has 0% support and is too popular to ignore.
It is a very pretty demo tho, well done :)
It is a very pretty demo tho, well done :)
SSE is easy to shim! We use: https://github.com/Yaffle/EventSource/
Sadly these shims require a per-client queue to ensure message delivery, as events will otherwise be lost during reconnections.
Really you should have a queue anyway to account for those on less reliable connections (mobile, satellite, comcast)
EventSource natively supports this via the "Last-Event-ID" header (and can also be used by a shim to ensure it gets messages it missed). And in the case of a room style app you probably already have a room history that can be used to provide this data.
EventSource natively supports this via the "Last-Event-ID" header (and can also be used by a shim to ensure it gets messages it missed). And in the case of a room style app you probably already have a room history that can be used to provide this data.
I'm not sure I'm following you. How does this differ from native EventSource?
EventSource sends all events over a single connection which it keeps open indefinitely.
This shim receives a single event and then reconnects. In that window there is a period where there will be no connection to send events over, so they will be lost without a queue.
Edit: actually this looks to be a lot more sophisticated than the other shims i havr looked at and does indeed behave more like eventsource. Good job!
Edit: actually this looks to be a lot more sophisticated than the other shims i havr looked at and does indeed behave more like eventsource. Good job!
Ah, you're suggesting that the shims use long-polling. I don't think that's the case though. If I understand the library correctly, it really is keeping a connection open, so it's really very similar to the way EventSource works.
Addition: Verified. It doesn't disconnect between events (not long-polling).
Addition: Verified. It doesn't disconnect between events (not long-polling).
[deleted]
That looks like a very high quality shim, so that is good.
However, why would I want to use a shim over websockets?
http://caniuse.com/#feat=websockets
However, why would I want to use a shim over websockets?
http://caniuse.com/#feat=websockets
I'm not sure how much of this still holds true, but here's a few reasons you might want to stick to HTTP: https://speakerdeck.com/3rdeden/websuckets
tl;dr websockets can fail in strange ways on mobile and when passed through proxies and corporate firewalls
tl;dr websockets can fail in strange ways on mobile and when passed through proxies and corporate firewalls
If you are interested `eventsource` is a Server-sent event library that ties into the Go std http library.
https://github.com/antage/eventsource
https://github.com/antage/eventsource
Cool and all, but I really wish there was a better word than "realtime". I dislike when we hijack a word that already has a meaningful use.
Nice. It didn't like <> as a username, however. The chat will no longer load.
This is beautifully done, and simple and effective. Great demo page!!
```
var int = 1;
window.setInterval(function(){
int = int + 1; var data = { message: "test " + int, nick: "rl" };
$.ajax({ type: "POST", url: "http://sse.getgin.io/room-post/hn?nick=rl", data: data, });
}, 5);