「TCPクライアント・サーバープログラムを作成する」への評価、コメント

評価：良い
かなり参考になりました。実際に動かせました！！
ありがとうございました。本当に感謝しております。

評価：良い
いつも参考にさせて頂いております！
今回も大いに助けになりました！
ありがとうございます！

評価：悪い
ns.DataAvailable を見てループを抜けるのはやめたほうがいいです。
というのは、パケット長が長くなり、長さが MTU値を超えると分割して送信されるからです。
つまり、データはまだ続いているのに、受信途中で抜けてしまう可能性があります。

他サイトのサンプルを複数見ながら作ったTcpServerプログラムが受信と返信の2回目以降が例外になってしまい四苦八苦していたところ、ここでヒントを得てなんとか仕事を進められた。ありがとうございます。

いつも当サイトでお勉強をさせて頂いております。

「すべてのIPアドレスをListenする」の箇所で
IPv4とIPv6のアドレスをListenする方法として
　IPAddress.IPv6Anyの指定 ＆
　Socket.SetSocketOptionメソッドでIPv6Onlyを0にする
と記載されていますが、最近？はこれを一つにまとめた
　TcpListener listener = TcpListener.Create(ポート番号);
という方法もありますので参考になればと思い
コメントさせていただきました。

以上です。宜しくお願い致します。

もっと読みやすくしてくれ

>>以下に示すコンソールアプリケーションは、ローカルIPアドレスのポート2001で動作し、まず接続してきたクライアントからデータ（文字列）を受信し、受信した文字列の長さを返信してから、クライアントを切断しています。

ちゃんと記事を読みましょう。

分かりやすい記事をありがとうございます。
質問させていただきたいのですが、
以下のサーバ側の処理で、クライアント側から送られてきた文字列の長さをクライアント側へ送信している理由は何でしょうか。

if (!disconnected)
{
//クライアントにデータを送信する
//クライアントに送信する文字列を作成
string sendMsg = resMsg.Length.ToString();
//文字列をByte型配列に変換
byte[] sendBytes = enc.GetBytes(sendMsg + '\n');
//データを送信する
ns.Write(sendBytes, 0, sendBytes.Length);
Console.WriteLine(sendMsg);
}

よく解りましたが、クローズのことで教えてください。クライアントが通信を終了したい時、TcpCleiant.closeでクローズしますが、その時ＶＢ６の時はサーバ側のソケットでクローズイベントが発生しておりました。VB.NETではこのイベントが発生しないためサーバ側が終了の処理が出来ず困っております。例にある通りテータのやり取りでクライアント側が終了する旨をデータで送る以外方法はないのでしょうか。

> 広告がすげー邪魔

現在は広告が自動で挿入される設定になっており、表示されるほとんどの広告は自動で挿入されたものです。そのため、これを制御することは難しいですが、もし具体的にこの広告が邪魔というものがございましたら、お知らせください。よろしくお願いいたします。

広告がすげー邪魔

評価：良い
シンプルに必要な情報が詰め込まれていて素晴らしい

コピペで基本的な動作確認ができる完璧なサンプルがあり
コメントもわかり易く、改変の助けになります
いつもお世話になっております

評価：良い
とても分かりやすい！
助かりました。

適度なコードの量と説明の量で素晴らしいです。
正確に安全に書けば長すぎて読みにくいし、はしょれば文句を言う人も出てくることでしょう。

理解しやすい手頃なバランスでコーディングされています。
すっと試せて毎度とても役に立っています。
有り難う御座います。

評価：良い
thanks

この記事ではないですが、
https://codezine.jp/article/detail/22
において「Socketはスレッドセーフではない」と書かれていますが、Socketはスレッドセーフです。MSDNにも書かれています。誤解を招くので訂正をお願いします。

listener.Start()
でどんなＩＰアドレスにしてもエラーが発生します。

評価：良い
端的で判り安い　

