Como medir o progresso do upload de FTP no telnet

0

Estou trabalhando em um script usando telnet para se conectar a um servidor ftp e lançando um arquivo grande sobre ele.

Por causa do ambiente do projeto, eu preciso usar ftp e não posso confiar em outras técnicas como scp , rsync ou qualquer outra coisa.

Como posso saber o progresso do meu upload?

Eu posso mudar o lado do servidor entre pureftp e proftpd .

Eu tentei analisar o quão longe eu estou escrevendo para o canal de transferência, mas isso parece errado, já que está concluído muito antes de o arquivo estar no servidor. Então, eu gostaria de ter algum lado do servidor de feedback. Eu estava esperando encontrar algum comando mágico do STOR dando feedback sobre quantos dados foram realmente escritos.

Eu encontrei o comando STAT no proftpd, mas ele parece lento e precisa ser solicitado.

Existe uma maneira fácil de alcançar esse progresso?

Como funciona o feedback tradicional do HASH no ftp do lado do cliente?

    
por Vincent Duprez 01.02.2015 / 08:28

2 respostas

1

O comportamento que você está observando acontece porque, embora o cliente tenha gravado dados no soquete para a conexão de dados FTP e o kernel do cliente respondeu que isso aconteceu com êxito (retornando com êxito da chamada de sistema write() ou send() ), os dados ainda estão em todos os tipos de buffers e ainda não estão comprometidos com o arquivo de destino. É em buffers de rede no sistema operacional de origem, em buffers em placas ethernet, está em operação, está em buffers no destino, está nos buffers do processo do servidor FTP, foi gravado em um arquivo no servidor, mas não liberado para o disco, etc ...

Isso não acontece apenas com o FTP. Você pode facilmente perceber isso acontecendo com ferramentas de transferência de arquivos mais modernas, como scp também. scp um arquivo a meio do planeta (para uma rede de alta latência) ou para um sistema com armazenamento lento, e você verá que o progresso da transferência é mostrado mais rápido do que realmente é, então ele parece travar a 100% completo por um tempo antes que o comando seja realmente concluído.

Se você olhar o código-fonte para o netkit-ftp (o cliente FTP padrão / padrão no Debian), seu processamento de marca # não faz nada de especial. Ele grava as marcas de acordo com a quantidade de dados que gravou no soquete de conexão de dados. Assim, irá exibir o mesmo comportamento que você está observando.

O que os clientes FTP normais fazem e o que você deve fazer também é aguardar a resposta ao comando STOR na conexão de controle. Esta resposta virá algum tempo depois que você já tiver liberado e fechado o soquete de conexão de dados. Quando você recebe essa resposta, você sabe que o servidor FTP tem os dados. Pode não estar totalmente comprometido com o disco por lá, mas isso é o máximo de confirmação que você receberá.

    
por 01.02.2015 / 10:39
0

Se o seu cliente / servidor não mostrar progresso, você pode verificar o progresso do upload no lado do cliente, com base no progresso da leitura do arquivo.

  1. você tem tamanho do arquivo enviado
  2. você conhece o processo pid de qual arquivo de upload (por exemplo, 1234).
  3. você pode procurar em / proc / 1234 / fd - que fd pertence ao arquivo lido (por exemplo, 5).
  4. então - você pode olhar em / proc / 1234 / fdinfo / 5 - você vê aqui algo como
pos:    12313
flags:  0100002

Isso significa que a posição nesse arquivo é 12313 - então - se você dividir a posição (12313) pelo tamanho do arquivo - você tem um progresso geral.

    
por 01.02.2015 / 12:59