サーバーとクライアントの両方を備えたObjective-Cアプリを構築しています。クライアントはサーバーに更新を送信でき、サーバーは接続されている各クライアントに更新を送信できる必要があります。私はこのシステムをどのように実装するのが最善かを考えてきましたが、あなたの提案を求めています。
現在、新しい更新が利用可能になると、サーバーはスレッドを使用して更新を各クライアントに順番に送信すると考えています。クライアントがタイムアウトした場合、それらは切断されます。私はネットワーキングの経験がほとんどないので、あなたの洞察を求めています。
このシステムはうまくいくと思いますか？もしそうなら、あなたは糸脱毛を行う方法について何か提案がありますか？あなたが私に指摘できるNSクラスはありますか？使えるキューが必要だと思います。
他に何か考えはありますか？
編集：私はクライアント数が最大で50かそこらをはるかに超えるとは思わない。
クライアントとサーバーの両方が OS X アプリであり、どちらも Cocoa フレームワークを使用して Objective-C で記述できる限り、Cocoa の分散オブジェクト(DO) テクノロジを検討することを強くお勧めします。ここでは、分散オブジェクトのチュートリアルを提供しようとはしません。なぜそれが役立つのかを説明するだけです...
DO は非同期ネットワークの詳細を処理します (すべてのクライアントの更新は単一のスレッドで発生する可能性があります)。さらに、リモート オブジェクトとの通信のセマンティクス (クライアントからサーバーへ、またはその逆。接続が確立されると DO は双方向) は、インプロセス通信と非常に似ています。つまり、リモート オブジェクト (実際NSDistantObjectには、接続の反対側のオブジェクトへのプロキシとして機能するオブジェクト) への参照を取得すると、クライアント コードは、あたかもローカルであるかのように、リモート オブジェクトにメッセージを送信できます。
[remoteServer update:client];
クライアントから、または
[[remoteClientList objectAtIndex:i] update:server];
サーバーから。分散オブジェクト プログラミング ガイドを読んだ後、接続の設定と remoteServer または remoteClient 参照の取得の詳細を説明します。
DO を使用することの欠点は、Cocoa に縛られていることです。分散オブジェクトを使用して通信する Cocoa 以外のクライアントまたはサーバーを作成するのは非常に困難です。Cocoa 以外のクライアントまたはサーバーの実装が必要になる可能性がある場合は、DO を使用しないでください。この場合、多くのクロスプラットフォームと言語サポートを備えたシンプルなものをお勧めします. HTTP 経由の REST スタイルの API は適切なオプションです。HTTP リクエストとレスポンスの実装方法については、Cocoa URL Loading Systemのドキュメントを参照してください。Cocoa コードに HTTP サーバーを実装する方法については、Apple のCocoaHTTPServerサンプル コードまたは同名の code.google.com プロジェクトを参照してください。
最後のオプションとして、独自のネットワーク プロトコルを実装する場合は、Cocoa Stream Programming Guideを参照してください。NSStreamのサブクラスを使用すると、ネットワーク ソケットをリッスンし、そのソケットとの間で非同期の読み取り/書き込みを処理できます。多くの人がこの目的でAsyncSocketを使用しています。(下位レベルの) CFStream と CFSocket をラップし、ネットワーク コードの記述をいくらか容易にします。
サーバーがクライアントに更新を送信する場合、1つのスレッドですべてを処理し、非同期ソケットを使用する方がおそらく簡単です。もちろん、これはあなたが対処しなければならなかったクライアントの数にも依存します。
Apple 開発者側には、いくつかのネットワーキングの例があります。チェックアウトすることをお勧めするのは、ダウンロードできる URLCache です。この例の Apple のドキュメントからの引用:
URLCache は、Web からリソースをダウンロードし、それをアプリケーションのデータ ディレクトリに保存し、リソースのローカル コピーを使用する方法を示す iPhone アプリケーションのサンプルです。URLCache は、いくつかのキャッシュ ポリシーを実装する方法も示しています。
興味深いオプションは、Jens Alfkeによる BLIPプロトコルです。これは、メッセージ指向のネットワーク システムであるBEEPの機能を取り除いたバージョンのようなものです。基本的に、双方向メッセージ パイプの低レベルの抽象化を提供するため、その上に通信プロトコルを重ねることに集中できます。
Marcus Zarra (CoreData バイブルの著者) や Flying Meat ソフトウェアの Gus Muellerなどの価値ある信奉者がいます。
システムをどのように設計する予定かはわかりませんが、通常、サーバーはクライアントに接続できません。クライアントが通信を開始する必要があります。50 クライアントという低い制限では、Web サーバー/クライアントのような実装を検討していない可能性があります...
つまり、クライアントとサーバーの通信を処理するには、基本的に次の 2 つの方法があります。 1. クライアントはサーバーを定期的にポーリングして更新を取得します。理解してください）プロトコル。