Tcpclient/Tcplistnerクラスはソケットクラスよりも高速です

Question

私のアプリケーションは.netで書かれており、Windowsサーバ上で動作します。 TCP/IPを介してリモートサーバーに接続し、引き続きリスニングを行います。接続の開始時にはログインメッセージであるメッセージを1つだけ送信し、その後は決してメッセージを送信せずにサーバーからリッスンします。そのストリームソケットとパケットはかなり頻繁にやってくるので、60バイトから200バイトにおよぶサイズが約6000パケットになります。これまではソケットクラスを使用していて、リモートサーバーに接続しています。ログイン要求を送信した後、私は継続的にストリームを受信し始めます。私はBeginReceive、socketflagsなしを使用しているフローを受信する。そしてすべての初心者の後で、それは仕事を繰り返す。より速い方法でストリームを受け取る他の方法はありますか？私のアプリケーションはリアルタイムかつ非常に非常にタイムクリティカルです。 1マイクロセカンドでも問題ありません。誰でも提案できますか？

Answer 1

TcpClientは、単にのSocketとNetworkStreamの上にあるラッパーです。それは単にを実行しません - それは単に別の（より便利な）APIです。さらに、Joachimが指摘しているように、これは実際のボトルネックになる可能性は低いです。

あなたが試すかもしれないいくつかのアイデア：

• をNetworkStream APIを使用している場合、バッファされたデータがある場合に指示する、DataAvailableをご確認ください。お使いのコンピュータを最も可能性が高い - がある場合、その処理メッセージ対バッファリングメッセージの手順を分離非同期 *（BeginRead）
• にその時点スイッチで、偽のDataAvailableまで（数Read経由）同期を処理してみてください複数のコアがあり、別々のリードループ/プロセスキューがスループットを増加させる可能性があります。あなたも並列処理スレッドを検討することもでき、それは

リモートサーバを扱う、「でも、1マイクロ秒の事項は、」単に実行不可能である、より複雑です。そのレベルでは、おそらくの使用（refを経由して）を参照して、おそらくclassを使用することと違って、フラットスワップで変更することはできません。オブジェクトのプールなど、非常にトリッキーです。