ディレクトリが空の場合の NLST での FTP タイムアウト
-
09-06-2019 - |
質問
編集:それが重要な場合、Webメソッドは実際にはLISTではなくNLSTを使用することを学びました
私たちのビジネスでは、ほとんどのアウトバウンド通信を処理するために WebMethods 統合サーバーを使用していますが、その FTP 機能にはまだ不十分な点があります。WebMethods に固有の可能性がある問題が発生していますが、どのようなことが原因でこの問題が発生するのか、どなたかご教示いただければ幸いです。
パートナーの 2 つの FTP サーバーをポーリングすると、問題なく接続できますが、空のディレクトリ (ファイルもサブディレクトリもなし) で NLST を実行するとタイムアウトになります。実際のエラーは次のとおりです。
com.wm.net.ftpCException:[ISC.0064.9010] java.net.SocketTimeoutException:受け入れがタイムアウトしました
これは、pub.client.ftp:ls サービスの呼び出し中にスローされます。いくつかの FTP クライアントを使用して同じサイトに問題なくログインしました。WindowsのデフォルトのFTPクライアントであるFileZillaとlftpを使用しました。すべて問題なく。私の知る限り、サーバー自体は同じ FTP サーバー ソフトウェアではありません。1 つは Microsoft FTP で、もう 1 つは定かではありませんが、明らかに Microsoft ではありません。
空のディレクトリで NLST 応答を待機しているときに FTP クライアントがタイムアウトになる原因は何か考えられますか?FTP サーバーからの目に見える応答は同じように見えますが、空のディレクトリに対する NLST の応答方法に、私が気づいていない違いはありますか?
この問題は、これら 2 つのサーバーで一貫して発生します。ディレクトリ内にファイルまたはサブディレクトリがあるディレクトリではすべて正常に機能しますが、空の場合は機能しません。
ご意見やご指示をいただければ幸いです。
ありがとう!
エリック・シップル
解決
WebMethods IS バージョン 6.5 アップデート WmPRT_6-5-1_SP1、IS_6-5_SP3 でこれを試しました。
初めてでも完璧に機能しました。
FTP サーバー (Debian のデフォルトの ftpd) でデバッグを有効にしました。WebMethods の NLST は、渡されたアクティブ/パッシブ パラメーターを尊重します。
NLST コマンドについては特別なことは何もありません。また、空のディレクトリでの正しい動作についても何もありません。LIST が機能するのであれば、RETR、STOR、および NLST も機能するはずです。NLST が空ではないディレクトリで動作する場合は、空のディレクトリでも動作するはずです。
したがって、私の推測では、次のいずれかです。
- あなたのバージョンの WM にはバグがありますが、私のバージョンにはありません
- あなたの FTP サーバーにはバグがありますが、私のサーバーにはありません
- あなたのシステムには、データのない FTP データ ソケットを嫌う、奇妙なプロトコル認識ファイアウォールがあります。
ファイアウォール ベンダーは FTP に関しては少し気まぐれです...他のクライアントでテストする場合は、WebMethods Integration Server が実行されているのと同じマシンからテストするようにしてください。
記録のために、アクティブな NLST で何が起こるかは次のとおりです。
- クライアントはリスニングソケットを開き、そのソケットの詳細を含む PORT コマンドを送信します。
- クライアントが NLST コマンドを送信する
- サーバーはクライアントのリスニングソケット (これはデータソケット) に接続します。
- サーバーはデータソケット (この場合はゼロバイト) を介してリストを送信します。
- サーバーがデータソケットを閉じる
...そしてパッシブモードでは
- クライアントが PASV コマンドを送信する
- サーバーはリスニングソケットを開き、その詳細を含む PASV 応答で応答します。
- クライアントはリスニングソケット (これはデータソケット) に接続します
- クライアントが NLST コマンドを送信する
- サーバーはデータソケット経由でリストを送信します(再びゼロバイト)
- サーバーがデータソケットを閉じる
他のヒント
同じ問題かどうかはわかりませんが、少し前に Java の別の FTP クライアント (commons.net) を使用して同様の症状が発生しました。この問題は、接続のアクティブ/パッシブ モードが原因であることが判明しました。申し訳ありませんが、私が覚えているのはこれだけですので、詳しくは言えません...それが役立つことを願っています。
ギレルモ・バスコンセロスの答えは正しかった。FTP モードには、アクティブとパッシブの 2 つがあります。デフォルト FTP モードがアクティブです。アクティブでは、サーバーが何らかの TCP/IP ポートでクライアントに接続し直す必要があります。これは、このポートがブロックされているか、NAT を備えたルーターの背後にいてマッピングされていない可能性があるため、ファイアウォールでは機能しません。
代わりにパッシブ (PASV) モードを使用すれば、問題は解決します。
明日ここでメンテナンスが完了するときに、パッシブ設定でいくつかの新しいテストを実行するつもりですが、それが問題かどうかはわかりません。そのディレクトリにファイルまたはサブディレクトリがある場合、ディレクトリのリストを取得できます。NLST を実行しているディレクトリが空の場合にのみ失敗します。
アクティブ/パッシブの違いは空のディレクトリでのみ現れるのでしょうか、それとも別の可能性がありますか?
FTP では、指定されたポートとその上のポートの両方がファイアウォール経由で開かれている必要があります。webMethods のタイムアウトに関する問題が発生したのは、ファイアウォールで戻りポートが開いていないことが原因でした。
ハワード