As has been pointed out you may rely on RPC methods, but this might give unacceptable latency.
At IntelliFactory we are now working on a project that required asynchronous bi-directional and low-latency communication between the server and the client. We ended up using the WebSocket protocol. We are planning to document and release the code into a reusable library soon for people with similar requirements.
The prime advantage of the WebSocket protocol for our purpose was that it allowed to maintain state on the server side of the connection. Our server is a worker role running in Windows Azure. The server is selected randomly by the Azure load balancer when the WebSocket connection is established, and the client talks to the same server while the connection is open. This allows maintaining expensive to initialize per-connection state on the server.
The disadvantage of the WebSocket protocol is lack of support by older browsers. A portable low-latency alternative is SignalR that uses some form of HTTP polling to emulate the functionality on older browsers. Unfortunately we have so far failed to adapt SignalR to our requirements on Azure. It should theoretically be possible but since AFAIK SignalR follows a mostly stateless design this would require coding up a router to redirect messages and "undo" the effects of Azure load balancer.