>データの受信処理で
do～while (ns.DataAvailable)
の判定方法だと1.66MBの画像ファイルをbyte配列にして
転送しようとしたときに全部読み込まないうちに
ループを抜けてしまいました。

とありますが、画像などの比較的サイズの大きいものはUDPで通信することをお勧めします。本来TCPは大きなデータの送受信に向いておりません。
管理人ではないですが、返信コメントをさせていただきました。

スレッドではないのですね。

UIの方はどのように組めばよろしいのでしょうか。
まだ始めたばかりで詳しく分からないので、どうか回答おねがいします。

> 1.66MB全部読む前に途中で返ってきてしまいます。

説明不足の点が多々あり、申し訳ありません。次の機会に書き直したいと思います。ここで紹介している方法はかなり簡易的（手抜き？）ですので、大きなデータをやり取りする場合は、非同期で行った方がよいのではないかと思います。

Dobonさんのコードにはいつもお世話になっています

データの受信処理で
do～while (ns.DataAvailable)
の判定方法だと1.66MBの画像ファイルをbyte配列にして
転送しようとしたときに全部読み込まないうちに
ループを抜けてしまいました。
int resSize = ns.Read(resBytes, 0,resBytes.Length);
もresBytes.Length（1.66MB）分きっちり読んでくれるわけではないようでした。
1.66MB全部読む前に途中で返ってきてしまいます。
ので指定したbyte数分読むまでループするような処理に変更して対応しました。（一定時間たっても読めない場合はループを抜けるようにもしました）

評価：良い
開発の参考にさせて頂きます

すみません。
全部把握していなかったようで、全部把握してみたら、切断が正しい事がよくわかりました。

サーバー側の処理で
> //Readが0を返した時はクライアントが切断したと判断
および
> Console.WriteLine("クライアントが切断しました。")
とありますが、
その後、サーバー側からクライアント側へ送信しているので、切断という表現はおかしいのでは？

本来の意味としては、「クライアントからの送信データをすべて受信した」という方が近いのかな？と思ったのですが、いかがでしょうか？

> ドメインをlocalhost以外の独自の物にできないですか？

もちろん可能です。

ドメインをlocalhost以外の独自の物にできないですか？

評価：良い
簡潔なのに必要な事がしっかり書かれております。

何をしているのかよく分からないけれど、コピペすれば動くというサンプルが良いサンプルと言い切るのは難しいと思います。特にこのようなサーバーアプリケーションの場合、セキュリティの問題もありますので、なおさらではないでしょうか。このサンプルの場合、Listenするアドレスを表すIPAddressを指定するという点を明確にすべきで、IPAddress.Anyではその点が分かりにくくなります。しかも、意図していないアドレスをListenしてしまう可能性があります。さらに細かいことを言うと、IPAddress.Anyは万能ではなく、IPv4だけです。ですので、IPAddress.Anyを使用したサンプルが最善とは決して言い切れないと私は考えます。

MSDNのサンプルがそもそも良くないですね。
http://msdn.microsoft.com/ja-jp/library/c6z86e63%28VS.80%29.aspx
一応解説で補足説明されているとはいえ、Dns.Resolve("localhost").AddressList[0];を指定すべき状況なんてちょっと思いつかないです。
適当にコピペしてしまうと一見動く割に実は環境依存になっちゃう。

> TcpListenerコンストラクタに
> System.Net.Dns.GetHostEntry(host).AddressList[0];
> を渡しているのはサンプルとしては良くないかと。
>
> http://www.atmarkit.co.jp/fdotnet/special/networkprog/networkprog_03.html
> にあるようにIPAddress.Anyで良いと思います。

どちらの方がサンプルとして適切かは分かりませんので、両方の方法を併記することを検討します。ご提案、ありがとうございました。

TcpListenerコンストラクタに
System.Net.Dns.GetHostEntry(host).AddressList[0];
を渡しているのはサンプルとしては良くないかと。

