iOSチャットアプリケーションの設計、エンドユーザーへのメッセージの送信/リレー
デザインについて質問があります。具体的には、iOS用のチャットアプリケーション（iOSチャットアプリケーション）の構築を任されたとします。簡単にするために、一度に1人だけとチャットできるとしましょう（グループチャット機能はありません）。
では、電話Aから電話Bに直接エンドユーザーにメッセージを送信するにはどうすればよいでしょうか。
明らかに、いくつかのAPI呼び出しを持つWebサービス層があります。利用可能なAPI呼び出しの1つはstartChat()です。チャットを開始した後、メッセージを送信するときに、別の非同期呼び出しを行って、それをsendMessage()と呼び、メッセージとともに文字列を渡します。メッセージがWebサービス層に渡されると、メッセージはデータベースに格納されます。
ここが私が現在行き詰まっているところです。メッセージがWebサービスレイヤーに送信された後、どのようにしてエンドユーザーへのメッセージの送信/リレーを実現しますか？ Webサーバーがエンドユーザーにメッセージを送信して通知する必要があるか、または各クライアントがreceiveMessage()メソッドを定期的に呼び出し、サーバー側に情報がある場合は、その情報で応答できますか？
最後に、メッセージを送信しようとしているユーザーがオフラインである場合にどのように対処できますか？エンドユーザーが信号のあるエリアに戻ったときにパケットを確実に受信するにはどうすればよいですか？
他のユーザーがAPNSを提案していますが、後でアプリケーションをAndroidおよび/またはWindows Phoneに移植することを決定した場合、プラットフォームに縛られていると、これを達成するのが難しくなります。固有のプッシュAPI。このスタックオーバーフローの質問にリストされている3つのプラットフォームすべてでの使用に適したいくつかの代替案があります： https://stackoverflow.com/questions/9801720/Push-notifications-on-all-3 -platforms-Android-ios-windows-phone
このソリューションには、ある種のクライアントIDが含まれていると想定しています。次に、クライアントAがクライアントBのIDを使用してサーバーにメッセージを送信し、サーバーがメッセージを保存します（おそらく、メッセージが読み取られていないことを示すフラグ）。クライアントBが接続するたびに、未読のメッセージがあるかどうかをサーバーに尋ね、もしあれば、それらをポーリングします。
クライアントAがメッセージを送信している間にクライアントBが接続されている場合、サーバーはメッセージをクライアントBに直接配信する必要があります。
最高の幸運
私は似たようなことをしました。 iOS-（メッセージと受信者のIDを含むリクエストを送信）->サーバー---受信者にメッセージを送信-> iOS
ただし、最終的な配信には通知を使用しました。これは、サーバーがAPNSにリクエストを送信するユーザーが誰であるかを判別すると、サーバーにデバイスのトークンが格納されていることを意味します。
APNSは、これを行う最も明白な方法です。これは、中央サーバーが必要になることを意味します。また、期限切れのトークンをクリーンアップする必要があるため、メンテナンスが必要になることも意味します。 Appleは、証明書の作成に関しては登録されていますが、あまりストレスがありません。注意すべき点の1つは、文字数の制限が比較的低いことです。