Socket.io: Server-Sent Events transport

[mscdex]

I recently wrote a transport for using XHR for sending and Server-Sent Events for receiving. In my opinion SSE provides a great alternative to the overhead of websockets (especially if you're mostly receiving data and not sending very often).

Also, there were some recent changes to the SSE editor's draft that show possible upcoming support for cross-origin usage: http://dev.w3.org/html5/eventsource/. Mozilla has already committed changes to utilize this usage based on this draft: https://hg.mozilla.org/mozilla-central/rev/ed783dfd8179. This will make SSE even more handy/useful. I have already taken the initiative to add support for this in the transport as well.

Is there any interest in adding a transport like this?

[einaros]

I've been meaning to look into this. If no-one else gets started before I find time (which would probably be the coming week), I'll implement it.

[mscdex]

I already have it implemented in my fork. I was just checking to see if it was worth sending a pull request.

EDIT: Pull requests sent :-)

[einaros]

Right, #732. But there's going to take a bit more effort than that to land it entirely. I'll get back to this when I get back home on Monday.

[mscdex]

I'm not sure what you mean. I've sent pull requests for both server and client side (socket.io-client). I have already tested the changes and have been using it for some time now without issue.

What do you see missing?

[3rd-Eden]

I also support for EventSource in my own forks, I didn't submit a pull request for them because they are without test cases.
Also your implementation is missing support for Opera 9

[mikeal]

I need this too, what is preventing a merge?

[rauchg]

@mikeal what situation do you have of server-sent events support without websocket support?

[mikeal]

Android, all versions.

[3rd-Eden]

Server Send Events do not work on android's native browser (which should be considered the default most use browser for now, until google pushes chrome harder) see http://caniuse.com/eventsource for browser support and here's a confirmation from the emulator: http://cl.ly/image/0y380Y3Y2D1S

[mikeal]

I'm actually doing a phonegap app and the webkit view still isn't chrome even in latest Android :(

[maxogden]

SSE uses HTTP which means you get HTTPS for free whereas none of the java websocket implementations have implemented wss://

SSE would be trivial to implement as a phonegap polyfill. I also can't get any of the existing transports to work on the android browser over https but this is probably a separate issue

[njh]

Why was this closed? Any plans to add Server Sent Events?

[adrai]

Any opinion or plan to add SSE in v1.x?

[JohnBaileyN]

Why was this closed?

[rauchg]

SSE doesn't provide any meaningful advantage to us over WS.

[njh]

SSE doesn't provide any meaningful advantage to us over WS.

Any more details on why you think this?

Here are some of the reasons why I think Server Sent Events are worthwhile:

• It is just plain HTTP not a separate protocol
  
  
  
  • falls back to long-polling, if client/server don't have specific support for it
  
  
  • works with unmodified HTTP proxies
  
  
• It is less generic than Websockets, which means it is possible to build a generic distribution server, that doesn't require application logic
  
  
  
  • it would therefore also be possible to provide a commercial SSE CDN service
  
  

[passcod]

SSE+HTTP2 means a single connection over a single port, which provides interesting advantages as well.

[rauchg]

True. Very close to polling+HTTP2 for the time being.

[JohnBaileyN]

@passcod What do you mean by "single"? Do you mean persistent on one instance?

[passcod]

As per section 9.1 of the HTTP/2 spec:

Clients SHOULD NOT open more than one HTTP/2 connection to a given host and port pair, where the host is derived from a URI, a selected alternative service [ALT-SVC], or a configured proxy.

A client can create additional connections as replacements, either to replace connections that are near to exhausting the available stream identifier space (Section 5.1.1), to refresh the keying material for a TLS connection, or to replace connections that have encountered errors (Section 5.4.1).

A client MAY open multiple connections to the same IP address and TCP port using different Server Name Indication [TLS-EXT] values or to provide different TLS client certificates but SHOULD avoid creating multiple connections with the same configuration.

Servers are encouraged to maintain open connections for as long as possible but are permitted to terminate idle connections if necessary.

(All emphasis mine.)

It is my understanding that a browser is a _single_ client. Thus, _all_ requests, SSE streams, Server Push, etc for _all_ tabs of a browser connecting to a single domain/port pair would go through the _same_ multiplexed TCP connection.

[runvnc]

Then the conclusion is that socket.io is an outdated library. I will select an alternative.

[mkonecny]

@runvnc did you find any alternatives?

[runvnc]

Off the top of my head I don't remember a comprehensive wrapper like socket.to but if you can restrict the browsers at all then you can use plain websockets or HTTP 2 server push.

[Leo-Mu]

Off the top of my head I don't remember a comprehensive wrapper like socket.to but if you can restrict the browsers at all then you can use plain websockets or HTTP 2 server push.

So this is painful right, especially after QUIC and HTTP/3 announced. Today this is already a very necessary feature.