「チャット機能」、基本的には人々が互いにチャットする機能を含むアプリケーションのアイデアがあります。サーバーを介してメッセージを送信すると時間がかかるため (さらに、新しいメッセージがある場合にサーバーを毎秒チェックする必要があるのはかなり悪いことです)、サーバーを介する代わりにソケットを使用してピアツーピアチャット機能を実現したいと考えています。
私の2つの質問：
1) ソケットプログラミングはチャットプログラムを開発する最適な方法ですか? プッシュ通知サービスがあるのは知っていますが、チャットプログラムとしてはあまり使いこなせないと思います。5,000 人がチャットし、毎秒サーバーをポーリングしなければならないことを想像すると、サーバーを経由するのはちょっと悪いように思えます。
2) Apple は、ソケットを使用するピア ツー ピア チャット プログラムを含むアプリを承認する際に問題を抱えていますか?
ありがとうございました。
ソケットは確かに適切です。ただし、P2P アプローチよりもクライアント/サーバー アプローチの方が適しています。
非常によく知られているインスタント メッセージング サービスに長年携わってきた私は、サーバーが遅くない限り、サーバーを経由することは決して遅くないと断言できます。
クライアント/サーバーには多くの利点があります。つまり、NAT やファイアウォールなどの問題によって直接ソケット接続が困難で信頼性が低くなる P2P 接続ほど難しくありません。さらに、クライアントが IP アドレスを交換するには、とにかくメッセージング サービスが必要です。
クライアントまたはサーバーが「ポーリング」する必要があるというあなたの仮定は、スケーラブルなシステムがどのように機能するかではありません。永続的な TCP ソケットを使用し、現在存在する利用可能な非同期メソッドのいずれかを使用してソケット サービスをスケールアップすることを検討する必要があります。select()、poll()、Linux の epoll、および Windows の IO Completion Ports はすべて、定期的なポーリングを行わずに数千のソケットを同時に接続するための手法です。
私の提案 - XMPP/Jabber サーバーを展開するだけです。ほとんどの実装は、数千のクライアントにうまくスケールアップします。そうすると、チャット プログラムは単なる XMPP クライアント ソケットになります。一部の Jabber サーバーは、ユーザーの唯一のアクセスが http または http プロキシ サーバー経由である場合に備えて、HTTP 接続をサポートしています。私はしばらく前にOpenfireをいじってみましたが、それなりに感銘を受けました。
iOS にソケットがあり、Apple によって許可されていることは確かです。私は、iOS 製品の開発に携わったことのある人からの情報だけを知っています。プッシュ通知サービスは、何かする必要があることを知らせる通知以外には使用しないでください。
お役に立てれば。