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=eventsourceb) 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=websocketsDisadvantage 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