iPhone Push Notification Server tied to Snow Leopard Server

[AppleInsider]

Despite licensing the proprietary ActiveSync Exchange Server protocol from Microsoft for use with the iPhone, Apple is building its own Push Notification Server for messaging services in both the iPhone and Mac OS X Snow Leopard Server using open, interoperable standards.

However, the company's pioneering, yet protracted leap into push messaging indicates that notification technology can be more complex that it seems, having delayed Apple's intended deadline for shipping PNS by many months.

The push for push messaging

Push messaging relates to information that is sent immediately rather than queuing up on a server, waiting to be picked up. In conventional email, delivery is always push; sending an email immediately pushes it to the server using the outgoing email SMTP service. The client can always push out email because it knows where the SMTP email server is supposed to be.

In contrast, the incoming POP3 or IMAP mail server doesn't typically track the location of the email client, meaning that new emails sit on the server until the client system manually checks for email. This polling process (Apple calls it "fetch") is often set to occur on a schedule, as often as every few minutes. With mobile devices, having to rapidly poll for new emails on the server results in frequent network connections that usually result in discovering that no new emails are available.

The original goal of push messaging was to provide battery savings for mobile devices by having the server track the location of the device so that the server could both push out updates immediately and only when necessary, sparing the mobile device from having to fruitlessly poll for data to stay current.

RIM vs Microsoft in push messaging

The added luxury of having the server track the location of email clients came at a steep price: RIM's highly profitable BlackBerry empire was not built on hardware sales, but rather from service revenues related to licensing its BlackBerry Enterprise Server (BES) software, which is used to track mobile devices and relay them new messages from the corporate email system as they arrive.

Microsoft's Exchange ActiveSync (EAS) software (which has only its name in common with the company's unrelated desktop sync tool) duplicates the role of RIM's BES as an add-on mobile device tracker for facilitating push messaging. Both systems also allow IT administrators to manage the devices they track, limiting the software users can install or remotely wiping a lost or stolen unit, for example.

Apple licensed Microsoft's EAS for iPhone 2.0 rather than introducing its own competing push system, a decision which made the iPhone immediately useable for many businesses who already owned EAS infrastructure, or at least already used Exchange Server and could easily set up EAS for use with the iPhone at no additional cost.

Apple pushes back with MobileMe

At the same time, Apple also completed its own push messaging system for use with .Mac and delivered this alongside EAS in the iPhone 2.0 update. The new cloud push service and the existing .Mac services were fused together to create MobileMe, which allowed home users to enable push messaging on the iPhone without needing an Exchange Server account. In contrast with Microsoft's soon to be officially unveiled My Phone for Windows Mobile users (formerly known as SkyBox), MobileMe supports users' existing email accounts and contacts and also provides data sync with their desktop apps, in addition to web hosting and video uploads.

When an iPhone is set up to perform push messaging with MobileMe, it registers with Apple's cloud servers, which then track its location on the network so that new email, contacts, calendar, and browser bookmarks can be immediately delivered over the air the instant they change on the server, without continuous polling by the device.

MobileMe can also push updates to desktop client computers that register with the service. On Mac OS X, once users enable push messaging, the system registers its location with Apple's cloud servers and updates are pushed to Sync Services, which then distributes the updates to Address Book, iCal, Safari, and any other apps that register with that system. On Windows, iTunes handles the syncing of contacts, events, and bookmarks via a Control Panel interface, and sends new data to the configured Windows apps.

Email push messaging doesn't require messages to run through Sync Services (like calendar and contact updates) because the incoming email IMAP-IDLE service supports the ability for the client to inform the server that it will accept new message notifications. This means that rather than pushing the entire email to the client, the server sends a notification of new email when it arrives at the server, giving the client software the option of downloading it immediately. This is more flexible than a straight push, because the system may want to delay the downloading a large email, particularly if the system is mobile and the user only wants to download full messages when a fast connection is available.

Apple's Push Notification Server

Last year, Apple introduced plans at WWDC to provide a third push mechanism for the iPhone, in addition to EAS support and MobileMe. Rather than pushing updated contacts or calendar messages, the new Push Notification Server (PNS) would allow third party developers to push notifications of any type to the iPhone, which would then badge the application's icon, alerting users that the application had new information waiting for it.

Apple's long-lost Push Notification Service would funnel notification data from third party servers through its own, and then on to users' iPhones.

That application, once started, could then download (or offer to download) whatever new data the notification server had alerted it to. For example, an IM provider might push notifications of new messages to the iPhone in order to badge its specific IM app. A mobile app that presents news, stock events, or some other information via an RSS feed could similarly be badged by the developer via PNS.

PNS was intended in part to allow third party iPhone apps to reflect regular new updates, pushed over the air, without the apps actually needing to stay active in the background listening for updates themselves (and eating up memory and processor cycles while waiting around). Instead, the iPhone would triage all the push notifications itself and badge the apps' icons so users and developers could both benefit from push notifications as efficiently as possible, and without developers needing to implement their own notification system.

Originally due last September, the service would allow iPhone developers to push three kinds of notifications to users' iPhones: badges, alert sounds, and textual messages.

