0

.NET ソケットの実装に関していくつかのポイントがあるので、それらを順番に述べます。

  1. 私の理解では、Socket のインスタンスは内部クラスの実装に変更可能なサイズのバッファーがあり、実際にはバイトのキューであり、アプリケーションで宣言および定義するアプリケーション バッファーとも異なります。
  2. streamsocket type:および protocol type:を使用する同期モードで、(プロセスをブロックしている)tcpメソッドを使用する場合、Receiveアプリケーション バイト バッファーは、宣言したアプリケーション バイト バッファーと同じサイズのチャンクでソケット バッファーを実際にデキューします。アプリケーションで定義し、関数に送信したアプリケーション バイト バッファにこのチャンクを割り当てますReceive。
  3. 上記が当てはまる場合、バイト バッファの長さがソケット キュー内のバイト要素よりも大きい場合はどうなるでしょうか。
  4. また、2 が正しい場合Send、ソケットのメソッドは、アプリケーション バッファではなく、エンドポイントに接続されたホスト ソケット バッファにデータを送信します。
  5. 最後に、Socket メソッドは非ブロッキングであるため、基になる実装でスレッドが作成され、メソッドが呼び出されAcceptたときにデキューされる独自のキューがあります。Accept

これまでの私の理解が正しいかどうか、またはほとんど間違っていて修正が必要かどうかを確認するために、これらすべてをお願いします。

4

1 に答える 1

1

まず第一に、.netの実装は、ほとんどがwinsockのマネージラッパーです。

私の理解では、Socketのインスタンスは、内部クラスの実装で変更可能なサイズのバッファーを持ち、実際にはバイトのキューであり、アプリケーションで宣言および定義するアプリケーションバッファーとも異なります。

これまでのところわかりました。

ソケットタイプを使用する同期モードの場合：...メソッドReceiveを使用する場合

Receiveを呼び出すと、データが提供されたバッファにコピーされ、書き込まれたバイト数が返されます。これは、バッファのサイズよりも小さい可能性があります。バッファがTCPスタックによってキューに入れられたすべてのデータを収容するのに十分な大きさではない場合、バッファにコピーできるバイト数だけがコピーされ、残りのバイトは次のReceiveの呼び出しで返されます。

ソケットは、送信（または受信）されたすべてのデータを中断のない連続ストリームとして扱います。ただし、ネットワークを介して送信されるデータは、最大パケットサイズなどの制約を満たすためにデータを分割するネットワークまたはホストの影響を受けます。コードは、データが任意のサイズのチャンクで到着する可能性があることを前提としています。ちなみに、この種のメッセージは、開発/テスト環境よりも実稼働環境で表示される可能性が高くなります。

socketは、アプリケーションバッファではなく、エンドポイントに接続されたホストSocketバッファにデータを送信します

データがTCPスタックによってキューに入れられると、送信が返されます。TCPウィンドウがいっぱいで、リモートエンドポイントがソケットを読み取っていない場合（たとえば、自身の送信が完了するのを待っているため）、これには時間がかかる可能性があります。

最後に、SocketメソッドAcceptは非ブロッキングであるため

ドキュメントによると、Acceptは、接続が受信されるまでブロックするか、（非ブロックモードで）最初に使用可能な接続を同期的に受け入れるか、接続が使用できない場合はスローします。

これは依然として関連性があり、ネットワークコードを書き始めようとしている人には読むことをお勧めします。

于 2012-10-20T01:02:12.623 に答える