XMODEM - XMODEM

XMODEM
Protocolo de comunicação
Propósito protocolo de transferência de arquivos
Desenvolvedor (s) Ward Christensen
Introduzido 1977 ; 44 anos atrás ( 1977 )
Influenciado YMODEM , muitos outros
Hardware modems

XMODEM é um protocolo de transferência de arquivo simples desenvolvido como um hack rápido por Ward Christensen para uso em seu programa de terminal 1977 MODEM.ASM . Ele permitia que os usuários transmitissem arquivos entre seus computadores quando ambos os lados usassem o MODEM. Keith Petersen fez uma pequena atualização para sempre ativar o "modo silencioso" e chamou o resultado de XMODEM.

O XMODEM, como a maioria dos protocolos de transferência de arquivos, divide os dados originais em uma série de " pacotes " que são enviados ao receptor, junto com informações adicionais que permitem ao receptor determinar se o pacote foi recebido corretamente. Se for detectado um erro, o receptor solicita que o pacote seja reenviado. Uma sequência de pacotes inválidos faz com que a transferência seja abortada.

O XMODEM se tornou extremamente popular no mercado inicial de BBS ( sistema de quadro de avisos ), principalmente porque era simples de implementar. Também era bastante ineficiente e, à medida que a velocidade do modem aumentava, esse problema levou ao desenvolvimento de várias versões modificadas do XMODEM para melhorar o desempenho ou resolver outros problemas com o protocolo. Christensen acreditava que seu XMODEM original era "o programa mais modificado da história da computação".

Chuck Forsberg coletou uma série de modificações comuns em seu protocolo YMODEM , mas a implementação ruim levou a uma nova fratura antes de serem reunificados por seu protocolo ZMODEM posterior . ZMODEM se tornou muito popular, mas nunca substituiu completamente o XMODEM no mercado de BBS.

Estrutura do pacote

O XMODEM original utilizado um pacote de dados de 128 bytes, o tamanho do bloco básico usado no CP / M disquetes . O pacote era prefixado por um cabeçalho simples de 3 bytes contendo um caractere, um "número do bloco" de 0 a 255 e o número do bloco "inverso" - 255 menos o número do bloco. A numeração de bloco começa com 1 para o primeiro bloco enviado, não 0. O cabeçalho foi seguido pelos 128 bytes de dados e, em seguida, por uma soma de verificação de byte único . O pacote completo tinha, portanto, 132 bytes de comprimento, contendo 128 bytes de dados de carga útil , para uma eficiência de canal total de cerca de 97%. <SOH>

A soma de verificação era a soma de todos os bytes no módulo do pacote 256. A operação do módulo foi facilmente calculada descartando todos os bits menos significativos do resultado, exceto os oito , ou alternativamente em uma máquina de oito bits, ignorando o estouro aritmético que produziria o mesmo efeito automaticamente. Dessa forma, a soma de verificação foi restrita a uma quantidade de oito bits. Por exemplo, se esse método de checksum foi usado em um pequeno pacote de dados contendo apenas dois bytes carregando os valores 130 e 130, o total desses códigos é 260 e o checksum resultante é 4.

O arquivo foi marcado como "completo" com um caractere enviado após o último bloco. Este caractere não estava em um pacote, mas enviado sozinho como um único byte. Como o comprimento do arquivo não foi enviado como parte do protocolo, o último pacote foi preenchido com um "caractere conhecido" que poderia ser descartado. Na especificação original, o padrão era 26 decimal, que CP / M usava como marcador de fim de arquivo dentro de seu próprio formato de disco. O padrão sugeria que qualquer caractere poderia ser usado para preenchimento, mas não havia como ele ser alterado dentro do próprio protocolo - se uma implementação alterasse o caractere de preenchimento, apenas clientes usando a mesma implementação interpretariam corretamente o novo caractere de preenchimento. <EOT><SUB>

Detalhes da transferência

