TCP/IPのデータで質問です。

パソコンのサーバーと無線ハンディをTCP/IPで通信しています。サーバー側は無線ハンディからの要求に応えるプログラム(Visual Basic,Winsockコントロール使用)が起動されています。

このサーバーに無線ハンディ30台(もっと多いこともある)から,いっせいに接続要求を出すのですが,この接続に失敗するハンディがあったりします。

このときLAN上のデータを見てみると,パソコン側からRST(リセット)フラグ(強制切断)のデータが出ていました。どうやらこれが接続に失敗している原因のようなのです。

このRST(リセット)フラグのデータが出るのは,どう行ったときなのでしょうか? どういう理由でRST(リセット)フラグのデータが出るのでしょうか?

ご存知の方,いらしゃいましたら教えていただけないでしょうか? よろしくお願い致します。

このQ&Aに関連する最新のQ&A

A 回答 (5件)

ちなみに、ですが、手元の「TCP/IPバイブル」(SOFTBANK)では、



---------------
RST
 リセットフラグ(reset flag)は、他の全てが失敗するとき使われる。これは
エラーが起こり、コネクションが強制的にクローズされるべきであること(ある
いは、コネクションオープン要求に対する応答として送信されるならば、その要
求が拒否されること)を示す。
---------------
とあります。

実装でどう使われているかというのは、実装によるので難しいですね。
もしかしたら、という事で、MicrosoftのKBを挙げておきます。

参考URL:http://www.microsoft.com/japan/support/kb/articl …
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。

調べている中で、Winsockコントロールのキューも怪しそうだという情報もありました。どうもありがとうございました。

お礼日時:2001/03/12 09:42

このあたりの資料は書籍のほうが確実だと思います。



思いっきり専門書となりますが、オライリージャパンから出ているものでTCP/IPを
解説しているものがあったはずです。(私のところには「TCP/IPネットワーク管
理」というものしか置いてないので調べてみてください)
このほかにも専門書をたくさん置いてあるところにいけば結構あったと思います。

WebではRSTフラグは「強制切断」としか書いてないところが多数なんで何とも言い
ようがないですが、JPNICホームページのカテゴリ「教育」あたりにあるかもしれま
せん。
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。

いくつか書店をまわってみましたが「これ!」というものがなくて...。WEBでいろいろ探し回って、少しずつ情報が集まりかけてはいます。

お礼日時:2001/03/12 09:34

>ただ、1度目で失敗したときに、ハンディで接続処理をリトライさせるとつながる


>ようになります。
と いうことで、リトライ時点でその他のハンディのコネクションがまったく切れ
ていないのであれば、ハンディのプログラムを「コネクションを確立できなければ
何度かリトライする」というように改修するべきです。または、サーバにきたコネ
クション確立要求をパケットエラーでない限り受け入れるように改修するべきで
す。

コネクションを確立するのは要求する側の要求であって、要求された側はその要求
がのめる状態かどうかをチェックして初めて要求をのむかどうかを判断します。

コネクション確立要求がはねられる理由は
・資源(通信帯域やコネクションを確立するのに必要なメモリ)を使い切る寸前で
ある
・コネクション要求を受けたあと、返信するまでにある一定時間を経過してしまった
・パケットのエラー
などの原因ですので、このあたりをきちんと検討してみるといいでしょう。

※前回答にも書きましたが、きちんと実験してデータを取り、どこを改修するべき
かはきちんと検討する必要があります。
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。

もう少しこちらでも情報を集めてみようと思います。

接続要求や、rstフラグのデータについて説明してあるホームページや書籍をご存知ないでしょうか。もしご存知でしたら、教えていただけると助かります。

お礼日時:2001/03/08 09:30

TCPプロトコルは1対1のハンドシェーク通信を行います。



コネクションが成立するとFINを送受信するまでコネクションは成立したまま
となります。
コネクションをエラーなどで切断する必要が出るとRSTを送信してコネクショ
ンを解放します。

また、セキュリティポリシーなどで制限がかかっていてコネクションを成立さ
せたくない相手からのコネクション要求に対してもRSTでコネクションを不成
立させます。

といったところでどうでしょう?

現状はサーバー側からRSTを発信しているとのことですが、すべてのハンディ
からのコネクション要求が受け付けられているのか(つまり、RSTが出るのが
コネクション要求時なのか、コネクション成立後なのか)が分からないのでこ
のあたりに関しては現状をもっと詳しく解析されてみてはいかがでしょう?
(たとえばサーバ負荷とRSTが出てくる状態に関係があるとか)
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。

