11

I'm working on a web app that is accessible to users via multiple platforms from smartphones to desktops which needs to sometimes make a communication between two clients for example if I want my friend to join my network I'd send him a friend request but I want that request to be seen by my friend without him having to refresh the page.

In this scenario which would be a better choice? And also since I want this to work on as many platforms and browsers as possible which has more browser support? Is there a better option?

user3053234
  • 375
  • 1
  • 4
  • 16
  • Possible duplicate of [WebSockets vs. Server-Sent events/EventSource](https://stackoverflow.com/questions/5195452/websockets-vs-server-sent-events-eventsource) – Elias Zamaria May 03 '19 at 00:14

3 Answers3

18

Some things to keep in mind when making this choice.

  • Attempting to fetch content over a WebSocket connection is a poor design decision because WebSockets is a different protocol nested inside an HTTP connection and it can't leverage caching (neither the browsers nor CDNs).
  • Some older proxies won't pass on a Websocket connection unless its hidden within a secure connection while Server Sent Events remains an HTTP connection and won't suffer from this.
  • Neither WebSockets nor SSE are supported in the native Android browser until 4.4 (when they switched to using Chrome) - thus if you're considering a hybrid mobile app, you will need a fallback such as SocketIO since, as of this writing, 4.4 is only 20% of the market and hybrid apps use the native Android browser.
  • WebSockets is the most battery efficient protocol for mobile devices, since all other options require many HTTP connections and it is the repeated negotiating of the headers that will burden the cpu and drain the battery.

Another option may be notifications. All mobile devices now support notifications that can be targeted to an App and a number of browsers have as well. In all cases a connection already exists from the client to the messaging center (Apple, Google, Microsoft, etc) and all notifications are sent over this channel.

Here's a good overview of WebSockets vs. SSE: http://www.html5rocks.com/en/tutorials/eventsource/basics/

JaysonRaymond
  • 596
  • 6
  • 8
  • I've read through all the answers and your seemed to be the most helpful and logical. Thanks :) – user3053234 Sep 19 '14 at 15:03
  • 2
    "All other options require many HTTP connections". Doesn't SSE require just one? – matanster Nov 04 '15 at 00:37
  • 1
    SSE does require just one connection for the client to receive events from the server, but a new connection will be required for every time the client needs to update the server. – JaysonRaymond Nov 11 '15 at 20:23
  • HTTP KeepAlive has been with us since 1.1, and means that most of the time, a new TCP connection is not required. Websocket/SSE do save the header (which can be quite significant) and the roundtrip (main cause of latency). – Eric Grange Jul 18 '16 at 09:26
  • "Attempting to fetch content over a WebSocket connection is a poor design decision because WebSockets is a different protocol nested inside an HTTP connection and it can't leverage caching (neither the browsers nor CDNs)." You can implement caching yourself. I wouldn't say it's a poor design. In some real-time applications caching isn't needed as you will always want to see the most recent data. – Konrad Jul 01 '19 at 11:48
1

  • Server Sent Events: A persistent connection server-2-client only, for sending text messages and that is implemented in all major browsers, but Internet Explorer. It can reconnect itself if connectivity is lost. http://caniuse.com/eventsource

  • WebSokets: A full duplex persistent connection capable of transmitting UTF8 text and binary data. http://caniuse.com/websockets

WebSocket is better, and the future.

vtortola
  • 34,709
  • 29
  • 161
  • 263
  • 10
    Your facts are correct, but your summary is not. The 'future' should be about the right tool for the job. For instance, because WebSockets is a different protocol nested inside an HTTP connection, it can't leverage caching proxies (C!DN) some proxies don't handle it correctly and it can't leverage – JaysonRaymond Aug 28 '14 at 10:41
  • Can Server Sent Events? The question is about SSE vs WS. You may have misread the OP's question. – vtortola Aug 28 '14 at 11:02
  • This comment got posted before I was done, see my answer here to see other things to take into consideration when making this choice. – JaysonRaymond Aug 28 '14 at 11:34
0

From what I understand, SSEs are simpler and easier to implement, whereas WebSockets offer bi-directional data transfer but are their own protocol/API you need to understand to take advantage of. Honestly I've never really bothered with SSEs, Socket.IO does all I've needed as far as real time web app communication fairly easily and is built to be cross-browser.

If you just want him to be able to see a notification, then SSEs should be fine. If you want him to be able to reply to your friend request from the same page, then have the server send you a notification that he's accepted, you'll probably want to use a WebSockets implementation.

rw-nandemo
  • 1,210
  • 1
  • 9
  • 17