However, Apple indicated that PNS was supposed to ship by last September. That deadline came and went, and the service was never rolled out. Apple released a developer seed with a PNS API, but the company noted that "this API is not yet integrated with a live push server." It appears that PNS ran into unforeseen complications. Apple hasn't given up though; the company itself uses a notification system to push badge updates on the App Store's icon, which then has to be launched to check with the iTunes server of what those notifications actually are, behavior identical to that described for PNS.

With the App Store icon, neither the actual software updates nor even their descriptions are automatically pushed to the phone; its badge is simply incremented by, presumably, PNS. However, the system isn't yet fully operational even for internal use; sometimes apps are available but aren't reflected with a new badge increment, and sometimes the badged number doesn't match the software updates that are actually available. Apple has been working similar kinks out of iTunes, which also tracks available iPhone software updates with less than perfect results.

The progression of a notification badge being sent from a server belonging to a third-party iPhone developer to an iPhone running the developer's application.

Apple has historically allowed a number of technologies to languish as it focuses on the most promising and profitable products to invest its resources in. That's good news for anyone wondering if the company's PNS will ever see the light of day, as the company has so much riding on it. Unlike Apple TV, iCal, and other projects that seem to have taken a long time to develop as back burner hobbies due to the lack of any real revenue stream to justify their development, Apple's PNS is directly related to immediately profitable, high priority projects from the iPhone to MobileMe to iTunes to Snow Leopard Server.

On page 2 of 2: Snow Leopard Push; and Instant messaging is always push.

Snow Leopard Push

While Snow Leopard's Mail, iCal, and Address Book are set to gaining high profile support for Exchange Server messaging, they're also being updated to support open push messaging with Apple's own Snow Leopard Server. Rather than being based on EAS, Apple's own server push products are based on interoperable, open standards, the same as PNS.

Apple's iCal Server, which the company debuted both in Leopard Server and as an open source CalDAV calendar server project, is being updated to use XMPP publish-subscribe, an IETF open standard branching from the core of the Jabber IM service. That means Snow Leopard's iCal Server 2 will push calendar updates to clients using extended instant messages, making it an inherently push service. Like IMAP-IDLE, the system only sends a lightweight notification that new data has arrived, leaving iCal to fetch the new data itself in response.

In contrast, Microsoft's Exchange Server handles calendar events and other data as specially formatted emails, requiring additional infrastructure (RIM' BES or Microsoft's EAS) to supply push functionality for immediate updates. That also requires Microsoft to support a separate set of protocols when talking to desktop clients (MAPI) and mobile devices (EAS).

Instant messaging is always push

The main difference between IM and email is that IM is inherently push. That's because the IM service constantly monitors the location of the client, enabling it to send rapid updates in both directions. The presence indicator systems that IM users must log into required more infrastructure than typical email servers did, resulting in an initial domination of the IM business by proprietary protocols from AOL, Yahoo, and MSN. However, the Jabber project has since introduced an open source IM protocol that has expanded to become the eXtensible Messaging and Presence Protocol (XMPP).