すべてのハンディからのコネクション要求を受け付けられているのか、というと接続できなかったハンディに対しては受け付けられていないようです(VBのプログラムで接続要求イベントがあがっていない)。

ただ、1度目で失敗したときに、ハンディで接続処理をリトライさせるとつながるようになります。

お礼日時:2001/03/07 17:08

多分ですが、以下のことが想像できます。


・無線チャンネルが使いつくされてしまっている
・ハンディのIPアドレスが重複している
・VBのリスンが間に合っていない
・VBプログラムの構造に欠陥がある
・メモリ不足により、スレッド、タスク、プログラムのどれかを起動できなかった。
・不正アクセス監視プログラムによりアタックと認識され、阻止された。

で、RSTになるのは、確か該当サービスが起動していない時、あるいはエラー発生だったかと思います。
だから、無線チャンネルの奪い合い、IP重複という可能性が結構考えられそうです。
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。

挙げられた中で言うと、IPアドレスの重複はありません。またPCにはメモリを1GB積んでいますから、不足ということはないと思います。

VBのリスンが間に合っていない、ということはCPUの性能ということでしょうか。ちなみにPen3 800Mhzを使用しています。

不正アクセス監視...という説もありえない話でなさそうですが、「こういう理由でRSTを出した」という情報がどこかで取得できないでしょうか...。

お礼日時:2001/03/07 16:52

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人はこんなQ&Aも見ています

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

QwiresharkでパケットモニタするとRetransmissionが多発しているという意味は?

現在、自分で作成したパケット送信クライアントプログラムをテストしており、3秒に1回のタイミングでインターネット上にあるサーバのグローバルipアドレスに対し、TCPパケットを発信させて受信するというテストを行っています。
しかし、3秒に一回データを送っているはずなのに、その間隔10秒とか20秒とか間隔が開いてしまう時があります。

wiresharkというパケットモニタソフトで送信側、受信側共にパケットモニタを行ってみたところ、”Retransmission”が多発しているということがわかりました。(tcp.analysis.retransmissionというフィルタ設定で検索)この現象はある時とない時があります。テストして10日ぐらい経つのですが、このパケットが確認されるのはお昼の12時頃と夕方の6時頃が多いのですが、このことからどのようなことが起こっていると考えられますか?

わかる方いらっしゃいましたらご教授よろしくお願いいたします。

Aベストアンサー

簡単に言うと「トラフィック過多によるパケットの再送が多発している」です。

噛み砕いて言えば「回線が混雑していて、送信したパケットが、他の誰かが送信したパケットと衝突(コリジョンが発生)してパケットが消えた。なので、もう一度、送り直した」と言う事。

>このパケットが確認されるのはお昼の12時頃と夕方の6時頃が多いのですが、このことからどのようなことが起こっていると考えられますか?

「お昼休み、終業時間の6時になると、みんな、メールをチェックしたり、個人的にインターネットを閲覧し、トラフィック過多が起き、回線が異常に混雑する」と言う事が起きていると考えられます。

解消するには以下の方法があります。
・「休み時間も、終業時間後も、プライベートでネットを使うな!」と言う「通達」を全社に出す
・社内LANを、トラフィック過多によるコリジョンが起きないよう高速で帯域のあるネットワークカード、LANハブ、ルーターに変える
・受信側と送信側を、社内LANから(電気的、アドレス的に)独立した別のLANにする

要は「混んでる時間帯なので仕方が無い」って事です。

簡単に言うと「トラフィック過多によるパケットの再送が多発している」です。

噛み砕いて言えば「回線が混雑していて、送信したパケットが、他の誰かが送信したパケットと衝突(コリジョンが発生)してパケットが消えた。なので、もう一度、送り直した」と言う事。

>このパケットが確認されるのはお昼の12時頃と夕方の6時頃が多いのですが、このことからどのようなことが起こっていると考えられますか?

「お昼休み、終業時間の6時になると、みんな、メールをチェックしたり、個人的にインターネットを...続きを読む

QFINパケット、RSTパケットが返却される理由?

アパッチのヘルスチェックにて、パケットをみました。
シーケンス番号を追っていきましたが、下記のような
通常ではない動作がありました。

