標準の J2ME で最初に実装された Blackberry 用のアプリを作成しています。ネットワーク接続は、Connector.open("socket://...:80/...")
代わりに使用して行われましたhttp://
さて、両方の方法を使用して接続を実装しましたが、ソケット方法の方が応答性が高い場合もあれば、まったく機能しない場合もあります。両者の間に大きな違いはありますか?私が達成しようとしているほとんどのことは、スムーズな進行状況バーを取得するための接続からの応答性です。
標準の J2ME で最初に実装された Blackberry 用のアプリを作成しています。ネットワーク接続は、Connector.open("socket://...:80/...")
代わりに使用して行われましたhttp://
さて、両方の方法を使用して接続を実装しましたが、ソケット方法の方が応答性が高い場合もあれば、まったく機能しない場合もあります。両者の間に大きな違いはありますか?私が達成しようとしているほとんどのことは、スムーズな進行状況バーを取得するための接続からの応答性です。
Blackberryの実装は、ターゲットサーバーに接続するためのオプションよりも多くのオプションを提供しhttp
ます。もちろん、すべてのHTTPプロトコルを実装します。私はそれらをベンチマークしていませんが、特にポート80でリッスンしているものがHTTPサーバーではない場合(プロトコルオーバーヘッドなし) 、場合によっては直接 経由の方が速いことはある程度意味がありますhttps
socket
TCP
socket
私は過去にさまざまなネットワークプロバイダーで問題を抱えていました。一部のプロバイダーはdeviceside=true
他deviceside=false
のプロバイダーを必要としており、そのネットワークの最初のサポートコールが来るまで実際に知る方法はありませんでした。
主に私が達成しようとしているのは、スムーズなプログレスバーを取得するための接続からの応答性です。
私の言うことを許してください。しかし、「スムーズなプログレスバー」は「ユリを金メッキする」ことです。見たり持ったりするのは良いことですが、アプリケーションの機能、信頼性、堅牢性にとって重要ではありません。より堅牢でコードサイズを削減するものを使用してください-http
この場合は可能性があります。
どちらもネットワーク上で動作するため、スムーズな進行状況バーを保証できるとは思いません. その人に 1 つの場所にとどまることを思い出させると、その可能性が高くなる可能性があります。
ソケット接続では、HTTP 接続よりもオーバーヘッドが少なくなります。実際、HTTP 接続はソケット接続を介して実行されます。ソケット接続のオーバーヘッドの削減を利用して応答性を向上させることができますが、HTTP の場合よりも多くの作業が必要になる可能性があります。API はより低レベルであるため、コーディングはより複雑になります。
BlackBerry でのソケットと HTTP 接続の違いの 1 つは、BES および BIS 接続の場合、HTTP 接続が HTTP プロキシ経由で透過的にルーティングされる可能性があることです。
理論的にはソケットの方が高速ですが、独自のプロトコルをローリングするオーバーヘッドを管理する責任があります (複雑さによって異なります)。ソケットはより軽量ですが、HTTP とそれに付随するすべての機能により、頭痛が大幅に軽減されることがわかりました。