BeginReadが呼び出された後、読み取りたいバイトの到着を最終的にトリガーする他のコードがあるとしましょう。次のシナリオはこれまでに可能ですか？
（1）BeginReadの呼び出しが行われ、「buf」を渡して戻ります
（2）（1）に続くことが保証されている他のコードが実行され、その結果、バイトがポートに送信されます
（3）バイトはポート宛てに到着しますが、タイミングの問題のために「buf」に読み込まれません
それが可能になるとは思いませんが、経験豊富な方からの確認を求めています。これがどういうわけか可能であるならば、それから私が探している保証を得るための代替案は何でしょうか？
BeginRead一部のデータが利用可能になると終了しますが、データの量は保証されません。最も明白な例は、「余分な」データがポートに送信される前にバッファがすでにいっぱいになっている場合です...しかし、同様にバッファをいっぱいにする必要はありません-たとえば、ネットワークストリームでBeginReadは、途中でさらに多くのパケットが読み取られた場合でも、単一のパケットが読み取られました。
BeginReadストリーム内のすべてのデータを読み取るまで（つまり、もう一方の端が接続を閉じるまで）、または試行した分だけ読み取るまで（たとえば、長さプレフィックス付きメッセージ）。
適切なネットワーク通信を行いたい場合は、アプリケーションレベルのフレーミングを行う必要があります。
ただし、実際には、これらすべてを処理するメッセージングライブラリを使用するのが最も簡単な方法です。zeromqを見てください。これは本当に素晴らしいものであり、.NETバインディングがあります。
バイトはおそらくそこにありますが、探している場所にない可能性があります。コードを見ずに言うのは難しいです。WireSharkを使用して、送信されていると思われるデータが実際に送信されていることを確認することをお勧めします。