<ケース1>
(1)サーバからのHTTPのGETに対して、クライアントがFIN.ACKパケットを返却する。
(2)サーバがFIN.ACKパケットをクライアントに送る。
(3)クライアントからRSTパケットが返却される。
※RSTパケット内にて、broken tcpとの記載あり

<ケース2>
(1)サーバからのFIN.ACKパケットに対して、クライアントからRST.ACKパケットが返却される。


・質問1
それぞれについて、正常な動作とはおもえないのですが、
異常でしょうか?

・質問2
FIN.ACKパケット又はRSTパケットが返却されるのはどんな場合が想定されるのでしょうか?

・質問3
FIN.ACKパケット→RST.ACKパケットは異常な動作でしょうか?

よろしくお願いします。

Aベストアンサー

おつかれさまです。

質問1
ケース1というのはおかしいですね。
サーバからのHTTPのGETというのはありえません。
GETはクライアントから送信されるものです。
言葉のアヤでGETの応答電文がサーバから送信
されている間にFINがクライアンから来るという
ことであってもおかしくないと思います。

ケース2のRSTパケットについてもおかしくありません。
よくブラウザ上で通信途中(画面が全部表示されない)
で次のページへ移動することなどありますよね。
またサーバもクライアントも、keepaliveという
機能があります。一連のやりとりが終わっても、
次の通信のために一定期間コネクションを保持する
機能です。これは意外とおせっかい機能で時間が
たつと勝手にRSTを発行したりします。

質問2
FINは一連の通信が終わった時です。
上述のkeepaliveの機能も一応決まりがあって、
httpヘッダにカウンドダウンする数字があって
もうこの通信で終わりですよって1まで来たら
FINが発行されます。
またはkeepaliveのtimeout時間が過ぎると
RSTが出ます。
他のケースとしては通信不良で再送リトライ
オーバとなった場合とか、通信不良で通信の
シーケンスが合わなくなった場合とかに
RSTが出ることはあります。

質問3
FIN→RST クライアントがFINを出してコネクションを
開放した後に、FINをサーバが返してきたら、もう
コネクションはないのでサーバ側も開放してねと
RSTを投げるケースはあるでしょうね。

とにかく、
ケース1(1)以外はよくあることです。
クライアント(PCのブラウザだと思いますが...)は
人が操作しているので、ブラウザを×するとか
F5キー押すとか、いろんなことをやるでしょう。
WindowsやIEのそのあたりの動きは結構アバウトな
作りであることは確かですが....

いかがでしょう?

おつかれさまです。

質問1
ケース1というのはおかしいですね。
サーバからのHTTPのGETというのはありえません。
GETはクライアントから送信されるものです。
言葉のアヤでGETの応答電文がサーバから送信
されている間にFINがクライアンから来るという
ことであってもおかしくないと思います。

ケース2のRSTパケットについてもおかしくありません。
よくブラウザ上で通信途中(画面が全部表示されない)
で次のページへ移動することなどありますよね。
またサーバもクライアントも、keepaliveという
機能があり...続きを読む

QWiresharkでみるときの、1回のパケット

Wiresharkでみるときの、1回のパケットを追う方法を探してます。

TCP通信にて、通信確立後にデータのやり取りをしている通信を数時間tcpdumpにて取得し、
Wiresharkで流れをみています。そのときに、1回のデータのやり取りと見るために方法を教えてください。


クライアントからのリクエストとサーバからのレスポンスで、

1回目クライアントからデータ送信し、
複数かいやり取りして、終了(200 OKを返却して)

2回目クライアントからデータ送信し、
複数かいやり取りして、終了(200 OKを返却して)

という動作を繰り返してますが、

この1回目がここからここまでのパケット、2回目がここからここまでのパケットと知りたいのです。

なんとなくみると、ストリームNoなどもありますが、
ストリームNoが1回の通信後とのNoかとおもったら、
ストリームNoでフィルタしたら、
1回目5回目8回目・・と複数回のものが同じストリームNoであり、
どうゆうことだとうと疑問になってます。

詳しい方よろしくお願いします。

Aベストアンサー

No1です。
>TCPストリーム単位でも複数のやりとりがあるのか?わからなくて悩んでます。

昔のHTTP/0.9というプロトコルでは、リクエストに対してレスポンスがあればそれでストリームを終わらせてましたが、現在のHTTP/1.1では1つのTCPストリームで複数のリクエストーレスポンスを行うのが普通です。
また、レスポンスを待たずに複数のレスポンスを続けて投げることも可能です。

