amuck-landowner

Suggestions for push content to http clients

wlanboy

Content Contributer
Our sports club is hosting quite a big tournament and we want to provide live coverage.

I want to build something that can cover this and I am looking for some input.

There are quite some options for this scenario:

  • Static pages: git commit -> git pull
  • XMLHttpRequest
  • Web sockets
  • Messaging through AMPQ
After thinking about the scenario - a lot of different pages (sport clubs) / a lot of viewers  - it is all about Publish/Subscribe and therefore I am using AMPQ.

So I would need:

  • Webserver providing static html+css+js
  • AMPQ server (RabbitMQ)
  • AMPQ client (js) to listen for published information
Because I don't like to solve "does this work?" questions in theory I build a small example app.

Some marks:

  • Yes you can send information because you should be able to test the whole workflow
  • Yes the vmstat thing at the button would be something like the leaderboard.
So we have two different types of information:

  • Persistent information
  • Current information which can be missed.

Any suggestions for improvement or opinions?
 

fisle

Active Member
I thought using WebSockets was not the preferred way anymore? I am using Server-Sent Events myself.

Take a look at this.
 

wlanboy

Content Contributer
I thought using WebSockets was not the preferred way anymore?
Any arguments on that thesis?

I would really like to know if WS/SSE/SPDY or HTML 2.0 (draft) will be the standard for client-server communication.

Websockets, SSE (Server Sent Events) and SPDY are both capable of pushing data to browser clients but they do not solve the problem in the same way:

  • Websockets connections can both send data to the browser and receive data from the browser. A Bi-directional real time TCP connection betweem server and browser.
  • SSE connections can only push data to the browser. It is a HTTP connection for receiving push notifications from a server (using a text/event-stream MIME type) in the form of DOM events.
  • SPDY: Google proposal to extend HTTP with a more efficient wire protocol - like Websockets based on TCP - but maintaining all the former HTTP semantics (encoding, headers, cookies, request/response). One little drawback: SPDY requires TLS.
 

fisle

Active Member
Any arguments on that thesis?

I would really like to know if WS/SSE/SPDY or HTML 2.0 (draft) will be the standard for client-server communication.
I read this when I was fiddling around with push. I am not that familiar with the technologies themself though, just a user.

I did not know SPDY could do pushing too though.
 

wlanboy

Content Contributer
SPDY is deprecated isn't it? I thought it was QUIC now
Not at all. The SPDY protocol is now the foundation of the upcoming HTTP 2.0 protocol.

QUIC (Quick UDP Internet Connections) is an early-stage network protocol (stream multiplexing protocol) with a new Transport Layer Security on top of UDP instead of TCP.

So yes it is hipper but SPDY is not dead at all.
 
Top
amuck-landowner