ZMODEM - ZMODEM

ZMODEM
Protocolo de comunicação
Objetivo protocolo de transferência de arquivos
Desenvolvedor (s) Chuck Forsberg
Introduzido 1986 ; 34 anos atrás ( 1986 )
Porta (s) Nenhum
Hardware modems

ZMODEM é um protocolo de transferência de arquivos desenvolvido por Chuck Forsberg em 1986, em um projeto financiado pela Telenet para melhorar as transferências de arquivos em sua rede X.25 . Além de melhorar drasticamente o desempenho em comparação com os protocolos mais antigos, o ZMODEM oferecia transferências reinicializáveis, inicialização automática pelo remetente, um CRC de 32 bits expandido e cotação de caracteres de controle com suporte a transferências limpas de 8 bits , permitindo que fosse usado em redes que não passar caracteres de controle.

Em contraste com a maioria dos protocolos de transferência desenvolvidos para sistemas de quadro de avisos (BBSs), o ZMODEM não foi diretamente baseado nem compatível com o XMODEM seminal . Muitas variantes do XMODEM foram desenvolvidas para resolver uma ou mais de suas deficiências, e a maioria permaneceu compatível com as versões anteriores e completaria com êxito as transferências com as implementações "clássicas" do XMODEM. Esta lista inclui o YMODEM do próprio Forsberg .

ZMODEM evitou a compatibilidade com versões anteriores em favor de produzir um protocolo radicalmente melhorado. Ele teve um desempenho tão bom ou melhor do que qualquer uma das variedades de alto desempenho de XMODEM, fez isso em links que anteriormente não funcionavam, como o X.25, ou tinha um desempenho ruim, como modems Telebit , e incluía recursos úteis encontrados em poucos ou nenhum outro protocolo. O ZMODEM se tornou extremamente popular em sistemas de BBS (BBS) no início dos anos 1990, tornando-se um padrão tão difundido quanto o XMODEM havia sido antes dele.

Melhorias

Transmissão

Geralmente, os protocolos de transferência de arquivos dividem um arquivo em uma série de pacotes e os enviam um de cada vez para o receptor. A parte principal do pacote, a carga útil , é um certo número de bytes do arquivo que está sendo enviado. Após a carga, vem uma soma de verificação ou verificação de redundância cíclica (CRC) que pode ser usada para determinar se a carga foi recebida corretamente. Se o pacote for recebido corretamente, o receptor enviará uma mensagem ACK e o remetente começará a enviar o próximo pacote.

O sistema telefônico apresenta um pequeno atraso conhecido como latência, que interfere nesse processo. Mesmo que o receptor envie o ACK imediatamente, o atraso nas linhas telefônicas significa que sempre haverá algum tempo antes que o remetente o receba e envie o próximo pacote. À medida que a velocidade do modem aumenta, esse atraso representa um número cada vez maior de pacotes que poderiam ter sido enviados durante o atraso, diminuindo a eficiência do canal .

O XMODEM usou payloads de 128 bytes com um cabeçalho de três bytes e uma soma de verificação de um byte para um total de 132 bytes por pacote. Na era de 300 modems bps, um pacote levou cerca de quatro segundos para enviar e latências típicos foram da ordem de 1 / 10 de um segundo, então a sobrecarga de desempenho não foi significativa. Conforme as velocidades aumentam, o problema se torna mais problemático; em 2400 bps um pacote leva cerca de 1 / 2 para enviar, por isso cerca de 1 / 5 da largura de banda disponível é desperdiçada à espera de ACK s. Em 9600 bps um pacote requer apenas 0,13 segundos para enviar, por isso cerca de 1 / 2 da largura de banda é desperdiçada.

Uma solução para esse problema é o uso de uma janela deslizante . Esses protocolos resolvem a latência permitindo que o remetente continue enviando vários pacotes sem esperar por um ACK . O número de pacotes que permite continuar é a "janela", que normalmente fica entre dois e dezesseis pacotes na maioria das implementações. Uma série de novas versões de XMODEM com suporte para janela deslizante apareceram no início dos anos 1980.

As janelas deslizantes são úteis para latências da ordem de vários comprimentos de pacote, que é o caso do XMODEM em linhas telefônicas convencionais. No entanto, não é suficiente lidar com latências mais longas encontradas em chamadas telefônicas internacionais ou serviços X.25, como PC Pursuit , onde as latências são da ordem de um segundo ou mais. Em outros casos, em que o canal reverso era muito mais lento do que o de envio, como era o caso dos modems Telebit ou US Robotics , mesmo o pequeno número de ACKs poderia sobrecarregar o canal de retorno e fazer com que a transferência pausasse.

ZMODEM abordado estes problemas, removendo a necessidade de ACK s de todo, permitindo que o remetente para enviar dados continuamente desde que o receptor não detectou erros. Apenas NAKs tinham que ser enviados, se e somente se houvesse um problema. Como o ZMODEM era frequentemente usado em links com correção de erros embutida, como o X.25, o receptor frequentemente não enviava uma única mensagem de volta ao remetente. Como resultado, o sistema enviaria o arquivo inteiro em um fluxo contínuo, e o ZMODEM se referia a si mesmo como um "protocolo de fluxo".

