- PR -

NetworkStreamはどんなネットワーク通信に適合しますか？

1|2 次のページへ»
投稿者投稿内容
Bob
常連さん
会議室デビュー日: 2006/03/23
投稿数: 31
投稿日時: 2006-06-08 19:02
お世話になります。

Clinet側は.NETのNetworkStreamを使って、純粋のBSDソケットAPIを使うServerと通信を試みました。BeginReadを使い、非同期受信を行っています。
ここで質問ですが、
1.Client/Server間の通信Layerの対応関係に問題がありませんか？
2.DataAvailable フラグがうまく設定されていないようで、受信Dataがあるのに「false」に設定されたりします。
3.NetworkStreamを生成する際、Socketを指定するが、所有権の指定はなくても、何か不都合が生じるでしょうか？(自分でSocketをCloseする)

以上、宜しくお願いします。
Hongliang
ぬし
会議室デビュー日: 2004/12/25
投稿数: 576
投稿日時: 2006-06-08 19:53
引用:

1.Client/Server間の通信Layerの対応関係に問題がありませんか？

ストリーム指向の接続なら問題ないでしょう。
そうでない場合は合わないかも知れません。

引用:

2.DataAvailable フラグがうまく設定されていないようで、受信Dataがあるのに「false」に設定されたりします。

DataAvailable はバッファにデータが溜まっているかどうかを表す値だったと思います。。
バッファから読み込んだ直後に確認しても、相手先から送信されてきたデータがバッファにまだ格納されていなければ False になるでしょう。

引用:

3.NetworkStreamを生成する際、Socketを指定するが、所有権の指定はなくても、何か不都合が生じるでしょうか？(自分でSocketをCloseする)

確実に Close できるのなら別に良いんじゃないですか？
そのために選択肢を用意してるんだし。
Bob
常連さん
会議室デビュー日: 2006/03/23
投稿数: 31
投稿日時: 2006-06-14 09:21
ご回答ありがとうございます。
一応、BeginRead()を使って、Callbackでデータ受信を待ち受けるテストプログラムを作成したのですが、下記二つの疑問があります。

①TCP/IPをコネクションを確立した後、Callbackで「0」バイトを受信した場合、相手はソケットをCloseしたと見なして問題がありませんか？Webでは、「0」バイト受信で、ソケットをCloseされたと見なす説もありますが、MSのマニュアルでは明記していません。

②自分のCallback処理では、受信データ長をEndReadで受け取り、再度BeginReadで受信待ちうけをさせる形にしているが、相手側はソケットをCloseする場合、「0」バイトのCallback処理がずっと繰り返されています。この現象から見て、やはり「0」バイト受信はソケットがCloseされた証と見なしてよいかと思いますが、いかかでしょうか？

以上、宜しくお願いします。
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2006-06-14 10:39
引用:

(1)TCP/IPをコネクションを確立した後、Callbackで「0」バイトを受信した場合、相手はソケットをCloseしたと見なして問題がありませんか？


いいえ。一般論としてはＮＧです。
ただし、ソケットの上に乗せるプロトコルによってはＯＫな場合もあるでしょう。

引用:

Webでは、「0」バイト受信で、ソケットをCloseされたと見なす説もありますが、


ホントに？
一般論としては受け入れ難いですが、どういう場合に成り立つんでしょう？

引用:

(2)自分のCallback処理では、受信データ長をEndReadで受け取り、再度BeginReadで受信待ちうけをさせる形にしているが、相手側はソケットをCloseする場合、「0」バイトのCallback処理がずっと繰り返されています。この現象から見て、やはり「0」バイト受信はソケットがCloseされた証と見なしてよいかと思いますが、いかかでしょうか？


先にも書きましたが、一般論としてはＮＧです。
送信側はソケット接続をきちんと gracefull shutdown しているでしょうか？
かずくん
ぬし
会議室デビュー日: 2003/01/08
投稿数: 759
お住まい・勤務地: 太陽系第三惑星
投稿日時: 2006-06-14 13:35
引用:

渋木宏明(ひどり)さんの書き込み (2006-06-14 10:39) より:

引用:

Webでは、「0」バイト受信で、ソケットをCloseされたと見なす説もありますが、


ホントに？
一般論としては受け入れ難いですが、どういう場合に成り立つんでしょう？



System.Net.Socket#Selectメソッドに以下の説明がされていますが、これって関係あります？
引用:

MSDNより引用

読み取り可能な状態では、待機状態の場合、Accept がブロックせずに正常に呼び出されます。接続を受け入れている場合は、読み取ることができるデータが存在することを意味します。いずれの場合も、すべての受信操作がブロックせずに正常に行われます。また、リモート Socket が接続をシャットダウンしているかどうかも示します。接続をシャットダウンしている場合は、Receive の実行がすぐに終了し、0 バイトが返されます。
Bob
常連さん
会議室デビュー日: 2006/03/23
投稿数: 31
投稿日時: 2006-06-15 09:29
引用:

MSDNより引用

読み取り可能な状態では、待機状態の場合、Accept がブロックせずに正常に呼び出されます。接続を受け入れている場合は、読み取ることができるデータが存在することを意味します。いずれの場合も、すべての受信操作がブロックせずに正常に行われます。また、リモート Socket が接続をシャットダウンしているかどうかも示します。接続をシャットダウンしている場合は、Receive の実行がすぐに終了し、0 バイトが返されます。


ご回答を頂き、ありがとうございます。
自分の本音は渋木宏明(ひどり)さん同様ですが、かずくんさんのみつけた上記の記述はSocketAPIのSelectにある内容だと思います。
ただ、NetworkStream自体はSocketの上位にあると認識しており、動作的にはSocketそのものに同等かどうかは自分はあまり分かりませんので、何方情報を持っているなら、是非教えて頂きたいです。
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2006-06-15 10:26
引用:

System.Net.Socket#Selectメソッドに以下の説明がされていますが、これって関係あります？
（略）
た、リモート Socket が接続をシャットダウンしているかどうかも示します。接続をシャットダウンしている場合は、Receive の実行がすぐに終了し、0 バイトが返されま


これは Select した時ですよね。

NetwaorkStream は非同期 I/O を Select で実装しているはずはない（WinSock が非同期 I/O をサポートしているので）と思うので、同じ挙動をとるかどうかは。。。
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2006-06-15 12:26
引用:

(2)自分のCallback処理では、受信データ長をEndReadで受け取り、再度BeginReadで受信待ちうけをさせる形にしているが、相手側はソケットをCloseする場合、「0」バイトのCallback処理がずっと繰り返されています。この現象から見て、やはり「0」バイト受信はソケットがCloseされた証と見なしてよいかと思いますが、いかかでしょうか？


受信データが０バイトであること「だけ」でソケットが Close されているとみなすのは良くないと思いますが、Recieve() 結果が０バイトだった時、Socket.Connected の値を調べてみてはどうでしょう？
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）