I've been a blackberry user for the past 6 years. I've convinced myself to make the switch to an Android device. I have already started some Android development so having an actual android device would be a bonus.
My question: How exactly does push-email works in non blackberry phones? Here is what I have gathered with some deductive reasoning, but please correct me: on BB, there is the Blackberry Internet Service, or Blackberry Enterprise Service. They are servers that RIM controls, and they pool your email accounts (whether it is a gmail account or imap accounts on your own linux boxes) for new emails. Once a new email arrives, they push that email to your phone. They know how/where your phone is (its IP address or another unique characteristic) because every time you subscribe to a GPRS/3G antenna your mobile operator notifies BB that customer X with phone Y can be reached at address Z.
Now what happens in a non-BB scenario? How does my own linux server running imap (say dovecot) knows how to contact my mobile phone to "push" the new emails?
After reading a bit I stumbled upon IMAP IDLE, which from what I understand is an IMAP command that the client (my mobile phone in this instance) uses to say to the server: "Hey , i'm client X, and my address is Y, so if any new email comes push it here".
Here is where I'm gradually losing understanding: Does this mean that each time I switch from one mobile antenna to the next (say i'm driving down the road) my phone will send a new IMAP IDLE command to my dovecot server saying "Hey, my contact address has changed, please use this one".
What happens when you are using both WIFI and 3G? Does your phone issue two IMAP IDLE commands?
Finally, do all mobile phones (with a data plan) have unique IP addresses? If not (say the telco NATs you) how can my imap server initiate a communication to my device?
As you can see I'm a bit lost and I would be grateful for some more information.
Best Answer
NO - IP Connectivity
You phone is communicating with the cell masts using a different protocol stack from the TCP/IP stack you use to make "data" connections to the Internet (such as the s7 stack). As you roam from cell mast to mast, the IP stack is ignorant of the changes. Your phone is still using the same IP (usually) all the time (unless you travel a long way, not just down the road the the next mast, to somewhere you carrier has allocated a separate geographic IP bloack).
NO - Single default route
No, your phone will only be using one of them to send/receive data on the Internet (unless you have some magical load balancing phone, I've never seen one, but hey, we can't all have seen everything!). It will pick a preferred one and install a default route into it's routing table via that medium (typically wifi of course).
NO - There's a shortage "ya" know ;)
This is very rare indeed, in fact I have never seen it only heard of it. So I don't believe it still. Giving each mobile user a public IP would be far to wasteful, the same as giving every computer in your house a public IP. You likely have as many Internet capable mobiles in your house as you do PCs. With one wifi AP they can all share 1 IP. No-brainer for "typical" home use.
Single Port/UPNP - You don't need "full" IP visibility
In order for your phone to communicate with your server (over IMAP) you will connect to TCP port 143 (or possibly 993 if you are wise) from a random outgoing port number above 1024 on your mobile. The NAT device at the carrier can create a NAT state table entriy in their GCN device mapping your phones private IP and source port to your servers public IP and port number. This will explain NAT further. Essentially though, you only need to connect to one port, which is quite simple for NAT. Another option such as that often used in home routers is UPnP forwarding but this is unlikely used at the carrier level.
To Wrap Up - IP Changes
So, when you are constantly on 3G, as you roam from cell to cell or mast to mast, your private IP between you and the carrier might change but your public IP talking to your IMAP server should stay the same so the IMAP connection should stay active. If you change public IP mapping, the worst that can happen is that the IMAP server doesn't recognize the IDLE prompt to keep the connection alive, as it doesn't recognize this as the already authenticated session, so assuming your IMAP username and password are saved to you phone, it should simply re-authenticate from your new public IP (phone and mail app dependent, but this is the behavior I find 9/10 times).
The same should be true if you connect to a wireless access point. If the IMAP server has a strop you will just re-authenticate from your new IP and carry on as normal.