Mobile Application - Amazon Server and XMPP

IOS Mobile Chat Application is in the final stages of Development. We are almost completed but need to integrate the server and build a few custom OpenFire plugins to enable Push Notifications for 3rd Party Chat services and to allow for our Chat service to chat directly with other Jabber based platforms - ex - Gtalk. Assumptions: 1. The iOS device maintains a single XMPP connection to a cluster of Transfire servers running OpenFire. 2. All device communication is via the XMPP server which performs the translation on incoming and outgoing messages. 3. The OpenFire server maintains multiple gateways with both native (XMPP) and foreign (non-XMPP) messaging services. 4. The iOS device properly closes the XMPP connection when the application is placed in the background. 5. The OpenFire server is capable of sending APNS messages (Apple Push Notification Service) when the iOS application is not the foreground application so that the user currently receives timely notification of Transfire originated messages at all times. Problem: How to achieve timely of non-Transfire originated messages. This is actually several related cases, one of which should already handled: 1. Non-Transfire originated messages sent to an Transfire/XMPP node. For instance, a google talk user sends a message to . These should already be handled by the existing mechanisms. 2. Non-Transfire originated messages sent to a foreign service such as talk, that need to be translated and read by the user. This is the current case of interest. Enabling Push Notifications for 3rd party Chat services such as Gtalk, Yahoo, Facebook, MSN, AIM, etc.. Also, need to allow for Jabber platforms to chat from my TrasnsFire Chat service to any of the 3rd Party Chat services. The problem arises because when the iOS device closes the connection to the Transfire server, the Transfire server in turn closes it's connection with the foreign server, in essence relaying an "offline" state. Since these foreign servers have no means of pushing messages to the Transfire server (this is the main difference between case 1 and case 2) there is no timely notification of the message arrival. *Persistent Foreign Service Connection: In this solution, the device still closes out the connection with the Transfire server, but the Transfire server maintains persistent connections with the foreign services so that messages are received into the Transfire system in a timely fashion. The biggest problem here is that the extreme number of connections required to maintain multiple open connections for every client, online and offline, will lead to extremely heavy server loading. The advantages are that messages are delivered in an extremely timely fashion and there is no significant difference in server loading between active and inactive device clients. In reality, there's actually slightly less server loading for this solution.