NetCom7
1.0.0
可能な最速の通信。
これは、NetComパッケージのバージョン7.2です。このバージョンでは、NetComパッケージはマルチプラットフォームになりました！ Firemonkeyのすべてのプラットフォームの下にアプリをコンパイルできます！
このコンポーネントのセットは、あらゆる言語でのソケット通信の可能な限り最速の実装です。これは、TCP/IPソケットの非常に最適化されたコードです。接続ごとのスレッドの使用を忘れてください：このスイートを使用すると、好きなだけサーバーへの同時接続ができます。スレッドは要求ごとに使用され、接続ごとではなく、非常に高速なスレッドプールクラスで維持されます。
実装は、基本的なソケット通信を実装するTNCTCPSERVERとTNCTCPCLIENTから始まります。必要なのが標準（非常に高速な）ソケットコムを実装することだけであれば、tnctcpclientとtnctcpserverを使用できます。
TCP/IPソケットの上に、バッファを梱包および開梱できるように軽量プロトコルが実装されています（単純なTCP/IPはストリーミングであり、明確に定義されたバッファーの概念がありません）。この機能を実装するコンポーネントのセットは、TncServersourceとTncclientsourceです。これらのコンポーネントはどちらも、反対側でオンハンドルコマンドイベントをトリガーするexecCommand（ACMD、ADATA）を実装します（クライアントはサーバーにexecCommand、またはサーバーが任意のクライアントにexecCommandを実行できます）。 execCommandは、そのarequiresResultパラメーターを設定する方法に応じて、ブロッキングまたはノンブロッキング（ASYNC）をブロックすることができます。ブロッキング動作を使用している場合、コンポーネントはピアからの着信要求を処理します。たとえば、ClientOurceはサーバーへのexecCommandを待っている可能性がありますが、待っている間、サーバーからのexecCommandリクエストを提供できます。
Simple Senario：サーバー：
- You put a TncServerSource on your form.
If you want you can change the port it is listening to via the
Port property.
- You implement an OnHandleCommand event handler and,
depending on aCmd parameter (integer), you respond the result of
the command via setting the Result of the OnHandleCommand to
anything you like (TBytes). If an exception is raised while in
HandleCommand, it is trapped, packed, transfered accross to the
calling peer, and raised at the peer's issued ExecCommand.
This way exceptions can be handled as if they were raised locally.
- You set the Active property to true. Your server is ready.
クライアント：
- You put a TncClientSource on your form.
You can set Host and Port to whatever you want.
- You set Active property to true.
Your client is now connected to the server.
- You call ExecCommand (on your TncClientSource), with any
command number and data that you like. This will send your
command and data over to the server, call its OnHandleCommand,
pack the response, and return it as a result to your ExecCommand.
- ExecCommand is blocking (if aRequiresResult parameter is set to true),
but only for the current command issued.
The TncClientSource's OnHandleCommand still executes, so,
while waiting for a command to return, your client socket may be
processing requests from your server (a server can also
ExecCommand to a client).
- If you have forgotten to set Active to true and call ExecCommand,
the TncClientSource will first try to connect, so you can ommit
setting this property. It will also try to connect if it knows
it has been disconnected (and the Reconnect property is set to true).
この一連のコンポーネントは、比類のない速度を約束しますが、それは言葉だけではありません。
NetComvsindyデモを使用した簡単なタイミングテストでは、次の結果が得られます。
ベースユニットのncsockets.pasから始めて、実装にはスラックコードが搭載されていないことがわかります。インライン呼び出し条約は、適切と見なされていれば使用されています。非常にコア機能は、パフォーマンスのすべてのパフォーマンスを絞り出すために、大きなループのタイミングとアセンブリ検査を介してパフォーマンスを監視することにより、テストおよび最適化されています。
スピードゲインの最大の違いは、アーキテクチャによるものです。ほとんどの典型的なソケットとは異なり、
このソケットのセットは、接続ごとにスレッドをスポーンしたり使用したりしません。
これは、好きなだけライブ接続を持つことができることを意味し、パフォーマンスに違いはありません！スレッドプールは、リクエストを待つだけです。スレッドがリクエストまたは接続ごとに作成される場合、スレッドを作成することは非常に時間的に非常に重いため、速度は非常に苦しむでしょう。スレッドプールで1秒あたりのリクエスト数を処理できない場合、スレッドプールは最大定義されたサイズに成長し、それでも対処できない場合、クライアントはサーバーがリクエストを処理する準備ができたスレッドを取得するまで待機します。
接続の問題にも特に注意が払われています。たとえば、切断はすぐにピックアップされ、ラインが非常に悪い場合、切断がピックアップできない場合、実際のステータスを知ることができるKeep Aliveパケットによってこれに取り組みます。再接続プロパティとKeepaliveプロパティがあります。クライアントが切断されると、何らかの理由で、メインアプリケーションのパフォーマンスに影響を与えることなく、透過的に再接続しようとします。これにより、クライアントを接続することを心配する必要はありません。
これらのコンポーネントは、追加のライブラリを必要としないこれらのコンポーネントでも標準です。もちろん、必要に応じて独自の圧縮または暗号化を使用できますが、コンポーネントに設定できるプロパティだけを用意するのがかなり便利です。
この一連のコンポーネントは、それらに投げかけられたゴミデータを扱うこともできます。それらは、あらゆる種類の攻撃を見ることができる巨大な国全体のプロジェクトで使用およびテストされています。
プログラマーがこれらのコンポーネントを使用するために行わなければならない努力は、他のフレームワークと比較して最小限です。これらのコンポーネントの使用方法をよりよく理解するために、デモを参照してください。
Bill Anastasios Demosによって書かれました。 Daniel Mauric、Tommi Prami、Roland Bengtssonに、広範なテストと提案に感謝します。どうもありがとうございます！
vasdemos [at] yahoo [dot] co [dot] uk
** Delphiルール**
