これはまだ別のTcpClient対ソケットではありません。
TcpClientは、開発を容易にするためのSocketクラスのラッパーであり、基盤となるSocketも公開します。
まだ ...
TcpClientクラスのMSDNライブラリページで、次のコメントを読むことができます。
TcpClientクラスは、同期ブロッキングモードでネットワークを介してストリームデータを接続、送信、および受信するための簡単なメソッドを提供します。
そして、Socketクラスの場合:
Socketクラスを使用すると、ProtocolType列挙にリストされている通信プロトコルのいずれかを使用して、同期データ転送と非同期データ転送の両方を実行できます。
TcpCientのみを介して一部のデータを非同期で送受信するには、GetStreamを呼び出して、TAPパターンに従ってReadAsyncメソッドとWriteAsyncメソッドを呼び出すことにより、データを非同期で読み取り/書き込みできる基になるNetworkStreamを取得する必要があります。 (潜在的にasync / awaitコンストラクトを使用します)。
ソケットを介して非同期でデータを送受信するには(私は専門家ではありませんが、正しく理解できたと思います)、BeginRead / EndRead BeginWrite / EndWrite(または単にReadAsyncまたはWriteAsync .. TAPパターンを公開しない-つまり、タスクを返さない..混乱する)。
まず、.NET 4.5のSocketクラスがTAPパターンを実装しない理由、つまり、ReadAsyncとWriteAsyncがタスクを返す理由(後方互換性を維持するために別の方法で呼び出された場合のイベント)はありますか?
とにかく、APMモデルのメソッドペアからTaskメソッドを作成するのは簡単なので、この非同期メソッド(読み取り用)をReadAsyncTAP(タスクを返す)と呼んだとしましょう。
Ok ?async Task<Byte[]> ReadNbBytes(int nbBytes)
ここで、コードから呼び出してネットワークから特定のバイト数を非同期的に読み取るクライアントメソッドをコーディングするとします。
TcpClientのみに基づくこのメソッドの実装は、GetStreamを呼び出すことによってNetworkStreamを取得し、バッファーがいっぱいになるまでReadAsync呼び出しを待機する非同期ループを含みます。
ソケットに基づくこのメソッドの実装には、バッファーがいっぱいになるまでReadAsyncTAPで待機する非同期ループが含まれます。
結局のところ、クライアントコードの観点からは、違いはないと思います。どちらの場合も、への呼び出しはawait ReadNbBytes
すぐに「戻ります」。しかし、それは舞台裏で違いを生むと思います... TcpClientの場合、NetworkStreamに依存しているため、ソケットを直接使用する場合と比較して、読み取りはどの時点でもブロックされるかどうかはわかりませんか?そうでない場合、同期ブロッキングモードについて話しているときにTcpClientに対して行われたコメントは間違っていますか?
誰かが明確にすることができれば大いに感謝されるでしょう!
ありがとう。