Os arquivos foram transferidos um pacote por vez. Quando recebido, a soma de verificação do pacote era calculada pelo receptor e comparada com a recebida do remetente no final do pacote. Se os dois coincidissem, o receptor enviava uma mensagem de volta ao remetente, que então enviava o próximo pacote em sequência. Se houvesse um problema com a soma de verificação, o destinatário enviaria um . Se a fosse recebido, o remetente reenviava o pacote e continuava a tentar várias vezes, normalmente dez, antes de abortar a transferência. <ACK><NAK><NAK>

Um <NAK>também era enviado se o receptor não recebesse um pacote válido em dez segundos enquanto esperava dados devido à falta de um <EOT>caractere. Um tempo limite de sete segundos também foi usado em um pacote, protegendo contra conexões perdidas no meio do pacote.

Os números dos blocos também foram examinados de forma simples para verificação de erros. Depois de receber um pacote com sucesso, o próximo pacote deve ter um número superior. Se, em vez disso, ele recebeu o mesmo número de bloco, isso não foi considerado grave, estava implícito que o <ACK>não havia sido recebido pelo remetente, que então reenviou o pacote. Qualquer outro número de pacote sinalizou que os pacotes foram perdidos.

As transferências eram conduzidas pelo receptor; o transmissor não enviaria nenhum dado até que uma inicial <NAK>fosse enviada pelo receptor. Esse era um resultado lógico da maneira como o usuário interagia com a máquina de envio, que seria localizada remotamente. O usuário navegaria até o arquivo solicitado na máquina de envio e, em seguida, pediria a essa máquina para transferi-lo. Uma vez que esse comando fosse emitido, o usuário executaria um comando em seu software local para começar a receber. Como o atraso entre solicitar o arquivo ao sistema remoto e emitir um comando local para recebimento era desconhecido, o XMODEM permitia até 90 segundos para que o receptor começasse a emitir solicitações de pacotes de dados.

Problemas

Embora o XMODEM fosse robusto o suficiente para um jornalista em 1982 transmitir histórias do Paquistão para os Estados Unidos com um Osborne 1 e acoplador acústico em linhas telefônicas de baixa qualidade, o protocolo tinha várias falhas.

Problemas insignificantes

XMODEM foi escrito para máquinas CP / M e possui várias marcas desse sistema operacional . Notavelmente, os arquivos em CP / M eram sempre múltiplos de 128 bytes e seu final era marcado dentro de um bloco com o <EOT>caractere. Essas características foram transplantadas diretamente para o XMODEM. No entanto, outros sistemas operacionais não apresentavam nenhuma dessas peculiaridades, e a introdução generalizada do MS-DOS no início dos anos 1980 fez com que o XMODEM tivesse que ser atualizado para notar um <EOT> ou <EOF> como o marcador de fim de arquivo.

Por algum tempo, foi sugerido que o envio de um <CAN>caractere em vez de um <ACK>ou <NAK>deveria ser suportado para abortar facilmente a transferência da extremidade receptora. Da mesma forma, um <CAN>recebido no lugar do <SOH>indicado, o remetente deseja cancelar a transferência. No entanto, esse caractere poderia ser facilmente "criado" por meio de erros simples relacionados ao ruído do que deveria ser um <ACK>ou <NAK>. Um duplo <CAN>foi proposto para evitar esse problema, mas não está claro se isso foi amplamente implementado.

Problemas principais

XMODEM foi projetado para simplicidade, sem muito conhecimento de outros protocolos de transferência de arquivos - que eram bastante raros de qualquer maneira. Devido à sua simplicidade, havia uma série de erros básicos que poderiam causar uma falha na transferência ou, pior, resultar em um arquivo incorreto que passava despercebido pelo protocolo. A maior parte disso foi devido ao uso de uma soma de verificação simples para correção de erros, que é suscetível a erros ausentes nos dados se dois bits forem invertidos, o que pode acontecer com uma rajada de ruído adequadamente curta. Além disso, danos semelhantes ao cabeçalho ou soma de verificação podem levar a uma falha na transferência nos casos em que os próprios dados não foram danificados.