Apple began embracing XMPP in Mac OS X Tiger, with iChat gaining Jabber support on the desktop (next to AOL's proprietary IM protocol), and iChat Server being entirely based upon the open Jabber XMPP specification. That allowed iChat to work with other Jabber IM providers that appeared, including Google's GTalk.

In Snow Leopard Sever, iCal Server is paired with a Notification Server to provide push calendar updates using XMPP's publish-subscribe specification. Also known as pubsub, the service works like a "push RSS feed," so rather than polling an RSS file on a server to discover new updates, the Notification Server pushes out just what's changed to all of the clients who have subscribed to the update system (and who have been authenticated to receive updates). In some respects, the Notification Server is like a secured Twitter feed, with iCal server sending tweets to listening iCal clients to keep them abreast of changes.

Security is important to users who only want to notify themselves, their delegates, and their mobile devices of updates on their server-based calendar. Apple's PNS has similar requirements; adequate security is required to make sure that only a known developer is able to send notification updates through the system, and that only updates requested by the user are sent to their specific phone. Last year's WWDC attendees described Apple's PNS as a secured web service that simply relayed tiny XML messages. Why not use the same XMPP system to relay notification updates to the iPhone as will be used to deliver push calendar and contact notifications? That may be exactly what Apple has in mind, tying the release of PNS with the completion of Snow Leopard Server's own Notification Server.

[ View this article at AppleInsider.com ]

[dagamer34]

Er... this sounds like a non-story. Is PNS vaporware or not?

[pmjoe]

So called "push" notification has always come across as a bit of fiction to me. If my device is sleeping, there is no magical way a remote server can wake my device and force a message upon it. Somewhere underneath the hood, the device is waking up, connecting to the server and accepting messages. The rest is just media hype.

[noirdesir]

Originally Posted by pmjoe

So called "push" notification has always come across as a bit of fiction to me. If my device is sleeping, there is no magical way a remote server can wake my device and force a message upon it. Somewhere underneath the hood, the device is waking up, connecting to the server and accepting messages. The rest is just media hype.

Your device is never really sleeping. Only the display is sleeping. Whenever it changes locations it sends out its new position (cell tower used, IP address etc.) to the mobile operator and to any push notification servers it is linked to (like .me). How do you think you receive SMS or phone calls on your device?

[Constable Odo]

Bottom line is...Is this going to be better in some way than RIM's BES solution? Will it be cheaper? Or will it still be missing some features that companies will claim it's not secure enough or whatever. RIM seems to own the push-email business and after all these years hasn't been challenged at all. I think large corporations still believe the iPhone is just a toy and won't touch it.

[solipsism]

Originally Posted by pmjoe

So called "push" notification has always come across as a bit of fiction to me. If my device is sleeping, there is no magical way a remote server can wake my device and force a message upon it. Somewhere underneath the hood, the device is waking up, connecting to the server and accepting messages. The rest is just media hype.

You can receive SMS and phone calls while your phone is "sleeping" because your phone is still maintaining your cell connection. Sleeping does not mean the device is off. You can even setup your PC to wake on LAN access. The notification server can work in a similar fashion. A simple process runs in the background while pretty much everything else is dormant.



Apple may have changed their direction with PNS. The original system seems to be a separate system to the phone's default systems to monitor any updates. I think a better method that would reduce processing overhead would be to use your cell provider's control channel that it uses to transmit SMS over. In other words, when the notification server gets an update it sends it out as a specially formatted SMS that the iPhone will recognize as an atypical SMS. this prevents you getting it as a normal text message, but as the badge, vibration and/or popup that is allowed. The use of the provider's control channel means that messages can come even even you can't access data( GPRS/EDGE/UMTS) via the cell carrier. Of course, this would cause problems with iPod Touch users or iPhones who are on WiFi but are in a dead cell area. Just a thought.

[Ireland]

Apple with "push" this idea

Like the "push" that rip-off service (I use) called Mobile Moi

[Virgil-TB2]

Originally Posted by AppleInsider

Email push messaging doesn't require messages to run through Sync Services (like calendar and contact updates) because the incoming email IMAP-IDLE service supports the ability for the client to inform the server that it will accept new message notifications. This means that rather than pushing the entire email to the client, the server sends a notification of new email when it arrives at the server, giving the client software the option of downloading it immediately. This is more flexible than a straight push, because the system may want to delay the downloading a large email, particularly if the system is mobile and the user only wants to download full messages when a fast connection is available ...

I'd just like to point out that this description of how email is currently working on the iPhone above is really overly "rosy" in that it makes it seem like it all works fine when clearly it doesn't.

Notifications of new emails as they arrive are indeed pushed to the iPhone but partly because of the differences mentioned above, the mail itself is not actually synced. As a long time MobileMe user I generally like the service now (minimal though it is), but I would still probably jump ship the first time a competitor actually offered *real* IMAP email that actually syncs. The promise of IMAP is to have one email account with one set of mail folders that is synced to be identical on all your devices but this is quite different from what we actually get with the iPhone and MobileMe.

For instance if the iPhone is turned off on your desktop and your local mail client is open on the desktop computer, the iPhone will have acquired the new email notifications as your mail is dealt with on the desktop computer during the day, but only by turning on the iPhone and starting the mobile mail client will it actually update your mail or fetch mail that hasn't been read. It also does not sync email in folders until you actually access that folder, it just focusses on the inbox so as to make it seem like your mail is all being synced. Worse, depending on your settings one often ends up with multiple copies of various inboxes outboxes etc. on your laptop, your desktop, your iPhone and your web client as well as copies of the copies. There is no way to get rid of them save manual deletion or manual resetting of your clients and mail settings.

I am not totally unhappy with this situation as the mail generally gets to where it's going and generally get's marked as read if you wait a few minutes, but this is far from an ideal set-up. I think to just brush it off in one paragraph that mentions the IMAP-IDLE service and implies that everything is rosy and keen is a bit much. It's an ugly, clunky solution that clearly could work a lot better than it does.

If I have one criticism of the "Prince McClean" articles it is this very thing. The detail is impressive and the background coverage and context-setting excellent, but in describing the whole picture there often seems to be an attempt to purposely gloss over some of the details that don't necessarily reflect positively on Apple. A good analysis should be blind to that sort of thing and the author does himself no favours by "hiding" the little bad bits that Apple should really be held accountable for.

Apple is a great company that generally makes great products. They don't need an "apologist" and they do need to be held accountable when they make less than stellar software which they *do* do on occaision.

[pmjoe]

Originally Posted by noirdesir

Your device is never really sleeping. Only the display is sleeping. Whenever it changes locations it sends out its new position (cell tower used, IP address etc.) to the mobile operator and to any push notification servers it is linked to (like .me). How do you think you receive SMS or phone calls on your device?

That's my whole point. The phone is never really sleeping. It's still polling for messages. Messages still get queued. Now, you can correctly argue that this protocol is much lighter-weight and uses less radio time and power than setting up an IP connection and connecting to a mail server, but there's no magic "push" service that's saving battery by pushing out updates "immediately and only when necessary".

[bbwi]

Yeah, for the love of god why doesn't Apple just license ActiveSync? For that matter, why don't they scrap MobileMe all together and just partner with Google. I use MobileMe now but do not foresee any reason to continue paying $100 a year as soon as Gmail offers push email.

IMHO, Google is MUCH better, in every aspect, at delivering web services than Apple and there is no evidence so suggest that would change in the future.

[steviet02]

Originally Posted by pmjoe

That's my whole point. The phone is never really sleeping.".

That wasn't your original point....

[bbwi]

Originally Posted by pmjoe

That's my whole point. The phone is never really sleeping. It's still polling for messages. Messages still get queued. Now, you can correctly argue that this protocol is much lighter-weight and uses less radio time and power than setting up an IP connection and connecting to a mail server, but there's no magic "push" service that's saving battery by pushing out updates "immediately and only when necessary".

Your point is simply wrong and you're failing to understand how the technology works. There simply is no polling involved in a push service.

No messages are queued with push. As soon as they hit your inbox they're pushed to your device (unless your device is physically turned off, then yes, they'd be queued). If there are no messages then nothing is pushed. In a pull method, you need to schedule your phone to check in intervals. If there are messages they will get queued until your phone wakes up and checks. If there are no messages then your phone STILL wakes up and checks. This is where the battery savings come in. When your device is checking for messages even when there are none.

