私は、一般的なストリームからデータを読み取る単純な方法の魔女を書いています。つまり、長さを知らずにFileStreamまたはNetworkStreamになる可能性があります。私は繰り返しストリームをバイト[]に読み込み、データを別のストリームなどにプッシュします。私の質問は、ストリームが終了したことをどうすればわかりますか？私は返信しようとしたときのメソッドが0を返す - これは正しい方法ですか？ファイルを読むのは問題ありませんが、ネットワークからデータを読み取るときに問題が発生することがあります。ストリームが最後まで読み込まれたことをどのように伝えることができますか？
はい、繰り返しReadを呼び出し、0を返すと終了するのはまさに正しい方法です。
ネットワークストリームもこれで問題なく、データが受信されるか、ストリームが切断されるまでブロックされます。 Stream.Readのドキュメントを見てください：
戻り値は 位置が ストリームの終わりに現在ある場合のみゼロです。実装は、 データがない場合、少なくとものデータを読み取ることができるまで、 をブロックします。 readは、 のストリームにデータがなくなり、それ以上のデータが存在しない（例えば、 クローズドソケットまたはファイルの終わりなど）場合にのみ、0を返します。
ネットワークストリームの場合、Stream.ReadByte（）が0より小さい値を返す場合、ストリームが最後まで読み込まれたことがわかります。
NetworkStreamのループ本体にReadメソッドの直後にReadByte（）メソッド呼び出しを置く必要があることを意味しますか？ –
Jonは言うとおり、0バイトを返すのでファイルの終わりです。ただし、投げられるさまざまな例外も考慮する必要があります。ネットワークは本質的に信頼性が低いため、常に例外がいくつかあります。
たとえば、ストリームが切断された場合（反対側が単にソケットを閉じるのではなく）、IOExceptionの例外を受け取ることがあります。 I/O呼び出しを常に例外ハンドラでラップします。ただし、例外をスローできないことが確実な場合を除きます。
例外がスローされる可能性があるからといって、それらをハンドラでラップする必要はありません。私の経験では、IOコールがIOExceptionをスローすると、そのメソッドを*作成する*コールは通常例外のバブルを許可するだけです。私は、ほとんどのtry/catchブロックを持つ傾向があります - 通常はトップの近くにあります。 –
私はすぐにそれをキャッチする必要はありませんでした。しかし、それはある時点で捕らえられるべきです。 –
私は訂正された、ありがとう。 – JoshBerke
それから、ネットワークストリームのデータの長さを知る必要があると思われますか？ –
長さを知ることは助けになりますが、厳密には必要ではありません。 –