Muitos autores introduziram extensões para XMODEM para resolver esses e outros problemas. Muitos pediram que essas extensões fossem incluídas como parte de um novo padrão XMODEM. No entanto, Ward Christensen se recusou a fazer isso, pois foi precisamente a falta desses recursos e a codificação associada necessária para suportá-los que levou ao uso generalizado do XMODEM. Como ele explicou:

Foi um hack rápido que fiz, muito não planejado (como tudo que faço), para satisfazer uma necessidade pessoal de me comunicar com outras pessoas. SÓ o fato de ter sido feito em 8/77, e de ter colocado em domínio público imediatamente, fez com que se tornasse o padrão que é ...
... As pessoas que sugerem que eu faça mudanças SIGNIFICATIVAS no protocolo, como 'full duplex', 'vários blocos pendentes', 'vários destinos', etc etc, não entendem que a incrível simplicidade do protocolo é uma das razões ele sobreviveu.

Transferências em lote

Outro problema com o XMODEM era que ele exigia que a transferência fosse orientada pelo usuário em vez de automatizada. Normalmente, isso significava que o usuário navegaria no sistema do remetente para selecionar o arquivo desejado e, em seguida, usaria um comando para colocar esse sistema no modo "pronto para enviar". Em seguida, eles acionariam a transferência de sua extremidade usando um comando em seu emulador de terminal. Se o usuário quisesse transferir outro arquivo, teria que repetir o processo novamente.

Para transferências automatizadas entre dois sites, vários add-ons para o protocolo XMODEM foram implementados ao longo do tempo. Geralmente, presume-se que o remetente continuará enviando arquivo após arquivo, com o receptor tentando acionar o próximo arquivo enviando um NAK normalmente no início de uma transferência. Quando o NAK expirou, pode-se presumir que não havia mais arquivos ou que o link foi quebrado de qualquer maneira.

MODEM7

MODEM7 , também conhecido como lote MODEM7 ou lote XMODEM , foi a primeira extensão conhecida do protocolo XMODEM. Uma transferência de arquivo XMODEM normal começa com o receptor enviando um único caractere NAK ao remetente, que então começa a enviar um único SOH para indicar o início dos dados e, em seguida, pacotes de dados.

O MODEM7 mudou esse comportamento apenas um pouco, enviando o nome do arquivo, no formato 8.3 , antes do <SOH>. Cada caractere foi enviado individualmente e teve que ser ecoado pelo receptor como uma forma de correção de erros. Para uma implementação XMODEM não ciente, esses dados seriam simplesmente ignorados enquanto aguardavam a chegada do SOH , para que os caracteres não fossem ecoados e a implementação pudesse retornar ao XMODEM convencional. Com software "ciente", o nome do arquivo pode ser usado para salvar o arquivo localmente. As transferências podem continuar com outro <NAK> , cada arquivo é salvo com o nome que está sendo enviado ao receptor.

Jerry Pournelle em 1983 descreveu o MODEM7 como "provavelmente o programa de comunicação de microcomputador mais popular que existe".

TeLink

O MODEM7 enviou o nome do arquivo como texto normal, o que significava que ele poderia estar corrompido pelos mesmos problemas que o XMODEM estava tentando evitar. Isso levou à introdução do TeLink por Tom Jennings , autor dos mailers originais da FidoNet .

O TeLink evitou os problemas do MODEM7 padronizando um novo "pacote zero" contendo informações sobre o arquivo original. Isso inclui o nome, tamanho e carimbo de data / hora do arquivo , que foram colocados em um bloco XMODEM regular de 128 bytes. Enquanto uma transferência XMODEM normal começaria com o remetente enviando "bloco 1" com um cabeçalho <SOH> , o pacote de cabeçalho TeLink era rotulado como "bloco 0" e começado com um <SYN> . O pacote continha a data e hora de criação do arquivo, o nome do arquivo com até 16 caracteres, o tamanho do arquivo como um valor de 4 bytes e o nome do programa que envia o arquivo.

