2017-04-11 16 views
0
  1. "connect"と呼ばれる非ブロックUDPソケットでデータを送信するには、 "select/epoll/kqueue"を使用して書き込み可能かどうかをテストする必要があります?その場合、相手側のrecvバッファがいっぱいです。 "send"が失敗する可能性があるので、 "send"が成功を返すように書き込み可能であることをテストするために "select"を使用できますか? それはデータを送信するだけで、サイドのrecv buffがいっぱいかどうか気にしないので、不要です。それが本当であれば、「送信」は相手側がダウンしていない限り成功を返すだけでしょうか?
  2. UDPソケットの場合、 "send"の戻り値は何ですか?たとえば、100バイトを送信します。-1(エラー)または100以外の値を返します。 TCPの場合と50 ~~~~
+0

UDPはコネクションレスです。送信者は、パケットが受信者に送信されたかどうかはまったく分かりません。受信したかどうか、またはバッファがいっぱいだったかどうかはほとんど分かりません。 –

答えて

1

を返すことがあり、他の側のrecvバッファがいっぱいになる、失敗することがあり、「送信」ので、私は それが書き込み可能だことをテストするために「選択」を使用することができますように"send"は を返す可能性がありますか?

あなたはUDPを使用しています。パケットが送信され、受信バッファが受信側でいっぱいになると、受信側のシステムはそれを破棄します。これを読む:https://en.wikipedia.org/wiki/User_Datagram_Protocol#Reliability_and_congestion_control_solutions

send()コールの結果は、受信機の状態に完全に依存しません。受信側が存在しなくても成功します。

UDPは、基礎となるネットワークのパケットサイズより大きいデータグラムの処理方法のためにこれを参照してください:一般的にUDP Sockets on Linux; send successfully but unable to receive large buffer

0

を、send()をブロックし、常に書き込まれたバイト数を返さないで、ローカル(送信)バッファがない限り、カーネルがいっぱいです。基本的に決して起こらないUDPソケットの場合。あなたが速く書くか、受信側が処理できるなら、起こるTCPソケットのために。

関連する問題