Objective-C で記述され、Mac で実行されている「サーバー側」アプリケーションと、iPhone で実行されているクライアント アプリケーションとの間である種の双方向通信を実装するための最良の方法についてのアドバイスを探しています。
簡単に言うと、既存のライブラリをクライアント サーバー環境で使用できるように変更しています。ライブラリ (サーバー上で実行される) は、基本的に、定期的な結果を提供する検索エンジンであり、さらに後日、これらの結果の更新を提供できます。したがって、理想的な世界では、仮想ネットワーク ソリューションで次のことを実現できます。
- サーバーでクエリを開始します。
- 結果が到着したら、サーバーが結果をクライアントに「プッシュ」するようにします。
- サーバーが個々の結果の更新をクライアントに「プッシュ」するようにします。
このクライアントを別の Mac で実行するように作成している場合は、サーバーが実際にリモートで実行されているという事実を隠すために分散オブジェクトを使用することを考えるかもしれませんが、DO は iPhone では使用できません。
より一般的なクライアント/サーバー アプリケーションを作成している場合は、おそらく HTTP を使用して、検索にある種の RESTful インターフェイスを提供することを検討するでしょうが、このソリューションは非同期更新には適しておらず、さらに私が提案しているものはうまく適合しません。 REST の「ステートレス」の原則: プロトコルをモデル化する必要があるため、検索リソースを「作成」し、後で状態を照会できるようにし、その更新をポーリングする必要があります。
誰かが行った 1 つの提案は、BLIPのようなものを利用して、クライアントとサーバー間の双方向パイプを提供し、サーバー側のリソース用に独自の「プロキシ」タイプのオブジェクトを実装することでした。さらに、サーバーが更新をそれらにプッシュできるようにアドレス指定可能でした。BLIP は双方向通信に必要な低レベルのメッセージング フレームワークを提供しますが、それでもいくつか疑問が残ります。
- サーバー上のオブジェクトの有効期間をどのように管理しますか? 検索オブジェクトを「作成」するメッセージ タイプを使用できますが、そのオブジェクトはいつ破棄する必要がありますか?
- これが iPhone でどの程度うまく機能するか: サーバーに常時接続している場合、バッテリーの消耗が早すぎますか? この質問は HTTP の世界にも当てはまります。ほとんどの非同期更新は、永続的な接続を必要とする COMET タイプのハックを使用して行われます。
したがって、今のところ、最善の方法が何であるかはまだ完全にはわかりません。多くの検索と読み取りを行ってきましたが、解決策はありません。すでにこの問題を解決した人がたくさんいると確信しているので、SO で質問しています。
iPhone と Objective-C のサーバー側アプリの間でリアルタイムの双方向ネットワークを実現するために、どのように取り組んできましたか?