无法获取类项目 FTP 服务器发送 226

Question

对于一个班级项目，我正在用 Java 编写一个 FTP 客户端（不允许外部 FTP 库），它可以连接并从学校 FTP 服务器获取文件。由于某种原因，一旦传输完成，服务器将不会发送 226，也不会从自己的端关闭连接。

让服务器发送 226 的唯一方法是从客户端手动关闭 InputStream，这似乎不安全，因为客户端无法 100% 确定文件何时完成传输。 （现在，InputStream 的 available() 方法用于检查传输的距离。）

在项目规范中，它说我们必须遵循适用于我们正在实施的命令子集的 RFC 要求。 RFC 声明如下：

一般来说，维护数据是服务器的责任 连接——启动它并关闭它。这个例外 是当用户 DTP 以传输模式发送数据时， 需要关闭连接以指示 EOF。服务器 必须在以下情况下关闭数据连接： 1.服务器已完成以传输方式发送数据 这需要关闭以指示 EOF。 2. 服务器收到用户的 ABORT 命令。 3.端口规格由来自的命令更改 用户。 4.控制连接是否合法关闭。 5. 出现不可恢复的错误情况。 否则关闭是一个服务器选项，其行使 服务器必须通过 250 或 226 向用户进程指示 只回复。

这里有什么我遗漏的吗？

编辑：运行的服务器是 ProFTPD 1.3.0a 服务器。

Answer 1

您使用的是哪种传输模式？引用 RFC959：

流传输模式本质上是 不可靠，因为不能 判断连接是否关闭 过早与否。另一个 传输模式（块，压缩）做 不关闭连接表示 文件的结尾。他们有足够的 FTP 数据连接可以的编码 被解析以确定结束 文件。因此使用这些模式可以 保持数据连接打开 多个文件传输。

您使用的是块还是压缩？

编辑 - 哦 - 流

我没有在第一次阅读时接受它，但你说你正在使用InputStream.available() 来查看传输完成了多远？那不是该方法的作用。在这种情况下，它返回计算机已接收但应用程序尚未处理的字节数。返回的值可以是从零到文件完整大小的任意值。

如果您假设available() 返回 0 时文件已完全发送，则您过早停止读取 - 这就是服务器没有关闭套接字并发送 226 的原因。

判断文件是否完全发送的唯一方法是测试来自流的read 操作的返回。如果为 -1，则文件完整。读取字节数组可以读取零字节。这是不寻常但允许的。在输入关闭之前从输入流中读取的典型代码如下所示：

    byte[] buffer = new byte[0x1000];
    int read;
    while( (read=in.read(buffer)) != -1 ) {
        System.out.println("Read "+read +" bytes from socket ("+
               in.available()+" available now)");
    }

Answer 2

阿农，

这篇文章只是我个人的看法。

我是你的大学讲师，如果你在哪里关闭客户端明显耗尽的流，然后处理随后的 226...只要你评论了为什么这样做，我会很高兴，特别指出它是学校 FTP 服务明显偏离已发布协议的“解决方法”。即：“不是我的问题，我只是要处理它。K Boss？”

对于三倍的单词分数： 1. 对您的客户端进行编码，使其与标准服务器（在您的机器上运行一个 FTP 服务器进行测试，每个操作系统都有免费的）以及您的学校“显然不可靠”的 FTP 服务器一起工作......和 2. 找出学校的 FTP 服务器到底是什么（10 美元说它是一些教授自制的超高性能的非标准 extretia），然后看看你是否可以确认这是该实施的一个已知问题......如果不是，则向作者提交错误报告。

我只是猜测这是教授的“尾巴扭曲”......看看谁能够接受“现实世界的挑战”。

干杯。基思。