ftplib python: el comando NOOP funciona en ASCII no en binario

multithreading sockets

Question

Tengo un script FTP enhebrado. Mientras el zócalo de datos recibe los datos, un bucle enhebrado envía comandos de NOOP al zócalo de control para mantener viva la conexión de control durante transferencias grandes.

Se me impide usar el FTP.retrbinary() ya que, si deseo mantener viva la conexión de control, debo separar los datos y los sockets de control que no funciona con el retrbinary .

Código a continuación:

def downloadFile(filename, folder):
    myhost = ''HOST''
    myuser = ''USER''
    passw = ''PASS''
    #login
    ftp = FTP(myhost,myuser,passw)

    ftp.set_debuglevel(2)
    ftp.voidcmd(''TYPE I'')
    sock = ftp.transfercmd(''RETR '' + filename)
    def background():
        f = open(folder + filename, ''wb'')
        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(120)
        ftp.voidcmd(''NOOP'')
    ftp.quit();

Mi PROBLEMA : FTP.transfercmd("RETR " + filename) predeterminado en las transferencias ASCII y estoy transfiriendo video así que tiene que ser Binario (de ahí la ftp.voidcmd(''TYPE I) para forzar el modo Binario).

Si NO ftp.voidcmd(''TYPE I) a ftp.voidcmd(''TYPE I) los comandos de NOOP se envían correctamente y la salida es la siguiente:

*cmd* ''NOOP''
*put* ''NOOP/r/n''
*get* ''200 NOOP: data transfer in progress/n''
*resp* ''200 NOOP: data transfer in progress''
*cmd* ''NOOP''
*put* ''NOOP/r/n''
*get* ''200 NOOP: data transfer in progress/n''
*resp* ''200 NOOP: data transfer in progress''
*cmd* ''NOOP''
*put* ''NOOP/r/n''
*get* ''200 NOOP: data transfer in progress/n''
*resp* ''200 NOOP: data transfer in progress''

etc. Pero el archivo está en ASCII y por lo tanto está dañado. Si ftp.voidcmd(''TYPE I) llamo a ftp.voidcmd(''TYPE I) , el comando NOOP solo envía una vez, y el socket de control no responde hasta que la transferencia se complete. Si el archivo es grande, el socket de control expira como si los NOOP nunca se hubieran enviado ...

Muy extraño, pero estoy seguro de que es simple. Parece que transfercmd() no está dividiendo el control y los sockets de datos como se supone que debe ... y, por lo tanto, el ftp var no está separado de la secuencia de datos ... o algo así. extraño.

Gracias de antemano por cualquier consejo que usted puede ofrecer.

Answer 1

tcpdump confirma que el servidor solo envía 226 Transfer complete. después de que el servidor haya enviado todo el archivo.

Sospecho que eso es parte de la especificación de FTP.

De hecho, mira el código ftplib.py en ftplib.py :

    self.voidcmd(''TYPE I'')
    conn = self.transfercmd(cmd, rest)
    while 1:
        data = conn.recv(blocksize)
        if not data:
            break
        callback(data)
    conn.close()
    return self.voidresp()

La última línea espera obtener el resultado de la transferencia (como lo conoce el servidor) solo después de que se complete la transferencia.

De hecho, parece que su código no voidresp() bit voidresp() .

No estoy muy familiarizado con ftp, por lo que he visto, los descargadores en segundo plano como lftp realidad abren una nueva conexión de control para cada descarga paralela.

Usted tiene una preocupación válida si su archivo es realmente grande.

Hay muchas extensiones para FTP, puede haber algo que hace lo que quiere.

Alternativamente, puede hacer que un bucle le guste así:

pos = 0
while not full file:
    command REST
    download for a while in separate thread
    command ABRT
    wait for separate thread to abort
    pos += length of downloaded chunk