[DrMatatan]

Originally Posted by steviet02

That wasn't your original point....

Yes, that was his point. You just read it wrong

His point was that the device is never really sleeping since its still receiving information from towers,etc. If the device was really sleeping it wouldn't be able to receive calls, sms, updates, etc.

[Wiggin]

Originally Posted by pmjoe

That's my whole point. The phone is never really sleeping. It's still polling for messages. Messages still get queued. Now, you can correctly argue that this protocol is much lighter-weight and uses less radio time and power than setting up an IP connection and connecting to a mail server, but there's no magic "push" service that's saving battery by pushing out updates "immediately and only when necessary".

Perhaps that's why they call it a Push Notification Service? The only thing that's being pushed is the notification, not the content. So yes, the content is being queued. But rather than sit there and wait for the client to request the content, the service is pushing the notification. Your device then only needs to poll for messages when it receives the noticiation, rather than on a continuous schedule, such as every 5 minutes.

Other than in response to a pushed notification, the only connection your device would have to initiate is to keep the server informed of your location, which could be as infrequently as only when your location changes. So if you sit at your desk all day and don't receive any notifications, it's conceivable that the only time your device initiates a connection all day is when you get to your office (although there would probably still be a periodic confirmation of location that your device would perform).

So your device only has to sit and listen all day, which is far less power use than actually transmitting and establishing a connection every 5 minutes to ask if there are any new emails. The difference is similar to the standby time vs talk time for your cell phone.

[nagromme]

So who gets to define "sleep"? A sleeping computer can still receive key and click signals, USB connections, ethernet wake signals, IR remote signals, Bluetooth signals, etc.

... the company itself uses a notification system to push badge updates on the App Store's icon

I don't believe that's true. I have NEVER seen the update badge pushed to my iPhone (and I do have Push enabled--Yahoo uses it). The only time I ever see a number on that icon is if I launch the App Store. (I don't have to go to Updates, just launching into any part of the store is fine). Then, when I exit, any updates I haven't downloaded get counted in a badge.

But if I never launch the App Store, I never see any update badge. That's not push.

[DrMatatan]

Originally Posted by bbwi

Your point is simply wrong and you're failing to understand how the technology works. There simply is no polling involved in a push service.

No messages are queued with push. As soon as they hit your inbox they're pushed to your device (unless your device is physically turned off, then yes, they'd be queued). If there are no messages then nothing is pushed. In a pull method, you need to schedule your phone to check in intervals. If there are messages they will get queued until your phone wakes up and checks. If there are no messages then your phone STILL wakes up and checks. This is where the battery savings come in. When your device is checking for messages even when there are none.

Again the battery lost vs the battery saved can be argued here. Putting intervals and having Push on have really no difference except in the time it takes for you to see your messages vs the time your device pulls your message. For example if you constantly are receiving emails throughout the day with push enabled, the amount of battery life wasted on this service equals having the same service on a "fetch" status since the fetching will still waste the same amount of battery life. You can argue whatever you want but the only difference is in the time you receive the messages since pushed messages arrive almost instantaneously. What companies are trying to sell as novelty here is not the gain in battery life but the gain in the speed in which you receive your messages. Both ways consume battery life, both ways can be implemented in ways that can use up almost close to nothing in battery life. Push attracts and benefits the user more, hence companies are trying to make Push the most battery efficient. Again the only difference is the connection that the options use in order to retrieve your information. No device is ever in SLEEP MODE.

[hmurchison]

Originally Posted by bbwi

Yeah, for the love of god why doesn't Apple just license ActiveSync? For that matter, why don't they scrap MobileMe all together and just partner with Google. I use MobileMe now but do not foresee any reason to continue paying $100 a year as soon as Gmail offers push email.

IMHO, Google is MUCH better, in every aspect, at delivering web services than Apple and there is no evidence so suggest that would change in the future.

Probably because ActiveSync doesn't extend them control neither does partnering with Google. I use Gmail to but I certainly wouldn't use it for anything remotely sensitive. Add based product are insta-breaches of confidentiality (for the foolish person that would use them in a context that requires security). BTW I hope you didn't spend a c note on MobileMe when Amazon has it for $69 (they've sold it .mac and now MobileMe for that price for a while)

