私は現在、サーバーと web/iPhone/Blackberry クライアントで Node.js を使用して単純なクロス プラットフォーム アプリを作成しています。帯域幅と遅延の要件は、IRC の「パーティー ゲーム」やチャット システムで見られるものと似ています。私は、HTTP ロング ポーリングを使用して Web クライアントを開発しました (双方向で JSON を使用します)。
iPhone/blackberry の場合、組み込みの HTTP ライブラリを使用して現在の実装と通信するか、サーバーにソケット リスナーを記述してソケットを使用して通信することができます。そうすることに何か利点はありますか？ブラウザー以外の HTTP クライアントが推奨されないように見えるのはなぜですか?
ネットワーク スタックの技術的な詳細について十分に知らないため、iPhone と話すことはできませんが、BlackBerry の場合、ブラウザーからの HTTP 要求は、一般に、アプリから開始された要求とは異なる方法で処理されます。ソリューションとしての BlackBerry は、デバイス側の TCP/HTTP スタックだけでなく、BlackBerry サービス (企業であるかどうかに応じて) でホストされているモバイル データ サービス (BES/MDS) を備えた BlackBerry Enterprise Server で構成されます。企業ネットワーク、またはモバイル ブラウザーからのすべての接続をプロキシする Research In Motion がホストする BlackBerry Internet Services (BIS) サーバー。これらのサーバーは、モバイル デバイス (画像など) でコンテンツをより消費しやすくするために、Cookie、認証、およびコンテンツ トランスコーディングの一部の側面を処理するなど、多くのことを行うことができます。
とにかく、これは、通常の TCP/HTTP 接続に期待される多くの機能が実際にはデバイスの外で発生することを意味し、キャリア、企業、または RIM によって制御される可能性があります。必要最小限のソケットが異なるのは、中間にあるさまざまなサーバーが HTTP 接続についてできる限り多くの仮定を TCP ソケットについて行うことができないため、HTTP 要求をいじることができないためです。多くの BlackBerry アプリは、実際にはソケット レイヤーの上に独自の HTTP クライアントを作成することになります。そのため、HTTP ロング ポール (Comet?) のようなことを行う必要がある場合は、必ずソケット接続の上にそれを記述してください。組み込みの HTTP 接続ではありません。