Uma implementação normal de XMODEM simplesmente descartaria o pacote, supondo que o número do pacote foi corrompido. Mas isso levava a um possível atraso de tempo se o pacote fosse descartado, pois o remetente não poderia dizer se o receptor respondeu com um <NAK> porque não entendeu o pacote zero ou porque houve um erro de transmissão. Como o TeLink era normalmente usado apenas pelo software FidoNet , que o exigia como parte dos padrões FidoNet, isso não representava um problema do mundo real, pois ambas as extremidades sempre suportariam esse padrão.

O sistema básico "bloco 0" tornou-se um padrão na comunidade FidoNet e foi reutilizado por uma série de protocolos futuros como SEAlink e YMODEM .

XMODEM-CRC

A soma de verificação usada no protocolo original era extremamente simples e os erros no pacote podiam passar despercebidos. Isso levou à introdução do XMODEM-CRC por John Byrns, que usava um CRC de 16 bits no lugar da soma de verificação de 8 bits. Os CRCs codificam não apenas os dados no pacote, mas também sua localização, permitindo que percebam os erros de substituição de bits que uma soma de verificação não detectaria. Estatisticamente, isso tornava a chance de detectar um erro menor que 16 bits de 99,9999%, e ainda maior para cadeias de bits de erro mais longas.

O XMODEM-CRC foi projetado para ser compatível com versões anteriores do XMODEM. Para fazer isso, o destinatário enviou um caractere C(C maiúsculo) em vez de um <NAK>para iniciar a transferência. Se o remetente respondeu enviando um pacote, supôs-se que o remetente "conhecia" o XMODEM-CRC e o destinatário continuou a enviar C. Se nenhum pacote estivesse chegando, o receptor presumia que o remetente não conhecia o protocolo e enviava um <NAK>para iniciar uma transferência XMODEM "tradicional".

Infelizmente, essa tentativa de compatibilidade com versões anteriores teve uma desvantagem. Como era possível que o Ccaractere inicial fosse perdido ou corrompido, não se poderia presumir que o receptor não suportasse XMODEM-CRC se a primeira tentativa de acionar a transferência falhou. O receptor então tentou iniciar a transferência três vezes com C, esperando três segundos entre cada tentativa. Isso significava que, se o usuário selecionasse XMODEM-CRC ao tentar falar com qualquer XMODEM, conforme pretendido, haveria um atraso potencial de 10 segundos antes do início da transferência.

Para evitar o atraso, o remetente e o destinatário geralmente listam o XMODEM-CRC separadamente do XMODEM, permitindo que o usuário selecione o XMODEM "básico" se o remetente não o listar explicitamente. Para o usuário médio, o XMODEM-CRC era essencialmente um "segundo protocolo" e tratado como tal. No entanto, isso não era verdade para os mailers da FidoNet, onde o CRC foi definido como o padrão para todas as transferências TeLink.

Maior rendimento

Como o protocolo XMODEM exigia que o remetente parasse e esperasse por uma mensagem <ACK>ou <NAK>do receptor, ele tendia a ser bastante lento. Na era dos modems de 300 bit / s, todo o pacote de 132 bytes exigia pouco mais de 3,5 segundos para ser enviado (132 bytes * (8 bits por byte + 1 bit de início + 1 bit de parada) / 300 bits por segundo). Supondo que demore 0,2 segundos para que o receptor <ACK>volte ao remetente e o próximo pacote comece a atingir o receptor (0,1 segundo em ambas as direções), o tempo total para um pacote seria 3,7 segundos, pouco mais de 92% da taxa de transferência.

À medida que a velocidade do modem aumentava, o atraso fixo necessário para enviar <ACK>/ <NAK>aumentava proporcionalmente ao tempo necessário para enviar o pacote. Por exemplo, a 2.400 bits / s os pacotes levaram apenas 0,44 segundos para serem enviados, portanto, se <ACK>/ <NAK>ainda levasse 0,2 segundos para retornar (isso é latência na rede, não taxa de transferência), a taxa de transferência caiu para menos de 60%. A 9600 bit / s está abaixo de 30% - mais tempo é gasto esperando pela resposta do que o necessário para enviar o pacote.