I think we are underestimating the complexity of push notification. Hell Apple have have underestimated how difficult it is. RIM became the standard because they got push mostly right.

[mn_hawk]

At the risk of beating this topic to death, I have to follow up on my post from yesterday with all of these NEW features requiring an Intel machine.

What Apple is saying here is that if I have workers with G4 laptops, G5 towers or iMacs, and ANY kind of iPhone . . . I can't push my data to them unless I invest in an Intel based server so that I can install Snow Leopard server. What does this "push technology" have to do with the damn server processor?

I've got clients who spent over $10k on Xserves and RAIDs less than three years ago who are basically being told "we don't care about you anymore". Hey, if this was a G4 mini, that would be one thing, but a SERVER? Sounds to me like Apple should just get out of that whole market space because no IT department is going to trust blowing that kind of money to be pushed aside at a whim.

[hmurchison]

Originally Posted by mn_hawk

I've got clients who spent over $10k on Xserves and RAIDs less than three years ago who are basically being told "we don't care about you anymore". Hey, if this was a G4 mini, that would be one thing, but a SERVER? Sounds to me like Apple should just get out of that whole market space because no IT department is going to trust blowing that kind of money to be pushed aside at a whim.

They're fine with the RAID it'll work regardless if Intel or PPC chips but if they got 3yrs out of a 1U server that's not a bad deal. After all they can depreciate that hardware and typically business will do no longer than a 36 month lease on computer hardware because in fact most hardware is on the poor side of the value curve beyond 36 months.

[themacbuddha]

Originally Posted by bbwi

Yeah, for the love of god why doesn't Apple just license ActiveSync? For that matter, why don't they scrap MobileMe all together and just partner with Google. I use MobileMe now but do not foresee any reason to continue paying $100 a year as soon as Gmail offers push email.

IMHO, Google is MUCH better, in every aspect, at delivering web services than Apple and there is no evidence so suggest that would change in the future.

bbwi - Apple did license ActiveSync - more than a year ago. That support is coming for Mac OS X in Snow Leopard, as is mentioned in this article and during the WWDC keynote last year. But that is just Apple making OS X a first class citizen for businesses. MobileMe gets a lot more things right than it does wrong. The fact that sync from the MobileMe cloud to my iPod touch is pretty quick now, usually between 5 and 10 seconds, tells me they are heading down the right path. My understanding is that Snow Leopard will address this in the desktop client. I can only assume that syncing to the cloud will subsequently improve on both the desktop and the mobile device too.

Google licensed ActiveSync too. And I haven't heard of any plans for them to offer a home-grown solution. In Apple's case, it is another mostly open source solution that will compete against MS's proprietary offering and against RIM's insecure offering (data goes through their NOC. With Snow Leopard & Exchange Server it does not have to.) So, sure there are some entrenched players in the market(s) where Apple is aiming. That doesn't mean that there isn't a lot more of the market to address or even own. I cite the iPhone as the example.

[mn_hawk]

Originally Posted by hmurchison

They're fine with the RAID it'll work regardless if Intel or PPC chips but if they got 3yrs out of a 1U server that's not a bad deal. After all they can depreciate that hardware and typically business will do no longer than a 36 month lease on computer hardware because in fact most hardware is on the poor side of the value curve beyond 36 months.

I must be the only person who remembers when Apple equipment not only lasted longer than other equipment, but you could upgrade the software for a much longer time. I have two blue and white g3 towers running 10.4.11 with no problem, and three G4 towers running Leopard. These machines are far older than the G5 Xserves.

Apparently I'm the only person who just doesn't feel it's time to dump hardware, and at a time where most companies would be willing to spend $129 but not $5k, Apple is leaving a lot of money on the table.

[hmurchison]

Originally Posted by mn_hawk

Apparently I'm the only person who just doesn't feel it's time to dump hardware, and at a time where most companies would be willing to spend $129 but not $5k, Apple is leaving a lot of money on the table.

Agreed and I don't think that this is anything more than an anomoly. I think Apple will go back to supporting their computers for 5 years. What makes the PPC transition hard is that it's so close to the OS X transition. This behaviour is atypical of Apple IMO but I understand a bit why they are doing it.

Apple has shipped some of the buggiest software that I can recall in the last few years. I think kudos have to go to their engineers who bust their asses to keep the system stable despite Carbon/Cocoa battles and PPC/X86/ARM targets.

[bbwi]

Originally Posted by themacbuddha

bbwi - Apple did license ActiveSync - more than a year ago. That support is coming for Mac OS X in Snow Leopard, as is mentioned in this article and during the WWDC keynote last year. But that is just Apple making OS X a first class citizen for businesses. MobileMe gets a lot more things right than it does wrong. The fact that sync from the MobileMe cloud to my iPod touch is pretty quick now, usually between 5 and 10 seconds, tells me they are heading down the right path. My understanding is that Snow Leopard will address this in the desktop client. I can only assume that syncing to the cloud will subsequently improve on both the desktop and the mobile device too.

I guess I wasn't clear. I am aware that Apple has licensed ActiveSync but they licensed it for the iPhone, not MobileMe. An iPhone can connect to an Exchange environment through ActiveSync but connecting to MobileMe using ActiveSync is not possible, which is what I was getting at.

