17

どちらがより安定しているか教えてもらえますか? それぞれに長所と短所があることを知っています。しかし、どちらがhttpなどに適していますか?

以前のアプリケーションでは indy9 を使用していましたが、時々奇妙なエラーが発生するので満足できませんでした。

誰でもお勧めできますか?

4

8 に答える 8

16

多くのプロジェクトで Indy を使用しています。主に HTTP サーバーとプロキシとして 9 と 10 の両方を使用しました。プロジェクトには、非常に激しいトラフィックが発生することがあります (HTTP)。インディは決して私をがっかりさせませんでした。とても安定して動作します。

しかし、根底にある問題を見つけるために深く掘り下げなければならない「奇妙な」状況もいくつかありました。また、Indy が例外を通じて多くのことを処理する傾向があるのも好きではありません。一般的に、私は ICS コーディング スタイルの方が好きです。しかし、私はICSに行かせてください。

ICS はノンブロッキング ソケットを使用しますが、indy はブロッキングを使用します。ノンブロッキングは問題なく、一見優れているように見えますが、多くの状況でイライラすることがわかりました。問題は、コールバック関数が原因でコードの自然な流れが失われることです。これにより、手続き型のライブラリを作成することが難しくなります。さらに、すべてがメッセージによって処理される方法が好きではありません。私にとって、マルチスレッドと組み合わせると、すぐに面倒になります。そして最近ではマルチスレッドが主流です。

したがって、私は ICS のコーディング スタイルとコードの品質が好きですが、Indy の使いやすさとブロック モードが好きです。どちらを好むかはあなた次第ですが、どちらのライブラリも成熟して安定しています。

これらは私の 2 セントです。

于 2010-04-18T19:40:55.660 に答える
7

また、Indy と ICS の両方を使用しています。

ほとんどの場合、私は Indy を好みます。これは、シーケンシャル タイプのプロトコルを実装するのが非常に簡単だからです (要求は独自のスレッドで実行されるため、接続に対して読み取り/書き込みを行うだけで、非常に簡単です)。Indy を使用するには、スレッド化と同期に関する確かな知識が必要です。Runner とは異なり、Indy が例外を使用して「例外的な」ものを処理する方法が好きです。これにより、プロトコルの通常の流れに集中できるからです (リソースの割り当てを確実に解除するために try-finally ブロックを使用します)。

また、Indy が単に失敗したアプリケーションでも ICS を使用しました。TCP/IP プロキシを実装するアプリケーションに ICS を使用しました。ICS の使用は、ノンブロッキングの性質のため、より簡単でした。私は何も知らない TCP/IP プロトコルを「プロキシ」することができたので、バイトが一方の端から他方の端までどのように流れるかはわかりません。Indy では、イーサの読み取りまたは書き込みを行っているため、両方を同時に行うことはできないため、Indy はそのシナリオで失敗しました。ICS を使用してシーケンシャル タイプのプロトコルを実装するのは少し面倒です。基本的には、ステート マシン ロジックを使用し、プロトコルを少しずつ停止し、プロトコルのどこにいるかを把握できるようにフラグを設定しておく必要があります。大きな利点: ICS の作成者である François Piette は活発で、多くのフォーラムやメーリング リストで非常に役に立ち、ICS に関連することなら何でもすぐに助けてくれます。

私にとって、TCP/IP で何かをする必要がある場合、決定パスは非常に単純です。それは Indy で実行できますか? それからインディです。Indyで出来ないならICSで出来る!

于 2010-04-19T06:58:41.583 に答える
6

TCP、HTTP、FTP に Indy 9 と 10 を使用しましたが、問題はほとんどありません。ICSも良い選択です。ノンブロッキングなので、使い方が変わります。

私はそれを使用していませんが、ブロックしているSynapseについて良いことを聞いたことがあります。

于 2010-04-18T19:24:33.850 に答える
5

Indy10 IdTCPClient をテストして、リモート サーバーからビデオ ストリームを受信します。問題ありません。しかし、ストリームを受信して​​いるときに、サーバーにデータを送信すると同時に、受信したストリームデータのデータバイトが失われ始めました。スニファ ツールを使用してこの問題を追跡したところ、IdTCPClient がストリームの受信でいくつかのバイトを失ったことを確認しました。

そこで、Indy9.018 をテストすると、同じ問題が VS で数回発生しました。インディ10。

于 2012-12-12T02:22:30.217 に答える
4

インディは常にベータ段階にあることを忘れないでください。ナイトビルドで作業する必要がある場合があります。

于 2011-03-22T16:45:59.360 に答える
2

どちらが優れているかは、実際には特定のユースケースに依存しますが、http クライアントとしての indy には不満があり、ICS は、ランダムな癖がはるかに少なく、まさに私が必要としていたものになりました。

ただし、非ブロッキングであるため、単なる交換ではありません。

于 2010-04-18T19:27:18.343 に答える
2

私は Indy 9 を使用して、100 万人以上のユーザーに安定してリリースされた製品コードを提供していますが、奇妙なエラーは一度も発生していません。

于 2010-04-18T19:29:05.483 に答える
2

答えは、インターネットで何をしたいかによって異なります。Indy は、それがどのように機能するかを理解することに参加する準備ができていれば問題なく、非常に有能です。ICS は別の見方をしており、私はこれを多接続システムに効果的に使用してきました。しかし、基本的なタスクを実行したい日常的な「ファイルを取得するか、電子メールを送信する」タイプのものには、ほとんどの場合、コンポーネントを作成し、オプションを設定するだけで機能するClever Components Internet Suiteを使用します。このスイートは非常に包括的で、便利なアップデートを取得します。

于 2012-06-05T11:06:46.000 に答える