当目录为空时 NLST 上的 FTP 超时
编辑：了解到 Webmethods 实际上使用 NLST，而不是 LIST，如果这很重要的话
我们的业务使用 WebMethods 集成服务器来处理我们的大部分出站通信，并且其 FTP 功能还有待改进。 我们遇到了一个可能是 WebMethods 特有的问题，但如果有人能指出可能导致此问题的原因，我将不胜感激。
当轮询我们的两个合作伙伴的 FTP 服务器时，我们可以正常连接，但是当对空目录（没有文件和子目录）执行 NLST 时，就会超时。 实际错误是：
com.wm.net.ftpCException：[ISC.0064.9010] java.net.SocketTimeoutException：接受超时
在调用 pub.client.ftp:ls 服务期间抛出该异常。 我已经使用多个 FTP 客户端登录到相同的站点，但没有出现问题。 我使用过 Windows 中默认的 FTP 客户端：FileZilla 和 lftp。 一切都没有问题。 据我所知，服务器本身并不是同一个 FTP 服务器软件。 一个是 Microsoft FTP，另一个我不确定，但绝对不是 Microsoft。
您知道什么可能导致 FTP 客户端在空目录上等待 NLST 响应时超时吗？ 来自 FTP 服务器的可见响应似乎是相同的，但是 NLST 对我不知道的空目录的响应方式是否存在差异？
这个问题在这两台服务器上是一致的。 在包含文件或子目录的目录中一切正常，但在空时则不然。
任何想法或指示将不胜感激。
谢谢！
埃里克·西普尔
EDIT: Learned that Webmethods actually uses NLST, not LIST, if that matters
Our business uses the WebMethods integration server to handle most of our outbound communications, and its FTP functionality leaves something to be desired. We are having a problem that may be specific to WebMethods, but if anyone can point me in a direction of what kinds of things might cause this I'd appreciate it.
When polling two of our partners' FTP servers, we connect without issue but, when doing a NLST on a directory that is empty (no files and no subdirectories) it's timing out. The actual error is:
com.wm.net.ftpCException: [ISC.0064.9010] java.net.SocketTimeoutException: Accept timed out
It's being thrown during the invocation of the pub.client.ftp:ls service. I've logged in with a number of FTP clients without a problem to the same sites. I've used whatever the default FTP client is in windows, FileZilla and lftp. All without issue. The servers themselves aren't the same FTP server software from what I can tell. One is Microsoft FTP, the other I'm uncertain on but is definitely not Microsoft.
Any idea what could cause an FTP client to timeout when waiting for a NLST response on an empty directory? The visible responses from the FTP server appear to be the same, but is there a difference in how NLST responds for an empty directory that I'm unaware of?
This problem is consistent on these two servers. Everything functions fine on directories with files or subdirectories within it, but not when empty.
Any thoughts or directions would be appreciated.
Thanks!
Eric Sipple
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
明天维护完成后，我将运行一些新的测试，并将其设置为被动，但我不确定这就是问题所在。 如果该目录中有文件或子目录，我们就可以获得目录列表。 仅当我们进行 NLST 的目录为空时，它才会失败。
主动/被动差异是否仅在空目录中体现出来，还是还有其他可能性？
I'm going to run some new tests with the settings to passive tomorrow when maintenance is done here, but I'm not sure that's the issue. We are able to get a directory listing if there are files or subdirectories in that directory. It only fails when the directory we're NLST-ing on is empty.
Would the active/passive difference only manifest for an empty directory, or is there another possibility?
FTP 要求指定端口及其上方的端口都通过防火墙打开。 当我遇到 webMethods 超时问题时，这是因为防火墙没有打开返回端口。
霍华德
FTP requires that both the specified port and the one above it be opened through the firewall. When I had problems with webMethods timing out, it was because the firewall did not have the return port open.
Howard
吉列尔莫·瓦斯康塞洛斯的回答是正确的。 有两种 FTP 模式：主动模式和被动模式。 默认的 FTP 模式处于活动状态。 主动要求服务器通过某个 TCP/IP 端口连接回客户端。 这不适用于防火墙，因为该端口很可能会被阻止，或者如果您位于带有 NAT 的路由器（未映射）后面。
如果您改用被动 (PASV) 模式，则应该无法掌握。
Guillermo Vasconcelos was correct in his answer. There are two FTP modes, Active and Passive. The default FTP mode is active. Active requires the server to connect back to the client on some TCP/IP port. This does not work with firewalls because chances are that this port would be blocked or if you are behind a Router with NAT, not mapped.
If you use Passive (PASV) mode instead, you should not get the hang.
我不确定这是否是同样的问题，但不久前我使用 Java 中的另一个 FTP 客户端（commons.net）也遇到了类似的症状。 结果发现问题是由连接的主动/被动模式引起的。
很抱歉我无法向您提供更多详细信息，这就是我所记得的......希望有所帮助。
I am not sure if it was the same problem but I had similar symptoms a while ago using another FTP client in Java (commons.net). The problem turned out to be caused by the active/passive mode of the connection.
I am sorry I can't give you more details, that's all I can remember... hope that help.
我在 WebMethods IS 版本 6.5 更新 WmPRT_6-5-1_SP1、IS_6-5_SP3 中尝试过此操作。
第一次就完美地工作了。
我在 FTP 服务器（Debian 的默认 ftpd）上打开了调试。 WebMethods 的 NLST 尊重传递给它的主动/被动参数。
NLST 命令没有什么特别之处，它在空目录下的正确行为也没有什么特别之处——如果 LIST 有效，那么 RETR、STOR 和 NLST 也应该如此。 如果 NLST 适用于非空目录，则它应该适用于空目录。
所以我的猜测是：
防火墙供应商在 FTP 方面有点任性……
使用其他客户端进行测试时，请确保它来自运行 WebMethods Integration Server 的同一台计算机。
仅供记录，以下是活动 NLST
...并且在被动模式下
I tried this in WebMethods IS Version 6.5 Updates WmPRT_6-5-1_SP1, IS_6-5_SP3.
It worked perfectly first time.
I turned on debugging on the FTP server (Debian's default ftpd). WebMethods' NLST honours the active/passive parameter passed to it.
There's nothing special about the NLST command, nor its correct behaviour with an empty directory -- if LIST works, then so should RETR, STOR and NLST. If NLST works with a non-empty directory, it should work with an empty one.
So my guess is that either:
Firewall vendors are a bit wayward when it comes to FTP...
When testing with other clients, make sure it's from the same machine on which WebMethods Integration Server is running.
Just for the record, here's what should happen for an active NLST
... and in passive mode