AFAIK, Snow Leopard will not include ActiveSync but rather a customized solution using RPC over HTTP(s) just like Outlook can for Windows. This is different than ActiveSync

[bbwi]

Originally Posted by DrMatatan

No device is ever in SLEEP MODE.

Then you don't understand what SLEEP MODE is. Read the post from nagromme

[Silencio]

Originally Posted by mn_hawk

At the risk of beating this topic to death, I have to follow up on my post from yesterday with all of these NEW features requiring an Intel machine.

What Apple is saying here is that if I have workers with G4 laptops, G5 towers or iMacs, and ANY kind of iPhone . . . I can't push my data to them unless I invest in an Intel based server so that I can install Snow Leopard server. What does this "push technology" have to do with the damn server processor?

Or you can buy Kerio Mail Server today and get excellent ActiveSync and CalDAV support -- better than Leopard Server IMO. Email, calendar items and contacts push out to iPhones without any trouble at all.

The server runs just great on PowerPC Macs and under Tiger.

[Hattig]

Originally Posted by pmjoe

So called "push" notification has always come across as a bit of fiction to me. If my device is sleeping, there is no magical way a remote server can wake my device and force a message upon it. Somewhere underneath the hood, the device is waking up, connecting to the server and accepting messages. The rest is just media hype.

On a phone the device will wake up the baseband portion to do some kind of ping notification to the central server over a control channel. This channel is also used for text sending and receiving. And in Blackberries, for sending push messages. I presume that unless Apple do the same, then yes, it's not push because most phones try not to wake the main CPU up unless something has occurred.

With the full networking ping, Apple would need to wake up the main CPU and systems, make a network connection to their servers (this takes a bit of time of course), send the required ping messages, and get the responses. This isn't push by any definition, and it also uses up a lot more battery power.

More than likely Apple is going to integrate into the control channel a small message that encodes the application name and a quotient and maybe a tiny message. Then if this occurs the baseband can wake up the main part of the phone to do the bigger data gathering or just handle the control channel message.

No, you can't stream Pandora with the latter. I hope that if the phone is awake, then more adventurous push updates and background apps will eventually be allowed.

[Daniel0418]

Originally Posted by nagromme

So who gets to define "sleep"? A sleeping computer can still receive key and click signals, USB connections, ethernet wake signals, IR remote signals, Bluetooth signals, etc.



