iPhone Push Notification Server tied to Snow Leopard Server

Posted:
in iPhone edited January 2014
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.
«13

Comments

  • Reply 1 of 41
    Er... this sounds like a non-story. Is PNS vaporware or not?
  • Reply 2 of 41
    pmjoepmjoe Posts: 565member
    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.
  • Reply 3 of 41
    noirdesirnoirdesir Posts: 1,027member
    Quote:
    Originally Posted by pmjoe View Post


    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?
  • Reply 4 of 41
    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.
  • Reply 5 of 41
    solipsismsolipsism Posts: 25,726member
    Quote:
    Originally Posted by pmjoe View Post


    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.
  • Reply 6 of 41
    Quote:
    Originally Posted by pmjoe View Post


    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.



    When your iPhone is "asleep" don't you receive SMS text messages. There is no difference.



    Plus the fact that RIM has been doing it for years.
  • Reply 7 of 41
    irelandireland Posts: 17,798member
    Apple with "push" this idea



    Like the "push" that rip-off service (I use) called Mobile Moi
  • Reply 8 of 41
    Quote:
    Originally Posted by AppleInsider View Post


    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.
  • Reply 9 of 41
    pmjoepmjoe Posts: 565member
    Quote:
    Originally Posted by noirdesir View Post


    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".
  • Reply 10 of 41
    bbwibbwi Posts: 812member
    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.
  • Reply 11 of 41
    Quote:
    Originally Posted by pmjoe View Post


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



    That wasn't your original point....
  • Reply 12 of 41
    bbwibbwi Posts: 812member
    Quote:
    Originally Posted by pmjoe View Post


    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.
  • Reply 13 of 41
    Quote:
    Originally Posted by steviet02 View Post


    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.
  • Reply 14 of 41
    wigginwiggin Posts: 2,265member
    Quote:
    Originally Posted by pmjoe View Post


    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.
  • Reply 15 of 41
    nagrommenagromme Posts: 2,834member
    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.



    Quote:

    ... 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.
  • Reply 16 of 41
    Quote:
    Originally Posted by bbwi View Post


    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.
  • Reply 17 of 41
    Quote:
    Originally Posted by bbwi View Post


    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.
  • Reply 18 of 41
    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.
  • Reply 19 of 41
    Quote:
    Originally Posted by mn_hawk View Post


    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.
  • Reply 20 of 41
    Quote:
    Originally Posted by bbwi View Post


    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.
Sign In or Register to comment.