- - PR -
SocketでＦＴＰプログラムを作ったが、【Connection reset】が発生！
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-07-30 09:59
アプセトネデブ（アプリケーション、プレゼンテーション、セッション、トランスポート、ネットワーク、データリンク、物理） の７層です http://www.wakasato.org/learn/nepc/course1/chapter01/section02.html 等が参考になるかと。 
_________________ Inspired Ambitious ISMS Assistant Auditor | ||||||||||||
|
投稿日時: 2004-07-30 10:26
通信分野のプログラミングは初めてだったので、よく分からないまま作ったのですが、
メールクライアントとかＷＥＢクライアントなんかでも、多分、ソケットの部分でエラーが発生した場合、何度かリトライをやってるんじゃないかな？と思います。 本来、通信ＰＧでは、ソケットエラーに対しては何度かリトライを設けるのが定石なのかもしれないですね。 なんか、そんな気がしてきました。 リトライを行ってもエラーが続いたときに始めて、エラーとしてユーザ通知するものなのかもしれないですね。まー私の勘なんですが。 今回の件に関しては、 依頼主-----------Ａ社（インフラ担当） | -----Ｂ社（ソフト開発担当）-----Ｃ社（製造担当）------私（他３人） となっており、環境周りに関する情報を入手するのは現実的に困難でした。 また、インフラ情報がないとプログラムが組めないのか！って話にまで発展する可能性もあり、 はたまた周囲を騒がせた挙句、原因はＰＧミスです。とは言い辛い状況を自分で作ってしまう結果に陥ることを考慮すると、なかなか難しいものです。 | ||||||||||||
|
投稿日時: 2004-07-30 10:34
おばけさん、
ＯＳＩは７層です。 後で読みかえして８になってたのでやっちゃったーと思ってたところ、 ご指摘いただき、赤面してます。 どうやら、雑魚クレーマーが一匹釣れたみたいですが、 問題の解決から程遠い存在なので放置でいきます。 | ||||||||||||
|
投稿日時: 2004-07-30 10:58
あいつーです。
おばけさんも指摘されていますが、JVMはOSごとに配布されているわけですから、 OSによって挙動が異なる、というのは大いにありえます。 というか、OS依存のバグというのも結構ありますよ。 ですので、なるべくOSも書いたほうが良いとは思いますが。 （今回は関係ないとは思いますが、特定OS限定のライブラリなんかもありますしね）
自分もネットワーク系にはあまり詳しくないのですが、 トラフィックや通信状況の影響で失敗するというのは考えられることかとは思いますので、 リトライして、一定回数失敗したらエラーというのは定石だと思います。 （リトライ時にエラー通知するかどうかはケースバイケースだと思いますが） ちなみにエラー時のトレースなどは取得できるのですか？ それらも場合によっては有益な情報となると思います。 後は一般的なことですが、掲示板で不快なことがあったからといって、 直ぐにそれをそれを不快感あふれる口調で返す、というのは如何なものでしょうか。 なるべく友好的に話は進めましょうよ。 # だって相手が〜というのは止めてくださいね 
| ||||||||||||
|
投稿日時: 2004-07-30 11:36
あいつー氏へ >リトライして、一定回数失敗したらエラーというのは定石だと思います。 うん。私も定石のような気がしてきてます。 http://e-words.jp/w/E382B3E383AAE382B8E383A7E383B3.html 上の記事を読む限り、コリジョンはエラーではないとなってます。 でも、データ再送は、ＯＳもしくはＮＩＣ、ルータの役割だと思うのだが、 アプリで制御するものなのかな？ そのあたり、ソケット詳しい人教えてください。 >ちなみにエラー時のトレースなどは取得できるのですか？ Exception#geMessage() でエラー内容をログに出力してますが、 確認できる内容が【Connection reset】だけでした。 それ以外の情報はなかったです（何でエラー番号すらないのか不明）。 >後は一般的なことですが、掲示板で不快なことがあったからといって、 >直ぐにそれをそれを不快感あふれる口調で返す、というのは如何なものでしょうか。 このカテで議論する内容ではないですが、 社会人としての常識に関わる部分でもありますので、あえて言いますが、 不快感を相手に伝達することも、コミュニケーションの一つです。 掲示板であろうがなかろうが、極めて一般的なことですよ。 | ||||||||||||
|
投稿日時: 2004-07-30 11:52
Ethernetでのパケット衝突に際しての再送は、物理層やデータリンク層の責務だと 思われます。Ethernet特有の出来事ですからねえ。
再送と一口に言っても、それぞれ責務が違いますよね。 NICはEthernetレベルで、ルータはIPレベルで、OSはTCPレベル？ う〜ん、私も詳しくないですが、とにかく何でもかんでもこれら下層の連中が 何とかしてくれるってわけではないでしょうね。 ただ、今回の件は、コネクションがリセットされたと言っているので、TCPの コネクションが切れたってことかな？まあ、理由は色々とあると思いますが、 相手のFTPサーバが死んだとか、そういうことも考えられますよね。
エラー時にはスタックトレースを出した方が良いですよ。 厳密にどこで例外が発生しているかわかりますから。 で、もしFTPクライアントのソースコードがあるのでしたら、その例外発生 箇所のソースを追って挙動をチェックしてみても良いですよね。 まあ、JNIでOSネイティブなシステムコールや関数を呼んで終わり、というオチも あるでしょうけど・・・。 | ||||||||||||
|
投稿日時: 2004-07-30 12:47
そんな事は無い。 TCP接続を用いる場合、プロトコルスタック内でリトライ処理etcを勝手にやってくれます。そんな事はTCPレベルで発生しているエラーに対して、リトライ処理を行っても無駄です。リトライをするならConnectからやり直しでっせ。
だったら実環境に出来るだけ近い環境を用意して、自前で試験するしかないんじゃないの？私なら「正常に機能しているか、稼働状況の確認のためログファイルと照らし合わせたい」とか言って貰って来ますけどね。 ＃IP Networkな話題のような気がするんだけど。 | ||||||||||||
|
投稿日時: 2004-07-30 13:21
甕星氏へ
引用；-------------------------------------------------------------------------- そんな事は無い。 TCP接続を用いる場合、プロトコルスタック内でリトライ処理etcを勝手にやってくれます。そんな事はTCPレベルで発生しているエラーに対して、リトライ処理を行っても無駄です。リトライをするならConnectからやり直しでっせ。 ------------------------------------------------------------------------------- なるほど。ＴＣＰレベルのエラーではコネクトからやりなおしですか。 一つ質問ですが、では、アプリで検知するエラー（具体的には、ＦＴＰコマンドの”NLST”とか”RETR”を制御用ソケットから投げて異常終了。サーバからの戻り値確認不可）は、ＴＣＰレベルのエラーということでいいでしょうか？ となると、プログラムが悪いってことですね。 でも不明なのは、制御用の接続がリセットされたのか、転送用のコネクションがリセットされたのかがわからないです。 これって、判別する手法とかってあるのでしょうか？ | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。