NetTalk Central

Author Topic: Server 'push' updates to refresh a browse?  (Read 3445 times)

Devan

  • Full Member
  • ***
  • Posts: 230
    • View Profile
    • Email
Server 'push' updates to refresh a browse?
« on: May 01, 2013, 04:18:21 PM »
Hey all,

I was chatting to a colleague yesterday who has developed a web based system for a mutual client using Microsoft's Azure Cloud.  It is a nice web system with browses/forms etc. very similar to a NetTalk app, but one feature he showed off that he was very proud of, and that I found intriguing, was that the .NET app provided 'push' updates to the browses on different terminals.

For instance, if the operator at Terminal 'A' entered a new record into a browse screen, within seconds, operators on terminal 'B' and 'C' who had that browse open would experience an automatic refresh of the browse showing the new record.

My colleague was understandably cagey about giving away too much detail, but there is apparently some sort of add on with the Microsoft Azure cloud (where the web app is hosted) that provides this facility.

I know that 'server push' is not a standard paradigm in the web world, but I was wondering if we could replicate this functionality in NetTalk in some way?  Perhaps even a client side 'silent poll' on a periodic basis that would redraw the browse if there was a change?

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11244
    • View Profile
Re: Server 'push' updates to refresh a browse?
« Reply #1 on: May 01, 2013, 08:55:05 PM »
Hi Devan,

I don't think it's too fixed in to Azure. Basically with HTML5 there are two approaches to this.

a) Server Side Events (http://en.wikipedia.org/wiki/Server-sent_events)
SSE's allow the server to send the browser an "event" (with some data). In one sense the traffic here is "one way" (from the server to the browser) although of course the browser already has plenty of ways to talk to the server.
The big advantage of SSE's is that the networking is handled at the browser level (ie a connection is held open, and re-opened if closed automatically.) Also, and this is key, it works over HTTP - meaning it uses the same port which simplifies deployment with regard to firewalls etc.

Compatibility wise - it doesn't work on IE, or apparently the Android browser (as distinct from Chrome browser on Android, or Firefox Mobile browser on Android). However it can gracefully fall back on some sort of timer approach, so it's not terrible there.
http://caniuse.com/#feat=eventsource

b) Web Sockets
An alternative to SSE is Web Sockets. this allows you to open a direct connection (and keep it open manually) between the server and the browser. Big advantage is that you have complete two-way communications. Support is also not 100%, but slightly better than SSE.
http://caniuse.com/#feat=websockets
Disadvantage is that it doesn't necessarily run on the same port, and doesn't use HTTP (but of course since you have control it could be manipulated to do so.)

I've been looking at both for a bit now, but so far haven't folded any code into NT. The key thing to get right is the architecture to make sure it scales as well as possible. Both approaches "use up" a connection on the server - which is usually ok - but it's likely you don't want to create a whole thread for each connection. So one has to be a bit careful in terms of not over-burdening the server with extra threads etc.

In short - I make no promises of course - but it's likely that something along these lines will be folded in some-time in the future.

cheers
Bruce


Devan

  • Full Member
  • ***
  • Posts: 230
    • View Profile
    • Email
Re: Server 'push' updates to refresh a browse?
« Reply #2 on: May 07, 2013, 03:07:05 PM »
Thanks for the extra technical info Bruce !

Thinking back through most of my sites, I am not sure that this would be a 'must have' feature in my apps at the moment, but a 'nice to have' in the future which may open up more possibilities.  The app my colleague demonstrated for instance, was a manufacturing assembly line tracking system, so real time updates on the status of components etc. was critical across the shop floor.

Cheers,
Devan