Resumo

  • Na RFC 1068, a interface gravava uma operação FTP em uma fila persistente e o daemon FTC tentava executá-la mais tarde entre dois servidores. O submit preservava a instrução depois da saída do usuário; não comprovava o deslocamento do arquivo.
  • Em pedidos com vários arquivos, o primeiro NLST bem-sucedido congelava a composição e um ponteiro mantinha o progresso parcial. O pedido terminava tanto por sucesso integral quanto por falha permanente ou esgotamento das tentativas, tornando indispensável o resultado por item.

O problema descrito pela RFC 1068 não começava com um pacote malformado. Começava com alguém obrigado a permanecer diante de um terminal. O FTP em primeiro plano deixava com o usuário a tarefa de perceber uma indisponibilidade e repetir a operação. À medida que congestionamentos, atrasos e quedas se tornavam mais comuns, a presença humana passava a fazer parte do mecanismo de recuperação.

O BFTP separou essa presença da sessão. Uma interface recolhia o pedido; um file transfer control daemon, o FTC, guardava, programava e tentava cumpri-lo. O memorando queria provocar discussão e não criava um novo protocolo. A novidade estava em uma camada de estado ao redor do FTP: fila, agenda, repetição, progresso parcial e aviso por correio.

Havia uma máquina para lembrar e duas para transferir

Origem, destino e controle podiam ser três hosts diferentes. O usuário informava nomes, credenciais e caminhos dos dois servidores. Escolhia copiar, mover ou apagar na origem, criar, substituir, anexar ou gerar nome único no destino, além de tipo, modo e estrutura do FTP. Um curinga podia abranger muitos arquivos. A primeira tentativa podia ficar marcada para outro horário.

Depois de indicar a caixa postal para o resultado, o usuário executava submit. A interface já não precisava permanecer aberta. O registro que sobrevivia reunia parâmetros, horário, política e endereço de notificação. Ele dizia que o controlador aceitara uma intenção. Não dizia que os hosts estavam disponíveis, que a autenticação funcionaria, que o canal de dados existia ou que o destino continha uma cópia completa.

O comando verify era útil justamente por ser limitado. Quando os hosts respondiam, podia abrir sessões, validar parâmetros e verificar a presença da origem. Se uma máquina estivesse fora do ar, nem todos os testes eram possíveis. E um resultado favorável precedia o submit e a tentativa real. Era evidência sobre aquele instante, não uma reserva de conectividade, permissão ou espaço futuro.

O controlador dava ordens a um caminho que o contornava

O BFTP compunha o FTP de terceiros definido na RFC 959. O FTC abria uma conexão de controle com cada servidor. Solicitava PASV de um lado, passava o endereço e a porta ao outro por PORT e coordenava RETR com STOR. A conexão de dados corria diretamente da origem ao destino. Os bytes não atravessavam o host que mantinha a fila.

Por isso, o sistema produzia provas distintas. A fila guardava o que se desejava. Os controles registravam as ordens e as respostas dos dois servidores. O canal de dados carregava o conteúdo. A RFC 959 exigia controles abertos durante a operação e uma resposta final 226 ou 250 antes da próxima transferência. Conexão aberta, resposta preliminar ou fechamento do canal de dados, isoladamente, não encerravam a verdade do arquivo.

Esse arranjo também dependia de implementações pouco uniformes. Pelo menos um servidor precisava aceitar PASV. O relatório menciona saídas NLST fora do padrão, respostas malformadas e servidores que classificavam uma conexão quebrada como 5xx permanente em vez de 4xx temporário. Uma fila pode insistir, mas sua política será tão correta quanto a linguagem de falha recebida.

A repetição pertencia ao serviço, não à conexão anterior

Depois de uma falha temporária, o daemon anotava o evento, esperava e abria novas sessões. A implementação apresentada começava, por exemplo, perto de dez minutos, dobrava o intervalo e parava de aumentá-lo por volta de quatro horas. Esses valores descreviam uma escolha local, não constantes do protocolo.

As famílias 4yz e 5yz da RFC 959 decidiam a sequência. Uma resposta 4yz indicava que a ação não ocorrera, mas que o mesmo pedido podia ser tentado novamente. Uma 5yz desencorajava a repetição sem mudança. Classificar uma queda de comunicação como permanente podia eliminar uma oportunidade recuperável; chamar de temporária uma condição definitiva podia manter um trabalho sem saída.

Havia limites para essa paciência. Sucesso, falha permanente ou máximo de tentativas levavam o trabalho ao fim e geravam correio. A chegada da mensagem provava que o controlador encerrara o fluxo. Ainda era necessário ler se a mensagem relatava entrega ou abandono.

O primeiro inventário válido impedia que o lote crescesse sozinho

Um curinga muda de significado quando o diretório muda. Se cada repetição fizesse um novo NLST, arquivos criados depois poderiam entrar no trabalho antigo, enquanto outros desapareceriam. O BFTP guardava a lista da primeira execução bem-sucedida de NLST. Essa fotografia fixava os membros; novidades posteriores ficavam de fora.

O lote fixo não era uma transação atômica. Se quatro arquivos chegassem e o quinto falhasse, o sistema não apagava as quatro cópias para voltar ao início. Um ponteiro registrava o que já tinha dado certo, e os ciclos seguintes se limitavam aos pendentes. A economia de repetição criava um estado misto: parte entregue, parte ainda em dúvida ou definitivamente perdida.

Nesse contexto, “completo” não era sinônimo de êxito. A RFC 1068 concluía um pedido quando todos os itens terminavam bem, quando surgia uma falha permanente ou quando acabavam as tentativas. Completo queria dizer que o daemon não programaria mais trabalho. A relação por arquivo no aviso era a única forma de distinguir vitória integral, resultado parcial e fracasso.

Uma palavra-chave oferecia busca, não identidade forte

O usuário associava uma palavra ao pedido para encontrá-lo e cancelá-lo depois. Os autores chamaram o recurso de autenticação fraca. Duas pessoas que escolhessem a mesma palavra poderiam examinar ou cancelar trabalhos alheios. Um e-mail de cancelamento documentava o ato depois de ocorrido, mas não concedia autoridade antes dele.

A escolha do alvo de uma conexão de terceiros ganhou outra fronteira mais tarde. A RFC 2577 explicou como a autoridade de PORT no FTP proxy podia fazer um servidor conectar-se a outro serviço, o ataque bounce, e como certas restrições sacrificavam a função proxy. Isso não comprova um incidente no BFTP. Demonstra apenas que o controlador exercia uma capacidade relevante mesmo sem transportar os bytes.

O alcance histórico é específico

A RFC 1068 relata alguns meses de uso no ISI. Não sustenta adoção generalizada nem uma linhagem direta até filas modernas. A RFC 959 estabelece a separação entre controle e dados e o sentido das respostas; a RFC 2577 registra uma preocupação de segurança posterior. Nenhuma fonte prova uma entrega determinada, a proteção das senhas ou um sistema atual.

A lição durável é uma distinção de evidência. Tornar a intenção persistente melhora a possibilidade de tentar outra vez, mas cria uma segunda máquina de estados. A fila pode dizer o que deveria ser feito. Somente o registro de cada arquivo pode dizer o que de fato ocorreu.