I don't believe that's true. I have NEVER seen the update badge pushed to my iPhone (and I do have Push enabled--Yahoo uses it). The only time I ever see a number on that icon is if I launch the App Store. (I don't have to go to Updates, just launching into any part of the store is fine). Then, when I exit, any updates I haven't downloaded get counted in a badge.

But if I never launch the App Store, I never see any update badge. That's not push.

I agree. I never see the the badge update until I go into the app store to check myself. Or sometimes when I sync to iTunes it will show up. That is not push at all. And in this article when it references the Push notification of RIM and Microsoft lets not even go there yet please. First of all Push should have been out 2 years ago when the iPhone came out. The phone is getting old and it is too slow to do things as is. Push notification is far too late for the iPhone now. I am ready to toss my 3G Lag iPhone and get something new that can update freely without lag. AKA the Palm Pre. Something that can truly multi task. And before anybody says the iPhone will out perform any phone at all... How come it lags when I text message. How come it lags in google maps? How come it lags switching from contacts to recents within the phone app. This phone is too slow Push notifications now will only make it work. Please don't pretend this is a business phone. No Business has time to deal with this slow in affective micro computing these days. Maybe the Windows mobile phone isn't pretty to look and and maybe it doesn't have fun games. It gets the job done.... If you guys want to see a noticable difference in quality and crap compare the iPhone to the Black Berry bold.... the bold is FAST. Lag free. You can email, copy/paste and text as well as push notifications all without any lag.

[Daniel0418]

Originally Posted by Daniel0418

I agree. I never see the the badge update until I go into the app store to check myself. Or sometimes when I sync to iTunes it will show up. That is not push at all. And in this article when it references the Push notification of RIM and Microsoft lets not even go there yet please. First of all Push should have been out 2 years ago when the iPhone came out. The phone is getting old and it is too slow to do things as is. Push notification is far too late for the iPhone now. I am ready to toss my 3G Lag iPhone and get something new that can update freely without lag. AKA the Palm Pre. Something that can truly multi task. And before anybody says the iPhone will out perform any phone at all... How come it lags when I text message. How come it lags in google maps? How come it lags switching from contacts to recents within the phone app. This phone is too slow Push notifications now will only make it work. Please don't pretend this is a business phone. No Business has time to deal with this slow in affective micro computing these days. Maybe the Windows mobile phone isn't pretty to look and and maybe it doesn't have fun games. It gets the job done.... If you guys want to see a noticable difference in quality and crap compare the iPhone to the Black Berry bold.... the bold is FAST. Lag free. You can email, copy/paste and text as well as push notifications all without any lag.

In a nutshell... don't give me push my iPhone lags enough already.

[MacTel]

It will be awesome for Apple to really take-on Exchange. For SOHOs a Snow Leopard server that could host their email and push to iPhones, Blackberries, etc would be ideal and inexpensive since they wouldn't have to deal with CALs as they grow.

Mobile email is king and Exchange and RIM have that down pretty good. Hopefully Apple can pull this off right the first time.

[JavaCowboy]

What about support for syncing notes and tasks (todos), as well as contacts,calendar, and email?

[Adjei]

Originally Posted by bbwi

Yeah, for the love of god why doesn't Apple just license ActiveSync? For that matter, why don't they scrap MobileMe all together and just partner with Google. I use MobileMe now but do not foresee any reason to continue paying $100 a year as soon as Gmail offers push email.

IMHO, Google is MUCH better, in every aspect, at delivering web services than Apple and there is no evidence so suggest that would change in the future.

Maybe it has something to do with them being a web company.

[Adjei]

Originally Posted by Daniel0418

I agree. I never see the the badge update until I go into the app store to check myself. Or sometimes when I sync to iTunes it will show up. That is not push at all. And in this article when it references the Push notification of RIM and Microsoft lets not even go there yet please. First of all Push should have been out 2 years ago when the iPhone came out. The phone is getting old and it is too slow to do things as is. Push notification is far too late for the iPhone now. I am ready to toss my 3G Lag iPhone and get something new that can update freely without lag. AKA the Palm Pre. Something that can truly multi task. And before anybody says the iPhone will out perform any phone at all... How come it lags when I text message. How come it lags in google maps? How come it lags switching from contacts to recents within the phone app. This phone is too slow Push notifications now will only make it work. Please don't pretend this is a business phone. No Business has time to deal with this slow in affective micro computing these days. Maybe the Windows mobile phone isn't pretty to look and and maybe it doesn't have fun games. It gets the job done.... If you guys want to see a noticable difference in quality and crap compare the iPhone to the Black Berry bold.... the bold is FAST. Lag free. You can email, copy/paste and text as well as push notifications all without any lag.

Windows Mobile is laggy as hell.

[JeffDM]

Originally Posted by pmjoe

That's my whole point. The phone is never really sleeping.

It's not quite true. While the *whole* device might not be sleeping, wake-on-interrupt type hardware systems allow hardware designers to make a device that is sleeping except for very specific portions of the circuit, while the rest of the circuit / device is in sleep mode. The device that's "listening" basically pokes the rest of the system awake only if it's needed. A polling system would not allow as much of the device to sleep.

[ectomort]

Push between the web and iPhone, and from the desktop to the cloud worked at launch.
Mac OS 10.5.6 enabled push from the cloud to the OS X desktop.
MobileMe for Windows 1.3 enables push from the cloud to Windows.

There is no need to wait for Snow Leopard to get end-to-end push for MobileMe mail, contacts, calendars, and bookmarks.

To enable push, go to MobileMe system preferences and make sure the popup shows "Synchronize with MobileMe automatically"

[schafdog]

Could somebody tell which protocol is used to implement the push technology?

It must at telecommunication level (GSM, 3G and more) , since the IP layer must be dormant when the phone is sleeping.

The comparison with the IM protocols in the article is not that good, because the the IM client has an active connection with the server, which is used for the push.

[shadow]

Originally Posted by Virgil-TB2

I'd just like to point out that this description of how email is currently working on the iPhone above is really overly "rosy" in that it makes it seem like it all works fine when clearly it doesn't.

...

For instance if the iPhone is turned off on your desktop and your local mail client is open on the desktop computer, the iPhone will have acquired the new email notifications as your mail is dealt with on the desktop computer during the day, but only by turning on the iPhone and starting the mobile mail client will it actually update your mail or fetch mail that hasn't been read. It also does not sync email in folders until you actually access that folder, it just focusses on the inbox so as to make it seem like your mail is all being synced. Worse, depending on your settings one often ends up with multiple copies of various inboxes outboxes etc. on your laptop, your desktop, your iPhone and your web client as well as copies of the copies. There is no way to get rid of them save manual deletion or manual resetting of your clients and mail settings.

If you TURN THE PHONE OFF there is no way it will get updates. May be you mean turning the display off? Do you have your push settings set properly on the computer and on the phone? Take a look at the advanced setting in the Fetch New Data on your phone.

As far as my sync experience is considered, I find the article pretty accurate. I have 2 IMAP and 1 exchange account on the phone and have no problem with the folder contents and marking the messages as read. If I open a mail application on my computer and read the new mail from the phone, I can see the mail updating the read status within seconds.

The folders, other than the inbox, are not constantly updated for purpose. This is a feature, not a bug. Most people rarely need to browse Sent Items, let alone deleted items. I would prefer to save battery life and 3G data transfer and not have these folders always synchronized.

[bavlondon2]

I hope so.

[gopi]

Originally Posted by schafdog

Could somebody tell which protocol is used to implement the push technology?

It must at telecommunication level (GSM, 3G and more) , since the IP layer must be dormant when the phone is sleeping.

The comparison with the IM protocols in the article is not that good, because the the IM client has an active connection with the server, which is used for the push.

The iPhone doesn't sleep. The OS is always running. When there's nothing in the main event loop to run, the CPU goes off for a few milliseconds at a time.

I haven't instrumented an iPhone to measure, but with most similar systems: The baseband informs the main CPU whenever the cellular network sends it data. "Data" can be an incoming phone call, an incoming SMS, *or* an incoming IP packet.

In other words: incoming IP packets go straight to the OS, regardless of whether the system is fully operational, display off, or even asleep. You don't need to send continual packets to keep a link open. Once of my WinCE toys would actually fully wake up from sleep if you sent data over a TCP link.

TCP or UDP would be fine protocols to use for a push system with an architecture like the iPhone's. There wouldn't be additional overhead in terms of power usage.

[winterspan]

Originally Posted by pmjoe

That's my whole point. The phone is never really sleeping. It's still polling for messages. Messages still get queued. Now, you can correctly argue that this protocol is much lighter-weight and uses less radio time and power than setting up an IP connection and connecting to a mail server, but there's no magic "push" service that's saving battery by pushing out updates "immediately and only when necessary".

Originally Posted by bbwi

No messages are queued with push. As soon as they hit your inbox they're pushed to your device (unless your device is physically turned off, then yes, they'd be queued). If there are no messages then nothing is pushed. In a pull method, you need to schedule your phone to check in intervals. If there are messages they will get queued until your phone wakes up and checks. If there are no messages then your phone STILL wakes up and checks. This is where the battery savings come in. When your device is checking for messages even when there are none.