Uma série de novas versões do XMODEM foram introduzidas para resolver esses problemas. Como as extensões anteriores, essas versões tendiam a ser compatíveis com as versões anteriores do XMODEM original e, como essas extensões, isso levou a uma fratura adicional do cenário XMODEM no emulador de terminal do usuário. No final, dezenas de versões do XMODEM surgiram.

WXModem

WXmodem , abreviação de "Windowed Xmodem", é uma variante do XMODEM desenvolvida por Peter Boswell em 1986 para uso em linhas de alta latência, especificamente sistemas X.25 públicos e PC Pursuit . Eles têm latências muito mais altas do que o serviço de telefone comum , o que leva a uma eficiência muito baixa em XMODEM. Além disso, essas redes costumam usar caracteres de controle para controle de fluxo e outras tarefas, principalmente XON / XOFF para interromper o fluxo de dados. Finalmente, no caso de um erro que exigia um reenvio, às vezes era difícil saber se um SOH era um indicador de pacote ou mais ruído. O WXmodem adaptou o XMODEM-CRC para resolver esses problemas.

Uma mudança foi escapar de um pequeno conjunto de caracteres de controle, DLE , XON , XOFF e SYN . Eles foram escapados inserindo um DLE na frente deles e, em seguida, modificando o caractere por XORing com 64. Em teoria, isso significava que o pacote poderia ter até 264 bytes se originalmente consistisse inteiramente de caracteres que exigiam escape. Esses caracteres inseridos e modificados não fazem parte do cálculo do CRC, eles são removidos e convertidos na extremidade receptora antes de calcular o CRC.

Além disso, todos os pacotes eram prefixados com um caractere SYN , o que significava que a entrada do pacote era SYN SOH , reduzindo a chance de que um SOH perdido fosse confundido com um cabeçalho de pacote em vários casos de erro. Um SYN sem escape encontrado no corpo de um pacote era um erro.

A principal mudança no WXMODEM é o uso de uma janela deslizante para melhorar a taxa de transferência em links de alta latência. Para fazer isso, as mensagens ACK eram seguidas do número do pacote que estavam acessando ou NAK . O receptor não precisa fazer o ACK em todos os pacotes, ele pode fazer o ACK em qualquer número entre um e quatro pacotes. Um ACK com o quarto número de sequência do pacote é considerado ACK em todos os quatro pacotes. Um erro faz com que um NAK seja enviado imediatamente, com todos os pacotes daquele número e depois de ser reenviado.

Exigir um ACK a cada quatro pacotes faz com que o sistema funcione como se tivesse um tamanho de pacote de 512 bytes, mas no caso de um erro, normalmente requer apenas 128 bytes para ser reenviado. Além disso, reduz a quantidade de dados que fluem na direção reversa em quatro vezes. Isso tem pouco interesse na operação full duplex típica do modem , mas é importante em sistemas half duplex como os modelos Telebit , que têm velocidade de 19 kB em uma direção e 75 bits / s no canal de retorno.

SEAlink

Um dos primeiros mailers de terceiros para o sistema FidoNet foi o SEAdog , escrito pelo mesmo autor do então popular formato de compressão de dados .arc . SEAdog incluiu uma ampla variedade de melhorias, incluindo SEAlink , um protocolo de transferência aprimorado baseado no mesmo conceito de janela deslizante do WXmodem. Ele diferia do WXmodem principalmente nos detalhes.

Uma diferença é que o SEAlink suportava o "pacote zero" introduzido pelo TeLink, que é necessário para operar como um substituto imediato para o TeLink nos sistemas FidoNet onde o cabeçalho era esperado. ACK s e o NAK s foram estendidas a três bytes "pacotes", começando com o ACK ou o NAK , em seguida, o número de pacotes, em seguida, o complemento do número de pacotes, na mesma forma que o cabeçalho do pacote XMODEM originais. O tamanho da janela era normalmente definido para seis pacotes.