Qpingでポートの指定

pingでIPアドレスを指定して、通信できるかどうかというのは
よく使いますが、pingでポートを指定して応答するかどうかは調べられるのでしょうか?

よろしくお願いします

Aベストアンサー

pingを含むICMPというプロトコルは、OSIの7レイヤで言うところのL2(同一セグメント内通信)とL3(IPルーティングされた通信)の両方にまたがる、ちょっと珍しいプロトコルです。

IPアドレスは指定できますが、別サブネットに属するIPアドレスに到達できればL3通信、できなければゲートウェイと呼ばれる同一サブネットに属する中継装置からの回答を得るという点でL2(MAC通信ではなく、同一セグメント内通信という意味)通信です。

ポート番号はL4で使用されるアドレスですから、L4機能の疎通確認はping(を含むICMP)ではできません。

FTPの疎通確認であれば、クライアントからサーバに対するTCP/21通信(FTP-CMD)が可能であること(サーバからクライアントへのTCP/21からの応答を含む)+サーバからクライアントに対するTCP/20通信(FTP-DATA)が可能であること(クライアントからサーバへのTCP/21からの応答を含む)が必要でしょう。

監視ソフトによるものであれば、
・クライアントからサーバへのログイン(TCP/21)
・クライアントからサーバへのlsの結果(TCP/20)
で確認すればよいでしょう。

pingを含むICMPというプロトコルは、OSIの7レイヤで言うところのL2(同一セグメント内通信)とL3(IPルーティングされた通信)の両方にまたがる、ちょっと珍しいプロトコルです。

IPアドレスは指定できますが、別サブネットに属するIPアドレスに到達できればL3通信、できなければゲートウェイと呼ばれる同一サブネットに属する中継装置からの回答を得るという点でL2(MAC通信ではなく、同一セグメント内通信という意味)通信です。