O desempenho do ZMODEM foi tão melhorado em relação aos protocolos comuns anteriores que geralmente substituiu até mesmo os protocolos especiais como o YMODEM-g , que não incluía nenhuma correção de erro e, em vez disso, contava com links sem erros mantidos pelos modems. Embora o YMODEM-g fosse mais rápido, a falta de outros recursos, como transferências reinicializáveis, o tornava menos atraente.

Reiniciar

O XMODEM e a maioria dos protocolos baseados nele gerenciavam a ordem dos pacotes prefixando os dados com um número de pacote de 1 a 255. As versões em janela usavam esse número de pacote para indicar quais pacotes foram recebidos corretamente ou especificar um que não o foi. Como os pacotes tinham 128 bytes, isso significava que a quantidade máxima de dados que poderia ser transferida antes que os números dos pacotes fossem transferidos era de 32 kB.

O ZMODEM substituiu o número do pacote pelo local real no arquivo, indicado por um número de 32 bits. Isso permitiu o envio de mensagens NAK que refaziam a transferência até o ponto de falha, independentemente do tamanho do arquivo. Esse mesmo recurso também foi usado para reiniciar as transferências em caso de falha ou interrupção deliberada. Nesse caso, o receptor veria quantos dados foram recebidos anteriormente e enviaria um NAK com esse local, acionando automaticamente o remetente para iniciar a partir desse ponto.

Começo automático

Gerenciamento simplificado de inicialização automática, permitindo que a máquina de envio inicie a transferência. Anteriormente, o usuário precisava primeiro solicitar o arquivo do remetente, colocando-o em um estado de "espera", depois retornar ao programa local e chamar um comando para iniciar a transferência. Com a transferência automática, eles simplesmente solicitaram o arquivo, o remetente acionaria automaticamente a transferência no programa do usuário.

Variações

Uma série de versões modificadas do ZMODEM apareceram. ZedZap era uma variante do ZMODEM com blocos de 8 kbyte para melhor desempenho em modems de alta velocidade. LeechZmodem era uma variante maliciosa do ZMODEM (entre os derivados XMODEM e YMODEM semelhantes) que enganava as cotas de download do BBS . Uma extensão compatível com versões anteriores do ZMODEM com comprimentos de bloco de 32 kbyte e 64 kbyte foi criada pela ADONTEC em 2002 e 2007 para aumentar o desempenho em conexões livres de erros de alta velocidade como redes ISDN ou TCP / IP.

As implementações de ZMODEM mais notáveis ​​foram da Omen Technology, Inc. de Chuck Forsberg, incluindo DSZ (DOS Send ZMODEM), GSZ (Graphical Send ZMODEM) e o ubíquo (l) rzsz para variantes do Unix.

Em tempos mais atuais, os desenvolvedores do Synchronet criaram uma implementação X / Y / ZMODEM moderna chamada SEXYZ, vagamente baseada no pacote zmtx / zmrx, que roda nativamente em variantes do Windows e Unix, suporta nomes de arquivo longos e transferências de dados mais rápidas e confiáveis . A implementação ZMODEM do SEXYZ também foi incorporada ao projeto SyncTERM. Synchronet, SEXYZ e SyncTERM são todos projetos de código aberto, plataforma cruzada e centrados em BBS.

O próprio Forsberg coletou uma série de melhorias no ZMODEM-90. O primeiro deles é o MobyTurbo, que removeu o controle citando para melhorar ainda mais o desempenho, cerca de 15%. Mesmo em redes que "comem" caracteres de controle, o ZMODEM-90 pode ser adaptado para citar apenas os caracteres que a rede realmente come, ao contrário de todos os possíveis. Uma melhoria semelhante permite que o ZMODEM-90 funcione em redes de 7 bits, enquanto os protocolos anteriores (com a notável exceção do Kermit ) exigiam 8 bits em um grau ou outro. Finalmente, ZMODEM-90 inclui um sistema básico de compressão de codificação de duração para melhorar ainda mais o desempenho em arquivos não compactados.

Limitações

  • Alguns dos pacotes ZMODEM (por exemplo, ZACK, ZRPOS) incorporam um deslocamento de byte no arquivo transferido como um inteiro não assinado de 32 bits. Este design limita a viabilidade do ZMODEM para apenas transferir arquivos de forma confiável com menos de 4 GB.
  • Mesmo que o protocolo pudesse permitir, a implementação de referência (l) rzsz não pode codificar caracteres arbitrários de não controle (por exemplo, '~') que são frequentemente usados ​​por programas de conexão TCP / IP como telnet e ssh como "escape de terminal" do lado do cliente personagens. Os usuários devem desabilitar o recurso de escape do terminal para obter transferências confiáveis ​​sobre esses tipos de links, por exemplo, ssh -e none user @ hostname.

Referências

links externos