Python:ftplib 在传输结束时挂起

Question

我已经搜索了几天，但还没有找到答案。

我尝试从 FTP 下载视频文件，我的脚本检查服务器，将 nlist() 与从文本文件解析的已下载文件列表进行比较，然后创建一个新的文件列表以获取并迭代它下载每个文件，断开与服务器的连接并重新连接下一个文件(我认为服务器超时可能是一个问题所以我在每次文件下载后退出()连接)。

这适用于前几个文件，但一旦我找到一个超过 5 分钟的文件，fitlib 就会在传输结束时挂起(我可以在资源管理器中看到文件大小正确，因此下载已经完成，但它似乎没有收到消息并转到下一个文件)

任何帮助将不胜感激，我的代码如下:

newPath = "Z:\\pathto\\downloads\\"

for f in getFiles:
    print("Getting " + f)

for f in getFiles:

    fil = f.rstrip()
    ext = os.path.splitext(fil)[1]
    if ext in validExtensions:
        print("Downloading new file: " + fil)
        downloadFile(fil, newPath)

这里是download.py

from ftplib import FTP
def downloadFile(filename, folder):
    myhost = 'host'
    myuser = 'user'
    passw = 'pass'
    #login
    ftp = FTP(myhost,myuser,passw)
    localfile = open(folder + filename, 'wb')
    ftp.retrbinary("RETR " + filename, localfile.write, 1024)
    print("Downloaded " + filename)
    localfile.close()
    ftp.quit()

Answer 1

没有更多信息，我实际上无法调试您的问题，所以我只能建议最笼统的答案。这对您来说可能不是必需的，但对任何人来说可能就足够了。

retrbinary 将阻塞直到整个文件完成。如果超过 5 分钟，则在整个 5 分钟内不会通过控制 channel 发送任何内容。您的客户端正在超时控制 channel ，或者服务器正在超时。因此，当您尝试使用 ftp.quit() 挂断时，它要么永远挂起，要么引发异常。

您可以使用 FTP 上的 timeout 参数来控制您一方的超时构造函数。某些服务器支持 IDLE 命令以允许您设置服务器端超时。但是，即使合适的超时被证明是可行的，您如何首先选择合适的超时？

您真正想要做的是防止控制套接字在数据套接字上发生传输时超时。但是怎么办？例如，如果您经常在回调函数中使用 ftp.voidcmd('NOOP')，这就足以保持连接处于事件状态……但它也会迫使您阻塞，直到服务器响应 NOOP，许多服务器在数据传输完成之前不会执行此操作，这意味着您将永远阻塞(或直到不同的超时)并且无法获取数据。

处理两个套接字而不阻塞另一个套接字的标准技术是多路复用器，如 select.select 或线程。您可以在此处执行此操作，但您将不得不放弃使用简单的 retrbinary 接口(interface)，而是使用 transfercmd 显式获取数据套接字。

例如:

def downloadFile(…):
    ftp = FTP(…)
    sock = ftp.transfercmd('RETR ' + filename)
    def background():
        f = open(…)
        while True:
            block = sock.recv(1024*1024)
            if not block:
                break
            f.write(block)
        sock.close()
    t = threading.Thread(target=background)
    t.start()
    while t.is_alive():
        t.join(60)
        ftp.voidcmd('NOOP')

---

另一种解决方案是一次读取 20MB，然后调用 ftp.abort()，并使用 rest 参数恢复传输每个新的 retrbinary 直到到达文件末尾。然而，ABOR 可能会永远挂起，就像 NOOP 一样，所以这并不能保证任何事情——更不用说服务器不必响应它了。

您可以 做的只是关闭整个连接(不是退出，而是关闭)。这对服务器来说不是很好，并且可能会导致重新发送一些浪费的数据，并且如果您过快地终止套接字，也可能会阻止 TCP 正常加速到全速。但它应该有效。

参见 this answer — 请注意，它需要针对您的特定损坏的服务器进行一些测试，以确定哪些变体(如果有的话)可以正确有效地工作。