Suggestions for push content to http clients

[wlanboy]

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?

 

[WebSearchingPro]

Sounds like a pretty awesome idea you have there, I will definitely be following this one.

 

[wlanboy]

Noone else working with async WebSockets?

 

[fisle]

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

Take a look at this.

 

[wlanboy]

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]

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.

 

[hzr]

SPDY is deprecated isn't it? I thought it was QUIC now

 

[wlanboy]

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.