I often end up in discussions on how "push" messaging works to a browser, a phone or a client behind a firewall/NAT. The use case being that the device appears to get real time notification that something happens, a message pops up etc... without having to poll for it.
Really, they all use the same mechanism, just over various protocols. In all these environments, you can assume that the device can not be reached from an "inbound" connection (ie a network connection that starts outside, and wants to reach the device) - but only in response to the device reaching out over the network to a server.
So the solution is to have a "long poll" or "slow poll" - in http sometimes it is called a "hanging get" - I think this is also similar to what HTML5 is standardising as WebSockets (but I haven't looked specifically at it). The client device opens a connection (http or whatever) and the server end just lets it hang - holds it open (via whatever means) - and either it times out (in which case the client just reconnects, and it starts again) or the server has a message to send to the client, which it then sends as the reply, immediately. Thus you get something that is close to push in terms of the user experience (the only time there would be a lag would be between a timeout and a reconnect - but that would be milliseconds, ideally, so not too noticeable).
It really isn't a huge mystery, and has been done for a long time. Unfortunately, on my iphone at least, it just ends up chomping batteries, but that is another story.
