現在、Windows Azure でサーバー コンポーネントを実行する iOS 用のアプリケーション (MonoTouch を使用) を設計しています。アプリケーションは基本的に、ユーザーがクライアント内でメッセージを生成し、サーバーに送信するチャット タイプのアプリケーションです。サーバーは、ユーザーがメッセージを送信している可能性のある他のクライアントに (実行可能な限り迅速に) それらのメッセージを転送する必要があります。に。
私の質問は、クライアントがサーバーから「プッシュ」メッセージを受信する必要がある、このようなアプリケーションを設計するための推奨される方法はありますか?
いくつかのオプションを検討しましたが、フィードバックをいただければ幸いです。
最初のオプションは、Apple のプッシュ通知サービス (APNs) を使用することです。これには 2 つの懸念があります。1 つ目は、クライアントがオンラインのときにのみメッセージを受信する必要があることです (APN は、アプリが閉じているときにもメッセージを送信しますが、これは必要ありません)。第二に、大量のメッセージが送られる可能性があるが、Apple はおそらく (完全に公平に) 不満を抱くだろう。
私が検討した 2 番目のオプションは、Web サービス (WCF ベース) を使用し、クライアントがこのサービスを (たとえば) 2 ～ 3 秒ごとに呼び出すようにすることです。これは、許容できる最大遅延です。ただし、これには潜在的に不必要なネットワーク トラフィックが大量に発生するように思われます (「何かありますか?」、「いいえ」、吐き気を繰り返す)。
3 番目のオプションは、クライアントとサーバー間の永続的な Web サービス接続を維持することです。クライアント アプリが起動すると、バックグラウンド スレッドで Web サービス メソッドが呼び出されます。サーバーは (何も返さないことで) 接続を開いたままにし、メッセージが届いた場合はすぐに返します。この接続は、たとえば 2 分後にタイムアウトになる可能性があり、その時点で再確立されます。これは私が望むことをしているように見えますが、繰り返しますが、サーバーに対して多くの接続がいつでも開いているのではないかと心配しています。これにより、サーバー リソースが不必要に必要になる可能性があります。
4 番目のオプションは、TCP (または UDP ですが、私が見つけた限りでは、Windows Azure はこれをサポートしていません) を介した永続的な接続を使用することです。これは良いオプションのように思えますが、サーバーの使用量に関してはやり過ぎかもしれません.
5 番目のオプションは、クライアントにミニ Web サーバーなどを実行させるなどして、何らかの方法でサーバーからクライアントにメッセージを直接プッシュすることです。ただし、アプリは 3G および WiFi ネットワークで実行されるため (私の制御を超えて)、受信ポートがこの種のことのために開かれるとは思いません。
誰かが他の提案を持っている場合、または上記のオプションのいずれかが良い考えであると考えている場合 (または、この種の問題に取り組む標準的な方法である場合)、私はそれについて聞くことに非常に興味があります.
前もって感謝します、
ジョン