http://www.atmarkit.co.jp/fdotnet/special/networkprog/networkprog_03.html
にあるようにIPAddress.Anyで良いと思います。

> TCPクライアントのソースで一点、returnしてしまうと
> 各種Closeされないのが気になりました。

遅ればせながら、修正させていただきます。ご指摘、ありがとうございました。

> MSDN の TcpClient.Close のヘルプには、「このメソッドを呼び出すと、関連する Socket が閉じられ、データが作成された場合の送受信に使用される、関連する NetworkStream も閉じられます。」とあり...
> MSDN ヘルプのドキュメントバグですかね?

「TcpClient.GetStream メソッド」の説明には「データの送受信を完了したときは、NetworkStream を終了する必要があります。 TcpClient を終了しても、NetworkStream は解放されません。」とありますので、私にも両者の説明は矛盾しているように思えます。

実際のところは、moveccrさんがご指摘のように、TcpClient.CloseでNetworkStreamも閉じられるようで、「TcpClient.Close メソッド」の説明が合っているようです。「TcpClient.GetStream メソッド」の説明の方が間違っている（もしくは別の意味なのかもしれませんが）ようです。

ただ、NetworkStreamも明示的に閉じた方が無難なので、このページのサンプルはこのままにしておきます。

ご指摘、ありがとうございました。

MSDN の TcpClient.Close のヘルプには、
「このメソッドを呼び出すと、関連する Socket が閉じられ、データが作成された場合の送受信に使用される、関連する NetworkStream も閉じられます。」
とあり、実際 .Net4.0 の TCPClient.cs のソースを読んでも、 Close() Dispose() m_DataStream.Dispose() と呼び出しが行われ、
GetStream() で取得される m_DataStream の Dispose() がコールされているようです。
MSDN ヘルプのドキュメントバグですかね?

大変参考になりました。
TCPクライアントのソースで一点、returnしてしまうと
各種Closeされないのが気になりました。
↓ここ
if (resSize == 0)
{
Console.WriteLine("サーバーが切断しました。");
Console.ReadLine();
return;
}

TCP/IPとUDP/IPのプログラムを作成するのに、大いに参考にさせていただきました。感謝しております！　同期メソッドから非同期メソッドに書き換え、スレッドプールの使用、サーバー側でリストによるコネクション管理、送信側は接続を保持させるなど手を入れていき、思うようなアプリケーションを作成できるようになりました。

ありがとうございます。

> System.IO.MemoryStream ms = new System.IO.MemoryStream();はCloseしていますが、
> System.Net.Sockets.NetworkStream ns = tcp.GetStream();はその処理がありません。

ご報告ありがとうございました。修正しておきます。

System.IO.MemoryStream ms = new System.IO.MemoryStream();はCloseしていますが、
System.Net.Sockets.NetworkStream ns = tcp.GetStream();はその処理がありません。

MSDNでは次のようになっています。
「データの送受信を完了したときは、 NetworkStream を終了する必要があります。 TcpClient を終了しても、 NetworkStream は解放されません」

評価：良い
ありがとうございます

評価：良い
ギリギリの状態で焦っている中、非常に参考になりました。
多謝です。

評価：良い
いつも参考にさせていただいてます。
感謝。

とても参考になります。

評価：良い
助かりました

評価：良い
わかりやすい

ドボンさんのような人がいるおかげで開発効率の向上や処理の理解にとても大きく影響を受けていると思います。
心から感謝します。

評価：良い
VB6.0ではWinsockがありましたが、.NET〜はその機能がなくなってしまって困っていたところ、大変参考になりました。ありがとうございます。

わかりやすいけど
ｸﾗｲｱﾝﾄ側切断されたのにｻｰﾊﾞｰ側の
ns.Write(sendBytes， 0， sendBytes.Length);
を実行するとエラーはならないです
ｸﾗｲｱﾝﾄ側の切断は判断できないですか？

評価：良い
わかりやすい表示でした。