ソケット設定
いつもお世話になっております。
最近、ネットワークプログラミングを勉強しているのですが、1つ不思議なことが起きましたので御助言いただけると幸いです。
UDPで、小さなパケット(50byte)を10Mbps程度でデータを受信させたときに、送信サーバーのほうで何故か処理能力が落ちて
しまいました。
(送信帯域が1%くらいに激減しました)
UDP通信なので、送信側には何も影響はないはずだと思っているのですが、実は受信サーバーから何かを受け取っていたりするのでしょうか??
もう一つ疑問に思ったのが、[送信側]1ソケット → [受信側]1ソケット でデータを正常に送信することはできます。
[送信側]複数ソケット → [受信側]複数ソケット もOKです。
[送信側]1ソケット → [受信側]複数ソケット の場合にだけ送信帯域が激減するという事象に陥ります。
ちなみに送受信は複数ポートで行っております。
このような設定には普通しないと思うのですが、ご教授いただけますでしょうか。
宜しくお願い致します。
日時:
08/03/06 10:31
コメント
補足お願いします
れっささん,こんばんわ。
ちょっと,わからないところがあるので,補足願えますか?
>UDPで、小さなパケット(50byte)を10Mbps程度でデータを受信させたときに、
>送信サーバーのほうで何故か処理能力が落ちてしまいました。
>(送信帯域が1%くらいに激減しました)
送信側(A)と受信側(B)があって,
AからBに50バイトのパケットを10Mbpsのペースで送信したいのに,
10Mbpsの1%程度しか,パケットを送信できなかった,
ということかしら?
>[送信側]複数ソケット → [受信側]複数ソケット もOKです。
これはどういう意味かしら?
送信側にソケットが1~mまでm個あり,
受信側にはソケットが1~nまでn個あり,
送信側のソケット1から受信側のソケット1~nに順番(かな?)にパケットを送り,
送信側のソケット2からも受信側のソケット1~nにパケットを送り,
っていう具合にして,
送信側のソケット1~mから,受信側のソケット1~nに対してパケットを送る,
っていうことかな?
>[送信側]1ソケット → [受信側]複数ソケット
これもどういう意味かしら?
送信側の一つのソケットから
受信側の複数ソケットに対して順番(かな?)にパケットを送る,
っていうことかな?
>ちなみに送受信は複数ポートで行っております。
マシンAとマシンBがあって,
Aは常に送信側,Bは常に受信側で,UDPのパケットは一方向に流れる
っていうことかと思っていたのですが,
送受信が複数ポートっていうことは,
送信側と受信側は固定されているわけではなくて,
AとBの間で両方向にUDPパケットが流れるのかしら?
パケットを見てみれば,すぐ原因がわかるのかもしれませんけど。
Re 補足お願いします
すみません、、言葉足らずでした。
補足致します。
>ちょっと,わからないところがあるので,補足願えますか?
>>UDPで、小さなパケット(50byte)を10Mbps程度でデータを受信させたときに、
>>送信サーバーのほうで何故か処理能力が落ちてしまいました。
>>(送信帯域が1%くらいに激減しました)
>送信側(A)と受信側(B)があって,
>AからBに50バイトのパケットを10Mbpsのペースで送信したいのに,
>10Mbpsの1%程度しか,パケットを送信できなかった,
>ということかしら?
はい。その通りです。
>>[送信側]複数ソケット → [受信側]複数ソケット もOKです。
>これはどういう意味かしら?
>送信側にソケットが1~mまでm個あり,
>受信側にはソケットが1~nまでn個あり,
>送信側のソケット1から受信側のソケット1~nに順番(かな?)にパケットを送り,
>送信側のソケット2からも受信側のソケット1~nにパケットを送り,
>っていう具合にして,
>送信側のソケット1~mから,受信側のソケット1~nに対してパケットを送る,
>っていうことかな?
はい。
送信側の送信処理と受信側の受信処理を、処理能力向上のため、複数(複数スレッド)用意して、
並列で動かしています。
このときのソケット数はそれぞれ100個に設定しています。
>>[送信側]1ソケット → [受信側]複数ソケット
>これもどういう意味かしら?
>送信側の一つのソケットから
>受信側の複数ソケットに対して順番(かな?)にパケットを送る,
>っていうことかな?
はい。
>>ちなみに送受信は複数ポートで行っております。
>マシンAとマシンBがあって,
>Aは常に送信側,Bは常に受信側で,UDPのパケットは一方向に流れる
>っていうことかと思っていたのですが,
>送受信が複数ポートっていうことは,
>送信側と受信側は固定されているわけではなくて,
>AとBの間で両方向にUDPパケットが流れるのかしら?
Aは常に送信側,Bは常に受信側です。
試験の目的としては単純で、送信処理と受信処理を改造して、どうすれば処理能力が向上するのかと。
その際に、ソケット数の設定を変更して実験したところ、不思議な事象が起きましたので。。
>パケットを見てみれば,すぐ原因がわかるのかもしれませんけど。
パケットをキャプチャしてみてもB→A方向へは、ICMP以外のデータは見られませんでした。
また、送受信レートをみても不正データを受け取っているような履歴はありませんでした。
以上ですが、宜しくお願い致します。
送信側の負荷はどのくらいかしら?
>パケットをキャプチャしてみてもB→A方向へは、ICMP以外のデータは見られませんでした。
このICMPの内容はどんなものかしら?
Bー>Aにエラー通知しており,Aがそのエラー処理のために負荷が高くなっている
なんてことはないかしらね。
それから,Aでのパケット送信部分をコメントアウトして
実行したらどうなるかしら?
パケット送信以外の負荷が高くて,送信ペースが上がらない,
なんてことがないかどうか,確認しておくことも大切かと思います。
Re 送信側の負荷はどのくらいかしら?
>このICMPの内容はどんなものかしら?
>Bー>Aにエラー通知しており,Aがそのエラー処理のために負荷が高くなっている
>なんてことはないかしらね。
単なる送達確認の内容だったと思います。
正常導通時と全く同じ内容でした。
>それから,Aでのパケット送信部分をコメントアウトして
>実行したらどうなるかしら?
>パケット送信以外の負荷が高くて,送信ペースが上がらない,
>なんてことがないかどうか,確認しておくことも大切かと思います。
たしかに送信以外の負荷が高くなっていることは確認しました。
(何に処理をとられているのかを現在調査していますが、糸口がみつかりません・・・)
事象をまとめますと、
[送信側ソケット] [受信側ソケット] [結果]
1個 1個 正常導通確認
複数個 1個 正常導通確認
複数個 複数個 正常導通確認
1個 複数個 ★送信帯域が減少★
送信バッファが足りないからなのかなぁと思ったりもしていたのですが、UDPで送信する
だけだから関係ないと思います。
バックグラウンドで何かを受け取っているのかなぁと思っているのですが、そのようなことが
あるのでしょうか?
UDPのやり取りではICMPは流れないはず
> 単なる送達確認の内容だったと思います。
UDPには送達確認はありません,
というか,そもそもICMPは送達確認に使うものではありません。
通常のUDPのやり取りではICMPは流れないはずなので,
ICMPの中身を調べた方が良さそうに思いますよ。
Re UDPのやり取りではICMPは流れないはず
>UDPには送達確認はありません,
>というか,そもそもICMPは送達確認に使うものではありません。
>通常のUDPのやり取りではICMPは流れないはずなので,
>ICMPの中身を調べた方が良さそうに思いますよ。
回答ありがとうございます。
ICMPを確認してみました。
・Destination Unreachable(到達不能)
とのことでした。
正常導通時にも流れていましたので、内容はスルーしていたのですが、
これは、どういったときに、誰が(どこが)、送信するるのでしょうか?
Bがデータを受信した際に、Aに対してICMPで到達不能通知を出す理由がわかりません。。
確かに、UDPはデータを投げっぱなし(送達確認する必要はない)でいいはずですよね。
ちなみに、ソケットは全データ受信できるように設定しております。
追加質問となってしまい、申し訳ありませんが、宜しくお願い致します。
netstatでソケットの状態を調べた方がいいかも
> ・Destination Unreachable(到達不能)
Destination Unreachableの内容をもう少し調べると,
到達しない理由がわかります。
宛先のIPサブネットが存在しないとか,
宛先IPアドレスに該当する機器が存在しないとか,
宛先ポート番号に該当するソケットが存在しないとか,
といった情報がICMPの中に書いてありますから。
> ちなみに、ソケットは全データ受信できるように設定しております。
異常が発生しているときに,
netstatコマンドでソケットの状態を調べてみた方がいいかもしれません。
Destination Unreachableを返すっていうことは,
受信側がパケットを受け取れない状態になっている可能性が高いですから。
Re netstatでソケットの状態を調べた方がいいかも
>Destination Unreachableの内容をもう少し調べると,
>到達しない理由がわかります。
>宛先のIPサブネットが存在しないとか,
>宛先IPアドレスに該当する機器が存在しないとか,
>宛先ポート番号に該当するソケットが存在しないとか,
>といった情報がICMPの中に書いてありますから。
>異常が発生しているときに,
>netstatコマンドでソケットの状態を調べてみた方がいいかもしれません。
>Destination Unreachableを返すっていうことは,
>受信側がパケットを受け取れない状態になっている可能性が高いですから。
ソケットの状態は問題ありませんでした。
全ポートのパケットを受信できるように設定しております。
なぜか最初の数パケットだけICMPを返送しておりました。
また、その後、約1秒間隔で1パケットICMPを返送します。
ICMP(Destination Unreachable)を出すのですが、データを取りこぼしてはいないようです。
ちゃんと受信してデータを引き取れました。
いまその理由を調べるためにICMPを勉強しておりまして、TypeとCodeはわかったのですが、データ部に何がかかれているのかが、説明資料(サイト)が見当たりません。。
※英語サイト探すしかないのでしょうか・・
なんどもなんども申し訳ありませんが、御助言いただけますでしょうか・・m(__)m
RFCを調べるのが一番かと思いますけど
> TypeとCodeはわかったのですが、
タイプとコードがわかれば,大体のところはわかると思います。
> ※英語サイト探すしかないのでしょうか・・
ネットワークをやるなら,英語に慣れておいた方がいいでしょうね。
折に触れ,英語の文章を見るようにすると,抵抗感はなくなっていくと思います。
その意味でも,下のサイトでRFCを調べると良いでしょう。
http://www.rfc-editor.org/
ここにある情報がTCP/IP関係の原典ですから。
Re RFCを調べるのが一番かと思いますけど
>タイプとコードがわかれば,大体のところはわかると思います。
Type:3(Destination Unreachable)
Code:3(プロセス・ポート到達不能)
らしいのですが、なぜ到達していないのかがわかりませんでしたので。。
>ネットワークをやるなら,英語に慣れておいた方がいいでしょうね。
>折に触れ,英語の文章を見るようにすると,抵抗感はなくなっていくと思います。
了解しました。
英語や国語が苦手だからプログラムを書く世界に入ったのですが、、
、、勉強します・・・^^;
>その意味でも,下のサイトでRFCを調べると良いでしょう。
>http://www.rfc-editor.org/
>ここにある情報がTCP/IP関係の原典ですから。
ありがとうございます。
さっそく調べてみました。
その結果、タイプとコード意外は特に有効な情報はICMPにはないようです。
※data部分は受信したデータの一部をそのまま乗っけているようです。
色々調査してみた結果、ICMPが発生する理由は、ARP影響のようです。
ARP未解決時にバースト的にパケット送出があった場合に、ARP解決が走り
該当のパケットがICMP送信されるという現象がおきているようです。
ARPは毎回どこかのタイミングで必ず送信されていたので、被疑から外していました。。
これからはARP解決を行ってから、実施するようにして回避しようと思います。
長々と面倒を見ていただき、ありがとうございました。
今後とも宜しくお願い致します。
ARP云々で受信側がポート到達不能になる?
> 色々調査してみた結果、ICMPが発生する理由は、ARP影響のようです。
> ARP未解決時にバースト的にパケット送出があった場合に、ARP解決が走り
> 該当のパケットがICMP送信されるという現象がおきているようです。
うーーん。これはどういうことかしら?
ARPによって影響を受けるのは送信側ですから,
ARP云々で受信側がポート到達不能,っていうのは変ですね。
何か誤解があるような気がしますよ。
> 長々と面倒を見ていただき、ありがとうございました。
まだ終わりじゃありませんよーー。
このメッセージ見てくれるかしら。