I understand what PMJoe is talking about, and it always confused me as well. People keep talking about the client device not having to poll the server to get a new message, as it simply gets "pushed" to the phone. Well how the hell can the server "push" email notifications (or any other data)to the phone if the phone's TCP/IP data connection is not active??

The only way I can imagine this happening would be if AT&T (or whoever) itself had equipment that sent notifications through the minimal "heartbeat" signal that lets your phone and the cell tower communicate.. Is that what the Blackberry Server does? If so, then the cell carrier has to install special blackberry push equipment right?

Also, How does ActiveSync compare to this? If the Push email on ActiveSync/MobileMe doesn't use the special cell->tower signal, then it has to be using standard TCP/IP connections, and how is that any different than polling??

Can someone with a technical understanding of this please comment!

[gopi]

Originally Posted by winterspan

I understand what PMJoe is talking about, and it always confused me as well. People keep talking about the client device not having to poll the server to get a new message, as it simply gets "pushed" to the phone. Well how the hell can the server "push" email notifications (or any other data)to the phone if the phone's TCP/IP data connection is not active??

Ahh, well, what do you mean by "active"?

Inside an operating system, it costs nothing more than a tiny bit of memory to have an "open" TCP link. The CPU doesn't have to do anything until a packet actually comes in. It's really just a pathway, knowing which app is supposed to get the packet. If the app is written properly, it will use *zero* CPU until something happens.

That's all well and good, but the packet needs to get to the CPU somehow. That means you need to have the radio on, and in the right state.

The radio is already on, and already informing the cellular system where it is.

When you are sending IP packets to a cellphone, you send them to an IP address like any other. You don't do any magic to tell the cellular system where to send them.

So:

You start out with a live GSM network link. Your baseband is up and running, registered on the AT&T network. But you can't do data. The iPhone OS tells the baseband, "Please get me an IP address."

Baseband talks to the GSM network, gets an IP address, gives it to the iPhone OS.

Now IP packets can be passed over the link.

Once we are in this state, the cost to *remain* in this state is zero. AT&T knows where the phone is. iPhone knows its IP address. AT&T IP network knows that this particular IP address goes to this particular cell tower which then sends it to your phone.

In the case of the iPhone, which never actually *sleeps*, but rather shuts off the bits it doesn't need, it can get a new IP packet from the baseband whenever one comes in. Other phones that do sleep can get woken up whenever the baseband has a message.

iPhone logs in via IP to the push system, proves that it's my iPhone. Then it just sits there. Push system knows the IP address to send my messages to. No further traffic is needed at the iPhone OS layer.

The only way I can imagine this happening would be if AT&T (or whoever) itself had equipment that sent notifications through the minimal "heartbeat" signal that lets your phone and the cell tower communicate.. Is that what the Blackberry Server does? If so, then the cell carrier has to install special blackberry push equipment right?

I don't know much about the implementation of Blackberry. They may also do different things with different models. I suspect that they send SMS or SMS-like messages. The carrier can do that quite easily if you're a big customer. It also ensures that you need a special data plan. The iPhone can do push with Yahoo, MobileMe and ActiveSync without the carrier being involved.

Also, How does ActiveSync compare to this? If the Push email on ActiveSync/MobileMe doesn't use the special cell->tower signal, then it has to be using standard TCP/IP connections, and how is that any different than polling??

Can someone with a technical understanding of this please comment!

I'm pretty sure that ActiveSync is a pure IP based system. I've never seen any carrier-specific requirements for ActiveSync, There's no single, unified open standard for sending SMS messages to a carrier. Without carrier-specific agreements and integration into their system, you're gonna be IP-only.

I hope this makes sense. My personal background is primarily in the IP domain. I've worked with a lot of cellphone systems, but I've never actually built a GSM radio, or directly integrated my stuff with a carrier. If somebody here does know about the overhead of keeping a PDP context activated on a UMTS network, and there's more to it than I am aware of, please correct me!