ポート番号はL4で使用されるアドレスですから、L4機能の疎通確認はping(を含む...続きを読む

Qポートの80と443

こちらのサービス(https://secure.logmein.com/)を利用すると、インターネットを見られるサーバーのポートの80と443が空いていればルータやファイアウォールに特段の設定なく外部からサーバーを操作できるそうですが、逆にサーバーのポートの80や443を空けることには何か危険性があるのでしょうか。

Aベストアンサー

ポート80は一般的なHTTP、ポート443はHTTPSです。
この2つのポートがあいていなければインターネット接続(WEBブラウジング)は出来ません。
ですから、ほとんどのファイアウォールでこのポートは開いています。(インターネット接続を制限している社内LANでは当然閉じていますが)

ちなみに、よく使うポートとしてはFTPで20、21、SMTP(送信メール)で25、受信メールPOP3で110あたりです。セキュリティポリシー上、この辺は制限される事も多いですが、HTTP 80、HTTPS(暗号化用)443は通常閉じません。


危険性?
WEBプロトコルを使ってFTP的なファイル転送(WebDAV)やVPN等も出来るようになっています。当然そこにはある種の危険はつきものですが、WEBブラウジングに伴う危険と大きく変わりません。ウィルス等に感染していればこの2つのポートだけでも相当危険でしょうね。

参考まで。

Qtcp/ip通信で特定のデータが送れない

おせわになっています。
現在、秋月のH8ボート3069+RTL8019ボードを使用して、TCP/IPの通信プログラムを作成して
いたます。
ボードはホスト側に成っています。


H8OS等は使用していません。

パケットの送受信も有る程度問題なく出来ていて、クライアントからの通信確立も出来ています。
データの送受信を行っているときに、1バイトデータ 0x02を送信使用としたら、一番下のような
エラーが出てきました。

1バイトデータで0x00、0x01、0x03等は問題なく送れています。
Wiresharkで取り込んだデータの一部分を掲載します。

又、エラーとして[Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]と
表示されていますが、実際何が原因でエラーに成っているのかが判りません。

有る程度強引に合わせこんでデータを作っている部分も有るのですが、0x02のデータだけが
送れないというのが判りません。
データを見て頂き、判る方がいましたら教えてください。



[Calculated window size: 64240]
[Window size scaling factor: -2 (no window scaling used)]
Checksum: 0xd1b9 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[SEQ/ACK analysis]
[Bytes in flight: 1]
Data (1 byte)
Data: 03
[Length: 1]
VSS-Monitoring ethernet trailer, Source Port: 0
Src Port: 0
0000 00 40 45 32 27 35 02 00 03 cb 36 06 08 00 45 00
0010 00 29 fc d7 40 00 80 06 3d ac ac 14 64 00 ac 14
0020 04 22 29 04 06 42 65 62 b7 da 9e 32 35 28 50 10
0030 fa f0 d1 b9 00 00 03 00 00 00 00 00 00
              --- このデータは送れている。



Window size value: 64240
[Calculated window size: 64240]
[Window size scaling factor: -2 (no window scaling used)]
Checksum: 0x8254 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
[SEQ/ACK analysis]
[Bytes in flight: 1]
[Malformed Packet: FMTP]
[Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
[Message: Malformed Packet (Exception occurred)]
[Severity level: Error]
[Group: Malformed]
VSS-Monitoring ethernet trailer, Source Port: 0
Src Port: 0
0000 00 40 45 32 27 35 02 00 03 cb 36 06 08 00 45 00
0010 00 29 fc d7 40 00 80 06 3d ac ac 14 64 00 ac 14
0020 04 22 29 04 09 2f 65 62 b7 da d1 ae 4f 24 50 10
0030 fa f0 82 54 00 00 02 00 00 00 00 00 00
              --- このデータは送れていない。

宜しくお願いします。

おせわになっています。
現在、秋月のH8ボート3069+RTL8019ボードを使用して、TCP/IPの通信プログラムを作成して
いたます。
ボードはホスト側に成っています。


H8OS等は使用していません。

パケットの送受信も有る程度問題なく出来ていて、クライアントからの通信確立も出来ています。
データの送受信を行っているときに、1バイトデータ 0x02を送信使用としたら、一番下のような
エラーが出てきました。

1バイトデータで0x00、0x01、0x03等は問題なく送れています。
Wiresharkで取り込んだデータの一部分を...続きを読む

Aベストアンサー

>又、エラーとして[Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]と
>表示されていますが、実際何が原因でエラーに成っているのかが判りません。

ざっと見た程度ですが……。

>0010 00 29 fc d7 40 00 80 06 3d ac ac 14 64 00 ac 14
>0010 00 29 fc d7 40 00 80 06 3d ac ac 14 64 00 ac 14

IPヘッダのIdentificationが同じ値(0xd7fc)のIPパケットで問題ないのですか?
手元のSSHサーバに接続したときのモノ(SSHサーバからのもののみ)では…
Identification: 0x0000 (0)
=>3WayハンドシェークのSYNパケットの返答
Identification: 0xdb28 (56104)
=>ハンドシェーク完了後、SSHサーバが送信してきたウェルカムメッセージ
Identification: 0xdb29 (56105)
=>クライアントからのパケットに対するACK応答パケット
Identification: 0xdb2a (56106)
=>SSHサーバからのオプションなどのクライアントへの通知
というように値が更新されていってますが。

パケットがMTUなどによって分割された場合にIdentificationが同じ値になることはあるようですが、その場合はFlagsとFlagment Offsetで制御されるハズです。
が…Flags(ダンプだと0x0014の場所の上位3ビット)のビット1が1となっていますので「分割を許可していない」状態ですし、Flagment Offsetは同値の0番となっています。
よって受信側では「不正なIPパケット」として破棄しますから、その次のTCP処理まで進まないかと思われますが…そこのところどうでしょうか?

参考URL:http://www.itbook.info/study/p89.html

>又、エラーとして[Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]と
>表示されていますが、実際何が原因でエラーに成っているのかが判りません。

ざっと見た程度ですが……。

>0010 00 29 fc d7 40 00 80 06 3d ac ac 14 64 00 ac 14
>0010 00 29 fc d7 40 00 80 06 3d ac ac 14 64 00 ac 14

IPヘッダのIdentificationが同じ値(0xd7fc)のIPパケットで問題ないのですか?
手元のSSHサーバに接続したときのモノ(SSHサーバからのもののみ)では…
Identification: 0x0000 (0)
=>3Wayハンド...続きを読む

Qネットワーク遅延について

お世話になります。
ご面倒かけますが、ご回答頂ければ助かります。

状況を説明させて頂きますと
あるプログラム(計算して結果を出力)をネットワーク上で共有フォルダにアクセスして
実行しております。

(1)スタンドアローンで実行(自分のPCにプログラムを保存)すると、実行時間が1~2分
(2)ネットワークの共有フォルダにアクセスして実行した場合 5分~10分かかります。
※できるだけマスタ配布のような業務が入る為、スタンドアローンでは利用しない方針です

なぜこんなに実行時間に差がでるのかという質問を頂いてます。

ネットワーク上のプログラムを実行しているのですから、ある程度遅くなるのは
当たり前です。とは回答しているのですが、理解してもらえません。

WireSharkを利用して、パケットを拾ったのですが
・ TCP Dup ACK
・ TCP Retransmission
・ TCP Previous segment lost
上記のようなパケットを拾いましたが、パケットを分割や再送信を行っているので
遅くなっていると話をしましたが、これがネットワークの問題なのかプログラムの問題か
確認(考え方)するにはどうしたらいいでしょうか?

参考程度でも結構ですので、お願いいたします。

お世話になります。
ご面倒かけますが、ご回答頂ければ助かります。

状況を説明させて頂きますと
あるプログラム(計算して結果を出力)をネットワーク上で共有フォルダにアクセスして
実行しております。

(1)スタンドアローンで実行(自分のPCにプログラムを保存)すると、実行時間が1~2分
(2)ネットワークの共有フォルダにアクセスして実行した場合 5分~10分かかります。
※できるだけマスタ配布のような業務が入る為、スタンドアローンでは利用しない方針です

なぜこんなに実行時間に差がでるのかという...続きを読む

Aベストアンサー

まず前提として、
スタンドアロンの場合、自らのプログラムやデータはメモリー上に格納され
更新など行っても、実際にはファイルに書かれるのでは無くメモリー上で更新されます。
なので、物理的なアクセスの発生が少なく高速で動作します。
しかしネットワークの場合は、「共有」という概念が働く為なるべくメモリーで
処理するのでは無く物理的なファイルに更新がかかるようになります。
※このあたりはソフトの設計にも共有の仕方によりOSの制御にもよりますが....

また、それらの読み込み・更新毎にネットワークを使ってデータやり取りする為、
ネットワークへの負荷が掛かること、ネットワークの混雑具合に影響される事など
速度低下する要因が多くなりますので、ネットワーク上のデータを利用するという事は
こういう事だと理解してもらう必要があります。

そして、パケットのエラーの内容を見ていると、ネットワークで障害が発生していますね。
原因としては、ケーブル・HUB・ルータ・NICなど機器全てを疑う必要があります。
まず、同じ事を複数のパソコンで実行して、同じような状況になる端末を特定し、
その影響範囲を調べます。

結果、その範囲に使ってる機器が特定されますので、
その機器を交換して問題ない事を検証すれば良いと思います。

まず前提として、
スタンドアロンの場合、自らのプログラムやデータはメモリー上に格納され
更新など行っても、実際にはファイルに書かれるのでは無くメモリー上で更新されます。
なので、物理的なアクセスの発生が少なく高速で動作します。
しかしネットワークの場合は、「共有」という概念が働く為なるべくメモリーで
処理するのでは無く物理的なファイルに更新がかかるようになります。
※このあたりはソフトの設計にも共有の仕方によりOSの制御にもよりますが....

また、それらの読み込み・更新毎にネットワ...続きを読む

QSocketのSend関数でのCLOSEの検知 [Linux]

Linux環境でSocket(dm:PF_INET,type:SOCK_STREAM)を使用しての、
Client&ServerプログラムをCで作成しているのですが、
そこでのSend関数の使い方についてご助力ください。

Client&Serverプログラムは下記のような動きをします。

[Client]
ServerへConnectした後、複数のDataを数秒間隔でServerへ
送信(send関数使用)します。受信(recvやread関数等)は、
一切行いません。

[Server]
ClientからのConnectを受け付けた後、Clientから受信(recv関数
使用)したDataを標準出力へ表示する。送信(sendやwrite関数
等)は、一切行いません。


さて、ここでもしClientプログラムがCloseを発行したり、マシン
DOWN等の理由でConnectionが切断され、Server側のSocketが
CLOSE_WAIT状態になった場合、Bufferに溜まっていたDataを
すべて受けきった後、recv関数が0を返してくれるので
相手が終了したことがわかります。

ここからが質問のMainです。

では、もしServerプログラムがCloseを発行したり、マシン
DOWN等の理由でConnectionが切断され、Client側のSocketが
CLOSE_WAIT状態になっても、CLOSE_WAIT直後のsend関数が
なぜか正常に処理されてしまいます。無論このDataは、
Server側は受け取りません。この次のsend関数実行時に
EPIPEが返ってくるので、ここでようやくSocketが切断された
ことが判ります。

これを何とかCLOSE_WAIT状態になった直後から、send関数で
切断を検知できるようにできないでしょうか。

よろしくお願いします。

以上

Linux環境でSocket(dm:PF_INET,type:SOCK_STREAM)を使用しての、
Client&ServerプログラムをCで作成しているのですが、
そこでのSend関数の使い方についてご助力ください。

Client&Serverプログラムは下記のような動きをします。

[Client]
ServerへConnectした後、複数のDataを数秒間隔でServerへ
送信(send関数使用)します。受信(recvやread関数等)は、
一切行いません。

[Server]
ClientからのConnectを受け付けた後、Clientから受信(recv関数
使用)したDataを標準出力へ表示する。送信(se...続きを読む

Aベストアンサー

#3です。
>完全な保証ではないのですが、”送れた/送れない”をきちんと
ログとして残す必要があるのです。

なるほど、そういう事情でしたか。それだと、それなりの信憑性が要求されますね。

>それと最初にご提案いただいたrecvをNonBlockモードで呼び出す
方法ですが、これだとrecvのリターン値は0が返ってこないでしょうか?

Linuxで以下のような、プログラムを組んで確認しました。

//送信前に、ノンブロッキングでrecvする。
ret = recv(sock,rbuf,sizeof(rbuf),MSG_DONTWAIT);
if (ret == -1 && errno == EAGAIN){
//正常なので送信可能
ret = send(sock,msg[i],sendlen,0);
if (ret != sendlen){
//送信エラーの処理
}
}else{
//切断検知時の処理
 // CLOSE_WAITになると ret=0が返る
}

サーバー側で切断時、直ちにrecvで戻り値=0となり、エラーの検知ができました。ret==-1 かつ errno==EAGAIN
であれば、回線は正常状態です。

#3です。
>完全な保証ではないのですが、”送れた/送れない”をきちんと
ログとして残す必要があるのです。

なるほど、そういう事情でしたか。それだと、それなりの信憑性が要求されますね。

>それと最初にご提案いただいたrecvをNonBlockモードで呼び出す
方法ですが、これだとrecvのリターン値は0が返ってこないでしょうか?

Linuxで以下のような、プログラムを組んで確認しました。

//送信前に、ノンブロッキングでrecvする。
ret = recv(sock,rbuf,sizeof(rbuf),MSG_DONTWAIT);
if (ret == -...続きを読む

Qパケットロスで考えられる原因は何でしょうか?

PINGを打つと送信元は問わず
全720回中58回(約8%)のパケットLossが発生していますが
送信先の回線やサーバ負荷が高いと普通にある現象なのでしょうか?

又、故障の場合、原因として
1.ルータの故障
2.海底ケーブルの不良
などでしょうか?

tracerouteしても良くわからず、この先はどのように
調査すれば良いのかわからず困っています・・

19 XXX.XX.XXX.XX (XXX.XX.XXX.XX) 42.003 ms 42.003 ms 42.239 ms
20 * * *
21 XXX.XX.XXX.XX (XXX.XX.XXX.XX) 43.487 ms 42.583 ms 42.168 ms

Aベストアンサー

ご参考

http://www.atmarkit.co.jp/fnetwork/rensai/netadmin04/netadmin04.html

QNTP の TCPポートは?

NTPは123/UDPでようは足りると思うのですが、
WELL KNOWN PORTとかいろいろな資料に「123/TCP」ポートが割当たってます。
ntpd,ntpdate等でNTPを使う場合、実際には123/TCPは使われているのでしょうか?

Aベストアンサー

RFC1305では「ntpには123/udpを割り当てる」となっていますが、RFC1700では「123 ntp」となっており、「123/udp」と明示されているわけではありません。
よって、「123/tcp ntp」が間違っている(または使えない)という明確な根拠にはなりません。

「現状では『123/tcp ntp』を実装するための定義が存在しない」程度に考えた方が良いと思います。

ただ、将来的にRFC2030のSNTPが(IPv6対応などの点で)主流になる可能性があるので、「123/tcp ntp」は定義されない可能性もあります。


このQ&Aを見た人がよく見るQ&A

人気Q&Aランキング

おすすめ情報