Não se esperava que o SEAlink operasse em links X.25 ou semelhantes e, portanto, não executou o escape. Isso também era necessário para que o pacote zero funcionasse corretamente, já que esse padrão usava o caractere SYN que o WXmodem havia redefinido. Além dessas mudanças, ele adicionou um modo "Overdrive" para links half duplex. Isso suprimiu ACKs para pacotes que foram transferidos com sucesso, tornando a janela de tamanho infinito. Este modo foi indicado por uma bandeira no bloco zero.

O SEAlink posteriormente adicionou uma série de outras melhorias e foi um protocolo de uso geral útil. No entanto, permaneceu raro fora do mundo FidoNet e raramente foi visto em software voltado para o usuário.

XMODEM-1K

Outra maneira de resolver o problema de taxa de transferência é aumentar o tamanho do pacote. Embora o problema fundamental da latência permaneça, a velocidade com que ele se torna um problema é maior. O XMODEM-1K com pacotes de 1024 bytes foi a solução mais popular. Nesse caso, a taxa de transferência em 9600 bit / s é de 81%, dadas as mesmas suposições acima.

O XMODEM-1K era uma versão expandida do XMODEM-CRC, que indicava o tamanho do bloco mais longo no remetente , iniciando um pacote com o <STX>caractere em vez de <SOH>. Como outras extensões XMODEM compatíveis com versões anteriores, pretendia-se que uma transferência de -1K pudesse ser iniciada com qualquer implementação de XMODEM na outra extremidade, retirando recursos conforme necessário.

XMODEM-1K foi originalmente uma das muitas melhorias para XMODEM introduzidas por Chuck Forsberg em seu protocolo YMODEM . Forsberg sugeriu que as várias melhorias eram opcionais, esperando que os autores do software implementassem o maior número possível. Em vez disso, eles geralmente implementavam o mínimo, levando a uma profusão de implementações semicompatíveis e, eventualmente, a divisão do nome "YMODEM" em "XMODEM-1K" e uma variedade de YMODEMs. Assim, o XMODEM-1K na verdade é posterior ao YMODEM, mas permaneceu bastante comum de qualquer maneira.

NMODEM

NMODEM é um protocolo de transferência de arquivos desenvolvido por LB Neal, que o lançou em 1990. NMODEM é essencialmente uma versão do XMODEM-CRC usando blocos maiores de 2048 bytes, em oposição aos blocos de 128 bytes do XMODEM. NMODEM foi implementado como um programa separado, escrito em Turbo Pascal 5.0 para a família de computadores compatíveis com IBM PC . O tamanho do bloco foi escolhido para corresponder ao tamanho comum do cluster do sistema de arquivos FAT do MS-DOS em discos rígidos contemporâneos , tornando o armazenamento em buffer de dados para gravação mais simples.

Falsificação de protocolo

Em conexões confiáveis ​​(sem erros), é possível eliminar a latência "pré-reconhecendo" os pacotes, uma técnica conhecida mais geralmente como " spoofing de protocolo ". Isso normalmente é realizado no hardware de link, notavelmente modems Telebit. Os modems, quando a opção fosse ativada, notariam o cabeçalho XMODEM e imediatamente enviariam um ACK . Isso faria com que o programa XMODEM remetente enviasse imediatamente o próximo pacote, tornando a transferência contínua, como uma janela de tamanho infinito. Os modems também suprimem o ACK enviado pelo software XMODEM na extremidade oposta, liberando assim o canal de retorno de baixa velocidade.

O sistema também pode ser implementado no próprio protocolo, e variações do XMODEM ofereciam esse recurso. Nestes casos, o receptor enviaria o ACK assim que o pacote fosse iniciado, da mesma forma que os modems Telebit. Como esse recurso é apenas uma alteração do comportamento do lado do receptor, ele não requer nenhuma mudança no protocolo do lado do remetente. YMODEM formalizou este sistema.

Este conceito deve ser contrastado com aquele usado no SEAlink, que muda o comportamento em ambos os lados do link. No SEAlink, o receptor para de enviar o ACK inteiramente e o remetente muda seu comportamento para não esperá-los.

Veja também

Referências

Citações

Bibliografia

links externos