- PR -

ブロッキング・非ブロッキング関数について

1
投稿者投稿内容
freebird
常連さん
会議室デビュー日: 2006/11/07
投稿数: 22
投稿日時: 2006-11-28 19:19
こんばんわ。
Winsockを用いてソケットプログラミングを行なっています。
コンパイラはVC++.NET2003でコンソール上で実行しています。

テキストには、sendtoやrecvfromまた、sendやrecv関数はブロッキング関数となっています。
ブロッキング関数は、処理が完了するまで返らないと記述してあるのですが・・・

例えば、端末２台を用いて送信端末からsendtoを用いてパケットを受信端末へ送信する場合を考えます。

もし、受信側のプログラムが起動していない場合または、送信側で指定した受信側IPアドレスが間違っている場合に送信側のプログラムを実行すると、sendtoはブロッキング関数ですので動かない状態に陥るのでしょうか？

私のプログラムの場合、パケットを送出？していると思うのですが・・・どこかおかしいのでしょうか？

また、ブロッキングと非ブロッキング関数の使用の区別はあるのでしょうか？

よろしくお願いいたします。
甕星
ぬし
会議室デビュー日: 2003/03/07
投稿数: 1185
お住まい・勤務地: 湖の見える丘の上
投稿日時: 2006-11-28 19:39
Winsock Programmer's FAQを一度は参照してみてください。

引用:

freebirdさんの書き込み (2006-11-28 19:19) より:
こんばんわ。
もし、受信側のプログラムが起動していない場合または、送信側で指定した受信側IPアドレスが間違っている場合に送信側のプログラムを実行すると、sendtoはブロッキング関数ですので動かない状態に陥るのでしょうか？

送信時の「処理が完了するまで」とは「送信バッファに書き込むまで」を指します。したがって送信バッファへの書き込みが完了すれば（データが送信される前に）戻ってきます。送信バッファに空きがなければ戻ってきません。

引用:

また、ブロッキングと非ブロッキング関数の使用の区別はあるのでしょうか？

明確な区別はありません。ノンブロッキングを使うのが普通です。通信エラーを正しく処理するためには、recvfrom等で無限に待つわけには行きません。これを行うと永遠に切断を検出できない状況に陥る可能性があります。
freebird
常連さん
会議室デビュー日: 2006/11/07
投稿数: 22
投稿日時: 2006-11-29 12:30
返信ありがとうございます。
引用:

甕星さんの書き込み (2006-11-28 19:39) より:
Winsock Programmer's FAQを一度は参照してみてください。

参照させていただきます。前回もアドレスをのせていただき大変恐縮です。

引用:

送信時の「処理が完了するまで」とは「送信バッファに書き込むまで」を指します。したがって送信バッファへの書き込みが完了すれば（データが送信される前に）戻ってきます。送信バッファに空きがなければ戻ってきません。

わかりました、ありがとうございました。

送信側でパケットがロスしてしまう原因はブロッキング関数を使用しているから？はありえるのでしょうか？
甕星
ぬし
会議室デビュー日: 2003/03/07
投稿数: 1185
お住まい・勤務地: 湖の見える丘の上
投稿日時: 2006-11-29 12:40
引用:

freebirdさんの書き込み (2006-11-29 12:30) より:
送信側でパケットがロスしてしまう原因はブロッキング関数を使用しているから？はありえるのでしょうか？

ありえません。ブロッキング関数を薦めないのは、パケットをロスした場合のエラー処理をきちんと記述するのが困難だからです。
freebird
常連さん
会議室デビュー日: 2006/11/07
投稿数: 22
投稿日時: 2006-11-30 16:51
コンソールアプリケーションにて、sendtoおよびrecvfrom関数を使用しています。ＭByteのファイルを1KByteずつ送信するアプリケーションを作っているのですが、ブロッキングではなくノンブロッキングでかつ非同期のプロセスに変更するほうがよいのでしょうか？

こんごも、ダイアログボックス等を用いないコンソールアプリケーションでマルチスレッドなプログラムを続けていく予定です。

よろしくお願い致します。
1

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