Columbia Kermit

home *** CD-ROM | disk | FTP | other *** search

/ Columbia Kermit / kermit.zip / misc / portpm.txt < prev next >

Wrap

Text File | 2020-01-01 | 235KB | 6,019 lines

.op KK KK EEEEEEEE RRRRRRRR MM MM IIII TTTTTTTTTT KK KK EE RR RR MMM MMM II TT KK KK EE RR RR MMMM MMMM II TT KK KKKK EEEEEE RRRRRRRR MM MMM MM II TT KKKK KK EE RR RR MM M MM II TT KK KK EE RR RR MM MM II TT KK KK EEEEEEEE RR RR MM MM IIII TT ____________________________________________________________ ____________________________________________________________ MM MM AAAAAA NN NN UU UU AAAAAA LL MMM MM AA AA NNN NN UU UU AA AA LL MMMM MMMM AA AA NNNN NN UU UU AA AA LL MM MMM MM AA AA NN NN NN UU UU AA AA LL MM M MM AAAAAAAA NN NN NN UU UU AAAAAAAA LL MM MM AA AA NN NNNN UU UU AA AA LL MM MM AA AA NN NN UUUUUUU AA AA LLLLLLL DDDDDDDDD OOOOOO DD DD OO OO DD DD OO OO DD DD OO OO DD DD OO OO DD DD OO OO DDDDDDDDD OOOOOO PPPPP RRRRR OOOO TTTTTT OOOO CCCC OOOO LL OOOO PP PP RR RR OO OO TT OO OO CC OO OO LL OO OO PP PP RR RR OO OO TT OO OO CC OO OO LL OO OO PPPPP RRRRR OO OO TT OO OO CC OO OO LL OO OO PP RR R OO OO TT OO OO CC OO OO LL OO OO PP RR RR OO OO TT OO OO CC OO OO LL OO OO PP RR RR OOOO TT OOOO CCCC OOOO LLLLL OOOO ____________________________________________________________ ____________________________________________________________ TELEBRAS * Quinta Edic,a~o * Brasi'lia, setembro de 1986 .pa MANUAL DO PROTOCOLO KERMIT Quinta Edic,a~o Frank da Cruz Columbia University Center for Computing Activities New York, NY, 10027 Copyright (C) 1981, 1982, 1983, 1984 Trustees of Columbia University in the City of New York Traduc,a~o de J. Ricardo B. Ghirlanda Telecomunicac,o~es Brasileiras S. A. - TELEBRAS Brasi'lia - DF, 1986 E' permitida e, mesmo, incentivada, a co'pia e divulgac,a~o de qualquer parte deste manual, desde que para fins na~o comerciais. .foKERMIT: Manual do Protocolo i I' N D I C E ---------------- Prefa'cio da Quarta Edic,a~o........................... 1 Quinta Edic,a~o....................................... 2 Mais algumas palavras............................... 2 Agradecimentos...................................... 2 Aviso............................................... 3 .cp4 1. Introduc,a~o.......................................... 4 .cp3 1.1. Cena'rio........................................ 4 .cp3 1.2. Visa~o Geral.................................... 4 .cp4 2. Definic,o~es.......................................... 6 .cp3 2.1. Terminologia Geral............................. 6 .cp3 2.2. Nu'meros........................................ 7 .cp3 2.3. Conjunto de Caracteres......................... 7 .cp3 2.4. Func,o~es de Conversa~o........................... 8 .cp3 2.5. Jarga~o do Protocolo............................ 8 .cp4 3. Requisitos de sistema............................... 10 .cp4 4. Texto Impri'mivel VERSUS Dados Bina'rios.............. 12 .cp3 4.1. Arquivos de Texto Imprimi'vel................... 12 .cp3 4.2. Arquivos Bina'rios.............................. 13 .cp4 5. Transfere^ncia de Arquivos........................... 14 .cp3 5.1. Condicionando o Terminal....................... 15 .cp3 5.2. Timeouts, NAKs e Retries....................... 15 .cp3 5.3. Erros.......................................... 16 .cp3 5.4. Heuri'stica..................................... 17 .cp3 5.5. Nomes de Arquivos.............................. 18 .cp3 5.6. Robustez....................................... 19 .cp3 5.7. Controle de Fluxo.............................. 19 .cp3 5.8. Tabela de Estados do Protocolo KERMIT Ba'sico... 20 .cp4 6. Formato dos Pacotes................................. 23 .cp3 6.1. Campos......................................... 23 .cp3 6.2. Terminador..................................... 24 .cp3 6.3. Outros dados inter-pacotes..................... 25 .cp3 6.4. Codificac,a~o, Prefixac,a~o, Checagem de Bloco..... 25 .cp4 7. Conexa~o Inicial..................................... 27 .cp4 8. Facilidades Opcionais............................... 32 .cp3 8.1. Prefixac,a~o de oitavo bit e contador de repetic,o~es......................... 32 .cp3 8.2. Operac,a~o de SERVER (Servidor).................. 34 8.2.1. Comandos SERVER......................... 35 8.2.2. Temporizac,a~o............................ 37 8.2.3. O Comando "R"........................... 37 8.2.4. Respostas Curtas e Respostas Longas..... 38 8.2.5. Comandos SERVER Adicionais.............. 38 .foKERMIT: Manual do Protocolo ii 8.2.6. Comandos de Host........................ 41 8.2.7. Trocando para^metros antes de comandos SERVER...................... 41 .cp3 8.3. Tipos alternativos de checagem de bloco........ 42 .cp3 8.4. Interrompendo uma transfere^ncia de arquivo..... 44 .cp3 8.5. Transmitindo atributos de arquivos............. 45 .cp3 8.6. Tabela de estados do Protocolo KERMIT Avanc,ado. 52 .cp4 9. Comandos KERMIT..................................... 58 .cp3 9.1. Comandos Ba'sicos............................... 58 .cp3 9.2. Comandos de gere^ncia do programa............... 58 .cp3 9.3. Comandos de emulac,a~o de terminal............... 59 .cp3 9.4. Comandos em modo-usua'rio especiais............. 59 .cp3 9.5. Comandos cujo objeto deve ser especificado..... 60 .cp3 9.6. O comando SET.................................. 62 .cp3 9.7. Macros (o comando DEFINE)...................... 64 .cp4 10. Emulac,a~o de terminal................................ 65 .cp4 11. Escrevendo um programa KERMIT....................... 68 .cp3 11.1. Organizac,a~o do programa....................... 68 .cp3 11.2. Linguagem de programac,a~o...................... 71 .cp3 11.3. Documentac,a~o.................................. 71 .cp3 11.4. Bootstrapping................................. 72 .cp6 A P E N D I C E S ----------------- .cp4 A. Formato e Tipos dos Pacotes......................... 73 .cp4 B. Relac,a~o das Facilidades............................. 74 .cp4 C. Problemas na~o resolvidos............................ 76 .cp4 D. Um programa KERMIT.................................. 79 .cp4 E. O conjunto de caracteres ASCII (ANSI X3.4-1968)..... 104 .pa .foKERMIT: Manual do Protocolo iii I'N D I C E DE F I G U R A S ---------------------------------- .cp3 2-1: Caracteres Mneumo^nicos ASCII:.......................... 7 .cp3 5-1: Estados de Transmissa~o................................. 21 5-2: Estados de Recepc,a~o.................................... 22 5-3: Estados Comuns a Transmitir e Receber.................. 22 .pa .foKERMIT: Manual do Protocolo # .pn1 Prefa'cio da Quarta Edic,a~o A quarta edic,a~o (novembro de 1983) do Manual do Protocolo Kermit incorpora algumas novas ide'ias que cresceram de nossa experie^ncia em tentar implementar algumas das facilidades descritas em edic,o~es anteriores, particularmente func,o~es USER/SERVER. Isto inclui um mecanismo que permite interromper transfere^ncias em batch sem traumas, tanto para o arquivo corrente quanto para o conjunto total de uma transfere^ncia em batch; uma "ma'scara de capacidade"; uma extensa~o do protocolo para a passagem de atributos de arquivo. Ale'm disso, nu'meros sa~o escritos em forma decimal, ao inve's de octal, que costumava confundir a maioria dos leitores. Tambe'm foram feitas mudanc,as, por incompatibilidades, em a'reas de menos releva^ncia, onde ainda na~o houvesse acontecido alguma implementac,a~o; isso inclui: - o formato e a interpretac,a~o dos operandos dos comandos de um SERVER; - uso dos campos reservados 10-11 do pacote SEND-INIT e adic,a~o de novos campos reservados. A maior parte do material restante foi reescrito e reorganizado e muito material novo acrescentado, inclusive uma sec,a~o recomendando um vocabula'rio para documentac,a~o e comandos. As edic,o~es pre'vias deste manual tentaram definir a "Versa~o 3" do protocolo; esta edic,a~o abandona tal conceito. Uma vez que o desenvolvimento do KERMIT e' uma tarefa desorganizada, desordenada e distribui'da, na~o ha' forma de impor que implementadores de KERMIT incluam certas capacidades em suas verso~es. Porisso nesta edic,a~o tentamos definir o funcionamento ba'sico do KERMIT e, enta~o, descrever va'rias func,o~es opcionais. O princi'pio chave e' que qualquer implementac,a~o de KERMIT deveria funcionar com qualquer outra, independentemente qua~o avanc,ada seja uma delas ou qua~o primitiva seja a outra. A ma'scara de capacidade e outros campos SEND-INIT tentam promover tal princi'pio. .pa Quinta Edic,a~o A Quinta Edic,a~o (marc,o de 1984) tenta esclarecer alguns pontos que ficaram ambi'guos na Quarta Edic,a~o, particularmente a respeito de quando e como e' feito codificac,a~o de prefixo (e quando na~o e') e acerca de mudanc,as de tipos de checagem de blocos. Para o armazenamento de arquivos e' sugerido um mecanismo na Sec,a~o de Atributos onde diversos deles foram rearranjados e acrescentados (isto na~o deve fazer mal algum, ja' que ningue'm ate' hoje tentou implementar Pacote de Atributo). E' fornecida uma tabela de estado do protocolo mais completa, incluindo algumas adic,o~es na colec,a~o de tipos de pacotes. Mais algumas palavras... Antes de se decidir por escrever uma nova versa~o de KERMIT, por favor, tenha em mente que, por filosofia, ele nunca foi nem jamais deve vir a ser um produto comercial, vendido por lucro. Sua meta e' promover comunicac,a~o e compartilhamento e o KERMIT deve, ele pro'prio, ser compartilhado, na~o vendido. Mi'dia e custos de reproduc,a~o podem ser recuperados se desejado mas o lucro na~o deve ser o motivo. Vendedores de softwares comerciais, no entanto, podem pedir permissa~o para incluir o KERMIT com (ou dentro de) seus programas, desde que certas condic,o~es sejam aceitas, inclusive que os cre'ditos pelo protocolo devem ser dados a` CUCCA e o prec,o do produto na~o crescer substancialmente alem de custos de mi'dia e reproduc,a~o pela inclusa~o do KERMIT. Entre em contato com o KERMIT GROUP se voce tiver qualquer du'vida a respeito disso. De qualquer forma, implementadores de KERMIT em potencial devem fazer isso, porque algue'm pode ja' ter feito ou comec,ado a fazer a mesma coisa. O KERMIT e' distribui'do pela Universidade de Columbia em fita magne'tica. As instruc,o~es completas sobre a forma de fazer o seu pedido podem ser encontradas no Guia do Usua'rio. Consultas diretas podem ser feitas para: KERMIT DISTRIBUTION COLUMBIA UNIVERSITY CENTER FOR COMPUTING ACTIVITIES 7TH FLOOR, WATSON LABORATORY 612 WEST 115TH STREET NEW YORK, NY 10025 Agradecimentos Frank da Cruz e Bill Catchings desenharam o Protocolo KERMIT Ba'sico na Universidade de Columbia em 1981. Por ide'ias, procuraram em alguns dos modelos ANSI (X3.57, X3.66), o modelo OSI da ISO, alguns "protocolos assi'ncronos" do mundo real (incluindo o DIALNET PROJECT de Stanford, o TTYFTP PROJECT de Utah), assim como a transfere^ncia de arquivos nas redes tradicionais como (DECNET e ARPANET). O Bill escreveu os dois primeiros programas a implementarem o protocolo, um para o DEC-20, outro para um microcomputador sob CP/M-80 e, no processo, definiu a maior parte dos detalhes e a heuri'stica necessa'rios num processo de transfere^ncia de arquivos. Enquanto isso Daphne Tzoar e Vace Kundakci, tambe'm da Columbia, definiram os detalhes adicionais para comunicac,a~o com um I.B.M. ..@iIBM Muito cre'dito tambe'm deve ir para Bernie Eiben da Digital Equipment Corporation por haver promovido o uso do KERMIT e por acrescentar diversas novas maneiras de como ele poderia ser operado e para Nick Bush e Bob McQueen do Stevens Institute of Technology, pelas muitas contribuic,o~es a`s partes "avanc,adas" do protocolo e para outros grandes implementadores de KERMIT. Agradecemos a`s muitas pessoas que, por todo o mundo, contribuiram com novas implementac,o~es de KERMIT, que ajudaram na distribuic,a~o do KERMIT atrave's de va'rios Grupos de Usua'rios e a`queles que contribuiram para a qualidade do protocolo e suas muitas implementac,o~es ao reportar ou eliminar problemas, criticar o desenho ou sugerir novas facilidades. Aviso Nenhuma garantia do software nem da perfeic,a~o da documentac,a~o aqui apresentada pode ser expressa ou implicitamente dada, nem os autores nem a Universidade de Columbia se responsabilizam por quaisquer danos que possam advir de erros de software ou documentac,a~o, nem do uso destes. .pa ..@adu 1. Introduc,a~o .heIntroduc,a~o Este manual descreve o protocolo KERMIT. Assume que voce compreenda o propo'sito e a operac,a~o das facilidades do KERMIT de transfere^ncia de arquivos, descrita no Guia do Usua'rio, bem como a terminologia ba'sica de comunicac,a~o de dados e programac,a~o de computadores. .cp3 ..@bd 1.1. Cena'rio ..@iambiente ..@icenario O protocolo KERMIT de transfere^ncia de arquivos e' direcionado a`queles ambientes onde aparecem diversos tipos de computadores (micros, computadores pessoais, estac,o~es de trabalho, computadores de laborato'rio, sistemas de timesharing) fornecidos por diversos fabricantes. Tudo que esses sistemas te^m que ter em comum e' a facilidade de se comunicarem serialmente em ASCII. ..@iIBM Originalmente o KERMIT foi desenhado na Universidade de Columbia pela necessidade de se transferir arquivos entre nossos computadores de grande porte (DECSYSTEM-20 e IBM-370) e va'rios microcomputadores. Aconteceu que as diversas caracteri'sticas desses tres tipos de sistemas resultaram num desenho que era gene'rico o suficiente para atender a quase qualquer sistema. O sistema IBM, em particular, prepondera sobre a maioria das formas de comunicac,a~o de computadores. .cp3 ..@bd 1.2. Visa~o Geral ..@ivisao geral ..@ifilosofia do protocolo ..@iprotocolo, visao geral O protocolo KERMIT e' especificamente projetado para transmissa~o de caracteres atrave's de linhas de telecomunicac,a~o (diz-se "orientado para caracter"). O projeto faz concesso~es a`s restric,o~es e peculiaridades do meio e requisitos de diversos ambientes operacionais (buferizac,a~o, duplex, paridade, conjunto de caracteres, organizac,a~o de arquivos etc.). O protocolo e' obedecido por Programas KERMIT em cada ponta da conexa~o serial que trocam "pacotes" entre si; o transmissor manda nomes de arquivos, conteu'dos e informac,o~es de controle; o receptor acusa (positiva ou negativamente) a chegada de cada pacote. Os pacotes tem um desenho padra~o, mais ou menos mantendo as filosofias ANSI e ISO, com os campos mais exteriores usados pelos manuseadores da conexa~o para a verificac,a~o da integridade dos dados, os pro'ximos indicando continuidade e, centralmente, os dados a ni'vel de aplicac,a~o. As conexo~es entre sistemas sa~o estabelecidas pelo pro'prio usua'rio. Num caso ti'pico, o usua'rio, com o KERMIT no microcomputador, entra em modo de emulac,a~o de terminal, se conecta a um computador hospedeiro remoto (normalmente por discagem), faz o LOGIN, chama o KERMIT de la' e, enta~o, da' os comandos para que o KERMIT do hospedeiro comece uma transfere^ncia de arquivo; "escapa" de volta para o micro e comanda o KERMIT do micro para fazer sua parte da transfere^ncia. A transfere^ncia de arquivos pode ser feita um por vez ou em grupos. O KERMIT ba'sico prove^ apenas transfere^ncia de arquivos e somente para arquivos sequenciais, embora o protocolo tente permitir a transfere^ncia de va'rios tipos de arquivos sequenciais. Tambe'm se espera que as implementac,o~es de KERMIT em microcomputadores possibilitem emulac,a~o de terminal, de forma a facilitar a conexa~o inicial. Implementac,o~es mais avanc,adas simplificam a vida do usua'rio ao permitir que o KERMIT do computador hospedeiro trabalhe em modo "SERVER" (servidor), que pode transferir arquivos nas duas direc,o~es sob comando do KERMIT do microcomputador, em modo "USER" (usua'rio local). O SERVER pode, tambe'm, acrescentar funcionalidade adicional, como gere^ncia de arquivos, correio e por ai' a fora. Outras facilidades existem, inclusive uma variedade de tipos de checagem de blocos, um mecanismo para passar 8 bits atrave's de linhas de comunicac,a~o de 7 bits, maneiras de comprimir uma seque^ncia de caracteres repetidos etc. Conforme as redes locais forem se tornando mais populares, baratas e padronizadas, a demanda pelo KERMIT e protocolos similares podera' decair mas nunca deixara' de ter seu espac,o. Diferentemente das redes fixas, o KERMIT da' ao usua'rio comum o poder de estabelecer conexo~es seguras entre dois computadores, a prova de erros. Sempre havera' a eventual necessidade de uma conexa~o a longa distancia... .pa .heDefinic,o~es ..@adu 2. Definic,o~es ..@idefinicoes ..@bd 2.1. Terminologia Geral ..@iterminologia ..@iTTY TTY Esta e' uma terminologia usada normalmente para um equipamento conectado a um computador via uma linha de telecomunicac,a~o serial. Tal equipamento em geral e' um terminal ASCII mas pode ser um microcomputador ou mesmo um computador de grande porte, multi-usua'rio, emulando um terminal ASCII. A maioria dos computadores dispo~e de hardware (conectores RS-232 e UARTS) e software (device drivers) capazes de suportar conexo~es TTY; isto e' o que torna os protocolos de transfere^ncia de arquivos orientados para TTY, como o KERMIT, possi'veis a baixo (ou, mesmo, nenhum) custo. ..@ilocal LOCAL Quando duas ma'quinas sa~o conectadas, a "LOCAL" e' aquela com a qual voce interage diretamente, na qual voce tem o controle do terminal. O KERMIT LOCAL e' aquele que roda na MA'QUINA LOCAL. Um KERMIT LOCAL sempre se comunica atrave's de um equipamento externo (a porta de comunicac,a~o do micro, uma linha TTY associada etc.). ..@iremoto REMOTO(A) A ma'quina REMOTA e' a que esta' na outra ponta de uma conexa~o, com a qual voce interage atrave's da ma'quina LOCAL. O KERMIT REMOTO normalmente se comunica por seu pro'prio "console", "terminal de controle" ou equipamento "padra~o de I/O". ..@ihost HOST Outro nome para "computador hospedeiro", so' que, desta vez, usando-se o termo americano. Normalmente se referindo a um computador que pode ser um "lar" para mu'ltiplos usua'rios ou aplicac,o~es. Tal termo deve ser evitado no jarga~o KERMIT, a menos que precedido, imediatamente, por "local" ou "remoto", de forma a denotar de qual HOST se esta' falando. ..@iservidor ..@iSERVER SERVER (ou SERVIDOR) Uma implementac,a~o de KERMIT REMOTO capaz de aceitar comandos em pacote de um programa KERMIT local, ao inve's de diretamente do usua'rio. ..@iUSER ..@iusuario USER (ou usua'rio) Adicionalmente ao sentido normal (aquele que usa), "USER" sera' usado neste manual quando houver a necessidade de se referenciar a um programa KERMIT LOCAL, quando um KERMIT REMOTO estiver funcionando como SERVER. .cp3 ..@bd 2.2. Nu'meros ..@inumeros ..@ibases de numeracao Todos os nu'meros que aparecem no texto deste manual sa~o expressos em notac,a~o decimal (BASE 10), a menos que em determinadas situac,o~es seja indicado diferentemente. Os nu'meros sa~o sempre referenciados em termos de suas posic,o~es numa palavra de computador. Ja' que o KERMIT pode ser implementado em computadores com palavras de tamanhos diferentes, podemos comec,ar numerando os BITs da "direita" (bit-0 e' o menos significativo). Os BITs 0-5 sa~o os 6 BITs menos significativos; se todos estiverem em "1", o valor seria 63. Uma falha especial na terminologia usual, no entanto, se refere ao bit de mais alta ordem de um caracter, quando ele deve ser transmitido por uma linha de comunicac,a~o, como sendo o "oitavo bit". Mais propriamente ele e' o bit 7, uma vez que comec,amos a contar do 0. Referencias ao "oitavo bit" sa~o feitas em relac,a~o ao bit que uma transmissa~o ASCII usa como bit de paridade. O KERMIT ve^ se tal bit pode ser usurpado para a transmissa~o de dados ou, se na~o, se pode recorrer a ele para "prefixac,a~o de oitavo bit". .cp3 ..@bd 2.3. Conjunto de Caracteres ..@iconjunto de caracteres ..@icaracteres, mneumonicos ..@imneumonicos Todos os caracteres sa~o representados em ASCII (American Standard Code for Information Interchange), padra~o ANSI X3.4-1968. Todas as implementac,o~es de KERMIT transmitem e recebem somente caracteres em ASCII. O conjunto dos caracteres ASCII esta' listado no Ape^ndice E. .cp11 ..@f Figura2-1: Caracteres Mneumo^nicos ASCII: ============================= NOME VALOR CARACTER NUL nulo, morto 0 ^@ SOH start-of-header 1 ^A SP espac,o 32 branco CR carriage-return 13 ^M LF line-feed 10 ^J CRLF seque^ncia CR/LF DEL delete, rubout 127 E' considerado um caracter de controle qualquer byte cujos 7 bits menos significativos estejam na faixa 0-31 ou igual a 127. Neste manual os caracteres de controle podem estar escritos de diversas maneiras: CONTROL-A Denota o valor "1", comumente referenciado como "control A". .cp2 CTRL-A Abreviac,a~o de "CONTROL-A". Um caracter de controle normalmente e' teclado em um computador mantendo-se apertada a tecla marcada "CTRL" enquanto se aperta a tecla com o si'mbolo alfabe'tico correspondente, no caso "A". ^A Esta e' a notac,a~o dita "seta-para-cima" para o CONTROL. Muitos computadores "ecoam" caracteres de controle desta forma. E' considerado um caracter ASCII imprimi'vel, qualquer caracter na faixa 32-126 (do espac,o ao til). .cp3 ..@bd 2.4. Func,o~es de Conversa~o ..@iconversoes ..@ifuncoes de conversao Diversas func,o~es de conversa~o sa~o u'teis na descric,a~o do protocolo e no programa exemplo. A ma'quina onde roda o KERMIT so' precisa saber operar com dados inteiros; sa~o func,o~es que operam sobre o valor nume'rico de um caracter ASCII simples. char(x) = x + 32 transforma o inteiro "x" (desde que esteja na faixa 0- 94) num caracter ASCII imprimi'vel; 0 vira SP, 1 vira "!", 3 vira "#" etc. unchar(x) = x - 32 transforma o caracter "x" (desde que dentro da faixa imprimi'vel (SP-TIL) em um inteiro na faixa 0-94. ctl(x) = x ou 64 mapeia dentro dos caracteres de controle e suas representac,o~es imprimi'veis, preservando o bit de mais alta ordem. Se "x" for um caracter de controle, enta~o x = ctl(ctl(x)) ou seja: a mesma func,a~o e' usada para "controlizar" e "descontrolizar". E' assumido que o argumento seja um caracter de controle de verdade (0 a 31 ou 127) ou o resultado da aplicac,a~o do "ctl" em um caracter de controle (i. e': de 63 a 95). A transformac,a~o e' uma transformac,a~o mneumo^nica (^A vira A e vice-versa). .cp3 ..@bd 2.5. Jarga~o do Protocolo ..@ijargao do protocolo ..@iprotocolo, jargao Um pacote e' uma seque^ncia de caracteres claramente delimitada, composta de "campos de controle" aninhados em torno dos dados; os campos de controle permitem a um programa KERMIT determinar se os dados foram transmitidos correta e completamente. Um pacote e' a unidade de transmissa~o no Protocolo KERMIT. "ACK" e' "acknowledge" ou seja: "conhecimento". Um pacote que e' mandado para acusar o recebimento de um outro pacote. Na~o deve ser confundido com o caracter ASCII "ACK". "NAK" e' "negative acknowledge" ou seja: "desconhecimento". E' um pacote enviado para dizer que um outro pacote recebido estava adulterado ou incompleto, que foi recebido um pacote errado ou que o pacote esperado na~o foi recebido. Na~o deve ser confundido com o caracter ASCII "NACK". Um TIMEOUT e' um evento que pode ocorrer se um dado esperado na~o chega num determinado espac,o de tempo. O programa gerando o pedido de input pode ligar uma interrupc,a~o por tempo para sair de uma leitura sem resposta e ativar procedimentos de recuperac,a~o. .pa .foKERMIT: Manual do Protocolo # .heRequisitos de Sistema ..@adu 3. Requisitos de sistema ..@iprotocolo, requisitos ..@irequisitos do protocolo O protocolo KERMIT requer que: - o HOST possa mandar e receber caracteres usando codificac,a~o ASCII atrave's de uma conexa~o fi'sica EIA RS- 232 privada ou discada; - todos os caracteres imprimi'veis sejam aceitos como entrada pelo HOST e na~o sejam transformados sob condic,a~o alguma (caso sejam convertidos - para EBCDIC, por exemplo - o programa KERMIT deve ser capaz de reconstruir o pacote na forma original, antes da transformac,a~o). Similarmente, qualquer rede ou equipamento de comunicac,a~o interveniente ("smart- modems", TELENET, concentradores de terminais, seletores de porta etc) na~o devem transformar ou "engolir" qualquer caracter ASCII imprimi'vel; - um caracter ASCII simples de controle possa passar de um sistema para o outro sem transformac,a~o; tal caracter e' usado para sincronismo de pacotes; normalmente e' CONTROL-A (SOH, ASCII 1) mas pode ser redefinido; - se um HOST exigir um terminador de linha para entrada de terminal, tal terminador deve ser um u'nico caracter ASCII de controle, como CR or LF, distintos do caracter de sincronismo de pacotes; - ao usar um terminal de controle de JOBs para transfere^ncia de arquivos, o sistema deve permitir que o programa KERMIT passe o terminal para o modo sem eco, comprimento infinito (sem wraparound ou inserc,a~o de CRLF pelo sistema operacional) e sem formatac,a~o de caracteres chegantes ou saintes (por exemplo: transformar minu'sculas em maiu'sculas, caracteres de controle em imprimi'veis etc.); resumindo: o terminal deve ser colocado em modo "bina'rio" ou "cru'" e (tomara!) restaurado depois a`s condic,o~es originais de operac,a~o; - o processador de entrada de terminal do HOST deva ser capaz de receber uma "rajada" de 40 a 100 caracteres em velocidades normais de transmissa~o; este e' o tamanho ti'pico de um pacote. Note que a maior parte desses requisitos impugnam o uso do KERMIT atrave's de conversores IBM-3270/ASCII. O protocolo KERMIT na~o requer que: - a conexa~o seja feita em qualquer baud rate determinada; - o sistema possa fazer XON/XOFF ou qualquer outro tipo de controle de fluxo; controle de fluxo (por hardware ou por software) pode ajudar mas na~o e' necessa'rio (veja sec,a~o "Contro^le de Fluxo"); - o sistema seja capaz de operac,a~o full-duplex; qualquer mistura de half e full duplex e' suportada; - que o sistema possa transmitir ou receber bytes de 8 bits; o KERMIT tomara' vantagem das conexo~es de 8 bits para transmitir arquivos bina'rios; se uma conexa~o de 8 bits na~o for possi'vel, os arquivos bina'rios podem assim mesmo ser manuseados utilizando-se codificaca~o de prefixo. .pa .heTexto Imprimi'vel VERSUS Dados Bina'rios ..@adu 4. Texto Imprimi'vel VERSUS Dados Bina'rios ..@idados, binarios ..@itexto, imprimivel Para transmissa~o entre sistemas diferentes, os arquivos devem ser associados a` uma das duas categorias: texto imprimi'vel ou dados bina'rios. Um texto imprimi'vel e' aquele que pode fazer sentido entre sistemas diferentes (um documento, um programa-fonte, um texto etc.). Ja' um arquivo bina'rio e' aquele que na~o faz (e provavelmente na~o pode fazer) sentido entre sistemas diferentes (um programa executa'vel, nu'meros armazenados num determinado formato interno etc.). Em sistemas de bytes de 8 bits, arquivos ASCII imprimi'veis te^m os bits de mais alta ordem zerados (ja' que o ASCII e' um co'digo de 7 bits) enquanto que arquivos bina'rios usam o bit de mais alta ordem de cada byte para dados (seu valor pode variar de byte para byte). NOTA: existem algumas excec,o~es, como sistemas que armazenam arquivos de texto no chamado "ASCII negativo" ou arquivos de texto produzidos por processadores de texto que utilizam o bit de mais alta ordem para indicar sublinhado, negrito ou outras indicac,o~es. Muitos computadores na~o tem como distinguir um texto imprimi'vel de um arquivo bina'rio, especialmente um que tenha vindo de um sistema diferente. Porisso o usua'rio pode ter que dar comandos expli'citos para o KERMIT de forma a fazer com que ele fac,a converso~es. .cp3 ..@bd 4.1. Arquivos de Texto Imprimi'vel ..@itexto, imprimivel ..@iarquivo, imprimivel A principal meta do KERMIT e' transformar arquivos contendo textos imprimi'veis u'teis no sistema alvo depois da transfere^ncia. Isto exige uma representac,a~o padra~o para o texto durante a transmissa~o. O padra~o KERMIT e' simples: caracteres de 7 bits com "registros lo'gicos" (linhas) delimitados por CRLF's. E' da responsabilidade dos sistemas que na~o armazenam arquivos imprimi'veis desta forma executar as converso~es necessa'rias sobre entradas e sai'das. Por exemplo: ma'quinas de grande porte I.B.M. podem retirar brancos da direita na sai'da e acrescenta'-los de volta na entrada; o UNIX precedera' com um CR seu terminador normal de registro, um LF, na sai'da e o descartara' na entrada. Ale'm disso, os grandes sistemas I.B.M. devem fazer uma traduc,a~o EBCDIC/ASCII para arquivos de texto. Nenhuma outra conversa~o (p.e.: expansa~o de TAB) e' feita sobre arquivos de texto. Foi preferido assim por causa da maneira como os arquivos de texto sa~o armazenados na maioria dos microcomputadores e em muitos outros sistemas. Na maioria dos casos nenhuma transformac,a~o e' necessa'ria. .cp3 ..@bd 4.2. Arquivos Bina'rios ..@iarquivo, binario Os arquivos bina'rios sa~o transmitidos como se fossem uma mera seque^ncia de caracteres. A diferenc,a para os arquivos imprimi'veis e' que o status do oitavo bit deve ser mantido. Quando arquivos bina'rios sa~o transmitidos para sistemas diferentes, o objetivo maior e' que possam ser trazidos de volta ao sistema original (ou a um similar) intacto; nenhuma conversa~o especial deve ser feita durante a transmissa~o, a na~o ser aquela necessa'ria para que os dados possam passar pelo meio de transmissa~o. Para arquivos bina'rios, a transmissa~o a 8 bits e' permitida entre dois KERMITs desde que eles possam controlar o valor do bit de paridade e que nenhum equipamento de comunicc,a~o interveniente possa alterar este valor. Neste caso o oitavo bit de um caracter transmitido sera' igual ao original, depois de ter sido feito qualquer prefixac,a~o de controle. Quando pelo menos um dos lados na~o puder controlar o bit de paridade, um caracter especial de prefixo pode ser inserido, como descrito abaixo. Sistemas que na~o armazenam dados bina'rios em bytes de 8 bits ou cuja palavra na~o tem um nu'mero de bits mu'ltiplo de 8 podem fabricar um mecanismo especial para transferir arquivos bina'rios em "modo imagem". Isto pode ser feito dentro do protocolo ba'sico fazendo-se com que os dois lados implicitamente concordem com um esquema de compactac,a~o dos dados em caracteres ASCII de 7 ou 8 bits ou enta~o podem ser opcionalmente usadas facilidades e atributos de arquivo mais flexi'veis. O primeiro me'todo e' usado nas ma'quinas PDP-10, de 36 bits por byte, onde os textos sa~o armazenados em 5 bytes de 7 bits por palavra; o valor do "bit i'mpar" e' enviado como o bit de paridade de cada quinta palavra. .pa .heTransfere^ncia de Arquivos ..@adu 5. Transfere^ncia de Arquivos ..@iarquivo, transferencia ..@itransferencia de arquivos O protocolo de transfere^ncia de arquivos acontece numa transac,a~o. Uma transac,a~o e' uma troca de pacotes comec,ando com um SEND-INIT (S) e terminando com um BREAK-TRANSMISSION (B) ou ERROR (E) e pode incluir a transfere^ncia de um ou mais arquivos, todos na mesma direc,a~o. Uma transac,a~o tambe'm pode ser considerada terminada quando um dos lados parou sem enviar um pacote de erro. De forma a diminuir imprevistos, os pacotes KERMIT nao conte'm caracteres de controle, exceto um especialmente designado para marcar o ini'cio de um pacote. Exceto pelo marcador de pacote, somente caracteres imprimi'veis sa~o transmitidos. A sequencia a seguir caracteriza a operac,a~o KERMIT ba'sica; o transmissor e' a ma'quina que estiver mandando arquivos; o receptor e' a que os esta' recebendo. 1. O transmissor manda um pacote SEND-INIT (S) para especificar seus para^metros (comprimento do pacote, timeout etc.; explicados abaixo). 2. O receptor envia um pacote ACK (Y), com seus pro'prios para^metros no campo de dados. 3. O transmissor manda um FILE-HEADER (F), com o nome do arquivo em seu campo de dados. 4. O receptor "ACKceita" o pacote F mandando um pacote ACK sem informaca~o em seu campo de dados (opcionalmente, o campo de dados podera' conter o nome sob o qual o guardara' o arquivo que vai receber). 5. O transmissor envia o conteu'do do arquivo em pacotes do tipo "D". Qualquer caracter fora da faixa imprimi'vel e' prefixado e substitui'do por um equivalente que o seja. Cada pacote D tem que ser aceito ("Y") antes que o pro'ximo possa ser transmitido. 6. Quando todos os dados do arquivo tiverem sido transmitidos, transmissor manda um pacote de fim-de- arquivo (Z). 7. O receptor informa que tudo bem com um pacote ACK (Y). 8. Caso haja outro arquivo a ser transmitido, o processo e' repetido a partir do passo 3. 9. Quando na~o existirem mais arquivos a serem transmitidos, o transmissor envia um pacote de fim-de- transmissa~o (B). 10. O receptor manda um ACK (Y). Isto encerra a transac,a~o e desmonta a conexa~o lo'gica (a conexa~o fi'sica permanece aberta). Cada pacote tem um nu'mero de seque^ncia, que comec,a em ZERO com o SEND-INIT. A validac,a~o (ACK ou NAK) tem o mesmo nu'mero do pacote sendo validado. Uma vez que um pacote tenha recebido um ACK, esse nu'mero e' incrementado de 1, mo'dulo 64. Se o transmissor for remoto, ele espera, durante um certo tempo (algo como de 5 a 30 segundos) antes de transmitir o SEND-INIT, de forma a dar ao usua'rio tempo para ESCapar de volta ao KERMIT LOCAL e dizer a ele para receber arquivos. .cp3 ..@bd 5.1. Condicionando o Terminal ..@iterminal, condicionando o - ..@icondicionando o terminal Normalmente o KERMIT e' usado com o usua'rio sentado defronte a um microcomputador conectado a um sistema remoto de time-sharing, atrave's de uma porta de comunicac,a~o. O KERMIT remoto esta' usando seu pro'prio "terminal de controle" de JOBs para transfere^ncia de arquivos. Enquanto a porta do micro e' um mero equipamento, um terminal de controle de JOBs de um computador de time-sharing e' qualquer coisa de especial e frequentemente executa servic,os que interfeririam na operac,a~o normal do KERMIT. Tais servic,os incluem eco (em sistemas full-duplex), marcac,a~o de linhas com a seque^ncia CRLF quando atingida a "largura" da tela do terminal, pausa no "fim da tela", avisos do sistema, conversa~o alfabe'tica (minu'sculas em maiu'sculas), interpretac,a~o de caracteres de controle etc. Os programas KERMIT que rodam em mainframes devem estar preparados para inibir tantos desses servic,os quanto possi'vel antes de iniciar uma comunicac,a~o de pacotes e restaura'-los depois. Inibir tais servic,os e' normalmente conhecido como "colocando o terminal em modo bina'rio". O uso do KERMIT de equivalentes imprimi'veis dos caracteres de controle, comprimentos de pacotes varia'vel, marcadores e prefixos redefini'veis e tolera^ncia de deixar aparecer qualquer caracter entre pacotes sem efeitos adversos, da' uma boa margem de adaptabilidade para aqueles sistemas que na~o permitem inibir algumas (ou qualquer) dessas facilidades. .cp3 ..@bd 5.2. Timeouts, NAKs e Retries. ..@itimeout ..@iNAK ..@iretransmissoes ..@iretries ..@itemporizacao Se um programa KERMIT for capaz de preparar uma interrupc,a~o por tempo ou um limite de tempo para um pedido de entrada, deve fazer isto sempre que for tentar ler um pacote da linha, ao transmitir ou receber arquivos. Lido um pacote, deve desligar o temporizador. Se um programa KERMIT for capaz de ativar uma interrupc,a~o por tempo ou um limite de tempo em um pedido de input, deve faze^-lo sempre que for tentar ler um pacote da linha de comunicac,a~o, na~o importa se transmitindo ou recebendo um arquivo. Lido o pacote, o temporizador deve ser desativado. Se o transmissor entra em timeout esperando um ACK, deve retransmitir o mesmo pacote, repetindo este procedimento um certo nu'mero de vezes ate' um limite de tentativas ou ate' receber um ACK. Se o receptor entra em timeout esperando um pacote, pode tanto mandar um pacote NAK pelo pacote esperado quanto um pacote ACK pelo u'ltimo pacote que tenha recebido. Se um pacote do transmissor for danificado ou perdido (o primeiro detetado por um checksum errado, o segundo por um nu'mero de seque^ncia incrementado de mais de 1), o receptor manda um NAK pelo pacote adulterado ou perdido. Se um ACK ou um NAK do receptor for alterado ou perdido, o transmissor o ignora; em tal caso um dos dois lados entra em timeout e retransmite. Deve ser mantido um contador de retransmisso~es e um limite para ele, normalmente deixado em torno de 5. Quando quer que um pacote seja retransmitido (por timeout ou NAK) o contador e' incrementado. Quando atinge seu limite, ele e' zerado e a transac,a~o encerrada. Se nenhum dos lados for capaz de trabalhar com timeout, uma facilidade de intervenc,a~o manual deve estar disponi'vel no KERMIT local. Tipicamente isto funciona testando-se periodicamente o teclado; caso haja um input, CR por exemplo, o programa deve tomar o mesmo procedimento que tomaria em caso de timeout. O KERMIT local mante'm uma tela informativa que permite ao usua'rio detetar quando o tra'fego para. Neste ponto uma intervenc,a~o manual deve acabar com o trancamento. Sistemas compartilhados que tendem a ficar lentos quando pesadamente usados, devem ajustar seus intervalos de timeout baseados em pacotes, de acordo com a carga do sistema, de modo que uma transfere^ncia na~o falhe simplesmente porque o sistema esta' muito lento. Normalmente somente um dos lados deve estar trabalhando com timeouts; de prefere^ncia o lado que tiver maior conhecimento do seu ambiente (carga do sistema, baud rate etc), de modo a otimizar o intervalo de timeout para cada pacote. Se os dois lados estiverem trabalhando com timeout, seus intervalos devem diferir o suficiente para evitar coliso~es. .cp3 ..@bd 5.3. Erros ..@ierros ..@itransferencia, erros Durante uma transferencia de arquivos, o transmissor pode encontrar um erro de I/O no disco ou o receptor pode tentar gravar em um disco protegido ou, mesmo, cheio. Qualquer condic,a~o adversa ao sucesso de uma transmissa~o de um arquivo e' chamada "erro fatal". Erros fatais devem ser detetados e a transmissa~o ser cancelada elegantemente, com as informac,o~es pertinentes dadas ao usua'rio. Os pacotes de erro prove^em um mecanismo para atender tal premissa. Se acontece um erro fatal, tanto no lado que transmite quanto no lado que recebe, o que encontrou o erro deve mandar um pacote (E) de erro. O pacote "E" conte'm uma breve mensagem, textual, em seu campo de dados. Os dois lados devem estar preparados para receber um pacote de erro a qualquer tempo durante a transac,a~o. Neste caso os dois lados devem parar e voltar ao modo comando de usua'rio. Um SERVER deve voltar a esperar comandos do USER, que deve mostrar a mensagem de erro na tela. Na~o existe provisa~o para mandar mensagens de erros na~o fatais, avisos ou outras informac,o~es durante uma transac,a~o. Ate' que isto seria possi'vel mas requereria que ambos os lados concordassem em usar a ativac,a~o de um bit na ma'scara de capacidade, uma vez que antigos KERMITs na~o sabem desta facilidade e poderiam entrar em estado de erro fatal. De qualquer forma a utilidade de tal facilidade e' questiona'vel, ja' que ningue'm garante que o usua'rio vai estar presente para ler tais mensagens nos momentos em que elas forem emitidas; mesmo que sejam gravadas para posterior observac,a~o, em algum tipo de "caixa postal", suas significa^ncias podem ser diminui'das conforme for passando o tempo ate' serem lidas pelo usua'rio. Veja a sec,a~o sobre robustez, abaixo. .cp3 ..@bd 5.4. Heuri'stica ..@iheuristica Durante qualquer transac,a~o, diversas heuri'sticas sa~o u'teis: 1. Um NAK pelo pacote corrente e' equivalente a um ACK pelo pacote anterior (mo'dulo 64). Isto trata a situac,a~o muito comum na qual um pacote e' recebido com sucesso e aceito (ACK), mas o ACK e' perdido. O lado do ACK, enta~o, entra em timeout esperando pelo pro'ximo pacote e manda um NAK por ele. O lado que recebe o NAK pelo pacote n+1 ao esperar um ACK pelo pacote n, simplesmente retransmite o pacote n+1. 2. Se um pacote n chega mais de uma vez, mande um ACK e dispense-o. Isto pode acontecer quando o primeiro ACK se perdeu. Retransmitir o ACK e' necessa'rio e suficiente (na~o grave o pacote novamente!!!). 3. Ao abrir uma conexa~o, esvazie todo o buffer de entrada da linha antes de tentar receber ou transmitir o pri meiro pacote. Isto e' especialmente importante se o outro lado estiver em modo recepc,a~o (ou agindo como um SERVER), em cujo caso pode ter mandado NAKs perio'dicos pelo seu esperado pacote de comando ou SEND-INIT. Se voce na~o faz isso, voce pode descobrir que existem NAKs suficientes para impedir uma transfere^ncia: voce manda um SEND-INIT e le^ a resposta, que e' um NAK (ja' velho no buffer); retransmite o SEND-INIT, ganha um outro velho NAK e fica assim ate' atingir o limite de re transmisso~es e desiste antes de conseguir o ACK que estava esperando depois de todos os velhos NAKs. Se o nu'mero de NAKs for menor que o limite de retransmis so~es, enta~o cada pacote pode ser retransmitido diversas vezes. 4. Da mesma forma, apo's ler um pacote, com sucesso ou na~o, voce deve limpar o buffer de entrada. Na~o deve haver coisa alguma para voce la', mesmo, ja' que o outro lado deve normalmente esperar que voce envie sue pacote de resposta. Deixar de limpar o buffer pode resultar numa propagac,a~o de repetic,a~o de um pacote devido a NAKs empilhados. Obs.: sob "Facilidades Opcionais", mais sobre heuri'stica... .cp3 ..@bd 5.5. Nomes de Arquivos ..@inomes de arquivos ..@iarquivo, nomes de A sintaxe para nomes de arquivos pode variar muito de sistema para sistema. Para evitar problemas, sugere-se que os nomes de arquivos sejam representados nos pacotes (F) de cabecalho de arquivo numa "forma normal", por default, isto e': deve haver uma opc,a~o para passar por cima de tais converso~es. 1. Apague todos os atributos e pathnames das especificac,o~es de arquivo. O pacote de cabec,alho na~o deve conter nomes de dispositivos ou direto'rio, caso contra'rio isto pode fazer com que o receptor tente gravar o arquivo em uma area inacessi'vel ou inexistente ou, ainda, resultar em um nome de arquivo muito estranho. 2. Depois de retirados quaisquer adendos do nome do arquivo, converta o que sobrou para a forma "NOME.TIPO", sem restric,o~es quanto a comprimento, desde que caiba no campo de dados do pacote "F" e: a) na~o inclua mais que um ponto b) use somente di'gitos e letras maiu'sculas no nome e tipo. Caracteres especiais como "$", "&", "-", "_" etc., devem ser evitados, ja' que provavelmente causara~o problemas no outro sistema. O receptor, claro, na~o pode depender do transmissor para seguir esta convenc,a~o e deve tomar certas precauc,o~es. No entanto, ja' que a maioria dos sistemas trabalham com a noc,a~o de nome e tipo de arquivo, esta convenc,a~o permitira' que esses i'tens sejam expressos de uma forma que sistemas diferentes possam compreender. Esta notac,a~o em particular foi adotada simplesmente por ser a mais comum. O receptor deve se preocupar com o comprimento dos campos de nome e tipo em um nome de arquivo. Se um deles for muito extenso, deve ser truncado. Se o resultado, truncado ou na~o, e' o mesmo que algum arquivo ja' existente na mesma a'rea, o receptor deve ser capaz de evitar gravar por cima do arquivo mais antigo. As implementac,o~es de KERMIT que, por default, convertem as especificac,o~es de arquivos para uma forma normal, devem ter uma opc,a~o para deixar de lado esta facilidade. Isto e' mais u'til ao se transferir arquivos entre sistemas similares, talvez usado em conjunc,a~o com o modo "imagem" de arquivo. Isto pode permitir, por exemplo, um sistema UNIX mandar para outro toda uma a'rvore de direto'rio. .cp3 ..@bd 5.6. Robustez ..@iprotocolo, robustez ..@irobustez Uma grande facilidade do protocolo KERMIT e' a habilidade de transferir mu'ltiplos arquivos. Se um KERMIT em particular pode, realmente, ou na~o fazer isto depende da capacidade do programa e do sistema operacional do host (qualquer programa KERMIT pode receber arquivos mu'ltiplos). Se um programa KERMIT pode transmitir arquivos mu'ltiplos, deve tomar todo cuidado para mandar o grupo especificado inteiro. Se ele falha em enviar um arquivo em particular, na~o deve encerrar o batch inteiro mas, sim, ir ao pro'ximo e proceder ate' que uma tentativa seja feita para mandar cada um dos arquivos do grupo. Operar nesta robusta forma, no entanto, da' chance ao aparecimento de um problema: o usua'rio deve ser notificado de uma falha em transmitir algum arquivo. Infelizmente na~o e' suficiente dar uma mensagem na tela, ja' que o usua'rio pode na~o estar fisicamente presente. Uma melhor soluc,a~o seria fazer com que o transmissor tivesse um "log" opcional, com o nome de cada arquivo para o qual foi feita uma tentativa e informando se a tentativa teve e^xito e, se na~o, a raza~o. Auxi'lios adicionais para robustecer mais um programa KERMIT esta~o descritos na sec,a~o sobre facilidades adicionais, abaixo. .cp3 ..@bd 5.7. Controle de Fluxo ..@iXON/XOFF ..@icontrole de fluxo ..@ifluxo, controle de Em conexo~es full-duplex, controles de fluxo XON/XOFF podem, geralmente, ser usadas em conjunc,a~o com uma trans fere^ncia de arquivo via KERMIT, sem efeitos colaterais. Isto e' porque XOFF's sa~o mandados na direc,a~o oposta ao fluxo dos pacotes, de forma que na~o interfirira~o com os pacotes, pro priamente. XON/XOFF's, porisso, na~o precisam estar definidos em um programa KERMIT mas podem, por outro lado, ser utiliza dos pelo host. Se o host prove^ esta possibilidade, ela deve ser utilizada. Se os dois lados puderem responder aos sinais XON/XOFF, enta~o poderemos evitar os estouros de buffer e as onerosas retransmisso~es que isso implica. Acautele-se, pore'm, com a seguinte situac,a~o: o KERMIT remoto esta' mandando NAKs perio'dicos, o sistema local os esta' bufferizando a ni'vel de sistema operacional (porque o usua'rio na~o iniciou ainda o ponto final da transfere^ncia de arquivos); o buffer de linha local fica lotado, o sistema local manda XOFF, o remoto comec,a a bufferiza'-los, o usua'rio finalmente inicia o ponto final da transfere^ncia, limpa o buffer, o sistema operacional local manda XON e, enta~o os NAKs bufferizados remotamente aparecem, causando o problema descrito acima dos ecos de pacotes, apesar do buffer limpo no sistema local. Tambe'm podem ser empregados os controles de fluxo via sinais de modem, quando disponi'veis. .cp3 ..@bd 5.8. Tabela de Estados do Protocolo KERMIT Ba'sico ..@iestados do protocolo ..@iprotocolo, estados O protocolo KERMIT pode ser descrito como um conjunto de estados, transic,o~es e regras que dizem o que fazer ao acontecer uma mudanc,a de um estado para outro. Mudanc,as de estado ocorrem dependendo do tipo de pacotes que sa~o trans mitidos ou recebidos ou de erros que possam ocorrer. Os pacotes sempre va~o para frente e para tra's; o transmissor de um arquivo sempre manda pacotes de dados de algum tipo (ini cializac,a~o, cabec,alho, dados) e o receptor sempre devolve pacotes ACK ou NAK. Ao entrar em um dado estado, um certo tipo de pacote esta' sendo transmitido ou esperado (isto e' mostrado no tope da descric,a~o daquele estado). Como resultado da ac,a~o, va'rias respostas podem aparecer. Elas sa~o mostradas na coluna de eventos. Para cada evento, uma ac,a~o apropriada e' tomada e o protocolo entra em um novo estado. A tabela a seguir especifica a operac,a~o ba'sica do KERMIT. Por simplicidade, as condic,o~es de erro e timeouts foram omitidas mas a ac,a~o esta' como descrita acima. Opera c,o~es de SERVER e algumas das facilidades avanc,adas tambe'm foram omitidas. A tabela total de estados sera' mostrada no capi'tulo "Facilidades Opcionais". .pa ..@f Figura 5-1: Estados de Transmissa~o ================================== Novo Est. Evento Ac,a~o Est. === ===================== ============================= ==== **** Manda pacote SEND-INIT **** S recebe NAK ou mal ACK nenhuma S recebe bom ACK prepara parms., abre arq. SF outros nenhuma A **** Manda pacote de cabec,alho de arquivo **** SF recebe NAK ou mal ACK nenhuma SF recebe bom ACK enche buffer ou dados de arq. SD outros nenhuma A **** Manda pacote de dados de arquivo **** SD recebe NAK ou mal ACK nenhuma SD recebe bom ACK enche buffer ou dados de arq. SD fim de arquivo nenhuma SZ outros nenhuma A **** Manda pacote de fim de arquivo **** SZ recebe NAK ou mal ACK nenhuma SZ recebe bom ACK pega proximo arq. a enviar SF na~o mais arquivos nenhuma SB outros nenhuma A **** Manda pacote de break (EOT) **** SB recebe NAK ou mal ACK nenhuma SB recebe bom ACK nenhuma C outros nenhuma A .pa ..@f Figura 5-2: Estados de Recepc,a~o =============================== Novo Est. Evento Ac,a~o Est. === ===================== ============================= ==== **** Espera por pacote SEND-INIT **** R recebe SEND-INIT ACK c/ para^metros locais RF outros nenhuma A **** Espera por pacote de Cabec,alho de Arquivo **** RF recebe SEND-INIT ACK c/ para^metros locais ACK pre'vio foi perdido RF recebe SEND-EOF ACK (prev. foi perdido) RF recebe BREAK ACK C recebe cab.arq. abre arq., ACK RD outros nenhuma A **** Espera por pacote de dados de arquivo **** RD rec.pac.anterior(D,F) ACK de novo RD recebe EOF ACK, fecha o arquivo. RF recebe dados bons grava, ACK RD outros nenhuma A ..@f Figura 5-3: Estados Comuns a Transmitir e Receber ================================================= Novo Est. Evento Ac,a~o Est. === ===================== ============================= ==== C (envio completado) ini'cio A ("abortar") ini'cio .pa .heFormato dos Pacotes ..@adu 6. Formato dos Pacotes ..@ipacote, formato ..@iformato do pacote ..@bd 6.1. Campos ..@icampos do pacote ..@ipacote, campos O protocolo KERMIT e' construi'do em torno da troca de pacotes no seguinte formato: +------+-----+-----+------+------+-------+ | mark | len | seq | type | data | check | +------+-----+-----+------+------+-------+ onde todos os campos consistem de caracteres ASCII. Os campos sa~o os seguintes: .cp2 MARK (marca) E' o caracter de sincronismo que marca o ini'cio do pacote. Deve ser, normalmente, um CTRL-A, mas pode ser redefinido. .cp2 LEN (comprimento) Nu'mero de caracteres ASCII dentro do pacote que segue este campo. Em outras palavras: comprimento do pacote menos dois. Uma vez que este nu'mero e' transformado em um u'nico caracter atrave'z da func,a~o "char()", os contadores de caracteres em um pacote podem valer de 0 a 94, sendo 96 o tamanho ma'ximo de um pacote. O comprimento na~o inclui os caracteres de fim-de-linha ou de preenchimento, que esta~o fora do pacote e esta~o la' estritamente para benefi'cio do sistema operacional ou do equipamento de comunicac,a~o MAS INCLUI OS CARACTERES DE CHECAGEM DE BLOCO. .cp2 SEQ (seque^ncia) O nu'mero de seque^ncia do pacote, mo'dulo 64 (ou seja: varia de 0 a 63). Estes contadores, ao atingirem 63, voltam a 0 (viram zero a cada 64 pacotes). .cp2 TYPE (tipo) E' o pro'prio tipo do pacote, com uma letra. Os seguintes tipos de pacotes sa~o exigidos: D pacote de dados Y aceito (ACK) N na~o aceito (NAK) S SEND-INIT (troca de para^metros) B break na transmissa~o (EOT) F cabec,alho de arquivo Z fim de arquivo (EOF) E erro T reservado para uso interno O pacote NAK somente e' usado para indicar que o pacote esperado na~o foi corretamente recebido, nunca para suprir outros tipos de informac,a~o, como recusa em executar um servic,o pedido. O pacote NAK tem sempre seu campo de dados vazio. O pacote "T" e' usado internamente por muitos programas KERMIT para indicar que ocorreu um timeout. .cp2 DATA (dados) E' o "conteu'do" do pacote, se algum conteu'do for neces sa'rio naquele tipo de pacote, interpretado de acordo com o tipo de pacote. Carateres de controle (bytes cujos 7 bits de mais baixa ordem estiverem na faixa de controle ASCII 0-31 ou 127) sa~o prefixados por um caracter especial, geralmente "#" e "descontrolificados" via ctl(). Uma seque^ncia prefixada na~o pode ser quebrada de um pacote para o outro. Registros lo'gicos em arquivos imprimi'veis sa~o delimitados com CRLFs, devidamente prefixados (e.g.: #M#J). Registros lo'gicos na~o sa~o obrigados a corresponderem a pacotes. Quaisquer caracteres de prefixac,a~o sa~o inclui'dos no contador. A codificac,a~o opcional para 8 bits e para caracteres repetidos sera~o descritas posteriormente. CHECK (checagem de bloco) E' a checagem de bloco dos caracteres no pacote entre (mas na~o incluindo) a marca e o check. O check para cada pacote e' computado por ambos os lados e devem ser iguais se e' que o pacote deve ser aceito. Um checksum aritme'tico de um u'nico caracter e' o check normal e exigido. De forma a todos os bits de cada caracter de dado contribui'rem para tal ca'lculo, os bits 6 e 7 do valor final sa~o somados a` quantidade formada pelos bits de 0 a 5. Assim, se S for a soma aritme'tica dos caracteres ASCII, enta~o check = char((s + ((s and 192)/64)) and 63). Este e' o ca'lculo default e todos os KERMITs devem ser capazes de executa'-lo. Outros tipos opcionais de ca'lculo sera~o descritos mais tarde. O check de bloco e' baseado nos valores ASCII de todos os caracteres no pacote, inclusive caracteres de controle e caracteres de prefixac,a~o. Sistemas na~o-ASCII devem traduzir para ASCII antes de fazer os ca'lculos de check. .cp3 ..@bd 6.2. Terminador ..@iterminador ..@iCR ..@iterminador, CR Qualquer terminador de linha exigido pelo sistema pode ser inclui'do no pacote; costuma ser o CR. Terminadores de linha na~o sa~o considerados parte do pacote e na~o sa~o inclui' dos no contador de check. Na~o sa~o necessa'rios para o protoco lo e sa~o invisi'veis para ele, ja' que qualquer caracter pode aparecer entre pacotes. Se um host na~o puder receber um u'nico caracter de uma linha TTY, enta~o um terminador sera' neces sa'rio para transmitir para tal host. O terminador pode ser especificado no ini'cio da conexa~o. Algumas implementac,o~es de KERMIT tambe'm usam o terminador por uma outra raza~o: velocidade. Alguns sistemas na~o sa~o ra'pidos o suficiente para pegar um pacote e decodifica'-lo caracter a caracter sob velocidades mais altas; Recebendo "cegamente" todos os caracteres entre a marca e o EOL, sa~o capazes de absorver os caracteres que chegam a` toda velocidade e, enta~o, processa'-los calmamente. ..@iEOL ..@iterminador, EOL .cp3 ..@bd 6.3. Outros dados inter-pacotes. ..@idados inter-pacotes ..@ipacote, dados inter-pacote O espac,o entre pacotes pode ser utilizado para qualquer propo'sito desejado. Caracteres de handshaking podem ser necessa'rios em certas conexo~es, outras podem exigir controle de tela, outras ainda seque^ncias para manter os pacotes fluindo. .cp3 ..@bd 6.4. Codificac,a~o, Prefixac,a~o, Checagem de Bloco ..@icontrole, campos ..@icampos de controle ..@icodificacao ..@ipacote, codificacao ..@iprefixacao ..@ipacote, prefixacao ..@ibloco, checagem de ..@ichecagem de bloco Mark, len, seq, type e check sa~o campos de controle. Sa~o sempre campos de um u'nico caracter literal, exceto que o campo check pode ser expandido por um ou dois caracteres de check adicionais. Cada campo de controle e' codificado pela char() ou tomado literalmente mas nunca prefixados. Os campos de controle nunca conte'm dados de 8 bits. Os campos de dados (data) conte'm uma cadeia de caracteres onde quaisquer caracteres de controle sa~o codificados imprimivelmente e precedidos pelo prefixo de controle. A decisa~o de prefixar um caracter desta forma depende de seus 7 bits menos significativos terem um valor dentro da faixa ASCII de controle (0-31 ou 127). Os caracteres de prefixo que aparecem nos dados devem ser, eles mesmos, precedidos pelo prefixo de controle mas, diferentemente dos caracteres de controle, eles retem seus valores literais no pacote. O tratamento do bit mais significativo ("oitavo") de um byte de dados e' o seguinte: * se o canal de comunicac,a~o permite 8 bits por caracter, enta~o o valor original do oitavo bit e' mantido no caracter de prefixo; por exemplo: um byte correspondendo a um CTRL-A com o oitavo bit ligado, e' transmitido como um prefixo de controle, normalmente "#", com o oitavo bit desligado, seguido por ctl(^A) com o oitavo bit ligado; em notac,a~o bina'ria seria 00100110 10000001 neste caso, o oitavo bit entra em todos os ca'lculos de checagem de bloco; * se o canal de comunicac,a~o ou um dos hosts exigem paridade em cada caracter e ambos os lados sa~o capazes de prefixac,a~o de 8 bits, enta~o o oitavo bit sera' usado para paridade e na~o deve ser inclui'do na checagem de bloco; prefixac,a~o de oitavo bit e' uma opc,a~o que esta' descrita em mais detalhes na sec,a~o 8, abaixo; * se se estiver usando paridade mas na~o prefixac,a~o de oitavo bit, o valor do oitavo bit de cada byte de dados sera' perdido e arquivos bina'rios na~o sera~o transmitidos corretamente; novamente, o oitavo bit na~o entra na checagem de bloco. Os campos de dados de todos os pacotes esta~o sujeitos a codificac,a~o prefixada, exceto nos pacotes "S", "I" e "A" e seus ACKs (veja adiante). .pa .heConexa~o Inicial ..@adu 7. Conexa~o Inicial ..@iconexao inicial A conexa~o inicial ocorre quando o usua'rio iniciou um programa KERMIT nas duas pontas da conexa~o fi'sica. Um KERMIT foi ativado para transferir um arquivo e o outro para recebe- lo. O KERMIT receptor espera por um pacote SEND-INIT do KERMIT transmissor. Na~o importa se o KERMIT transmissor foi iniciado antes ou depois do KERMIT receptor (se antes, o pacote SEND-INIT deve ser retransmitido periodicamente ate' que o KERMIT receptor o aceite). O campo de dados do pacote SEND-INIT e' opcional; campos posteriores podem ser omitidos (ou deixados em branco, isto e': contendo espac,os) para aceitar ou especificar valores default. O pacote SEND-INIT conte'm uma string de informac,o~es de configurac,a~o no seu campo de dados. O receptor manda um ACK pelo SEND-INIT, cujo campo de dados conte'm seus pro'prios para^metros de configurac,a~o. O campo de dados do SEND-INIT e do ACK pelo SEND-INIT sa~o literais ou seja: na~o ha' codificac,a~o de prefixo. Isto e' porque as duas partes na~o saberiam fazer codificac,a~o de prefixo ate' depois da troca de dados de configurac,a~o. E' importante notar que campos recentemente inventados sa~o acrescentados a` direita, de forma que os antigos KERMITs, que na~o tem co'digo para lidar com os novos campos, podem agir como se eles simplesmente na~o existissem. Por esta raza~o o valor default para qualquer campo, indicado por branco, deve resultar no comportamento anterior a` definic,a~o ou inclusa~o do novo campo. 1 2 3 4 5 6 +------+------+------+------+-----+------+ | MAXL | TIME | NPAD | PADC | EOL | QCTL | +------+------+------+------+-----+------+ 7 8 9 10... +------+------+------+------ | QBIN | CHKT | REPT | CAPAS +------+------+------+------- Os campos sa~o os seguintes (a primeira pessoa, "eu", e a segunda, "voce", sa~o usadas para distinguir os dois lados). Os campos sa~o codificados "imprimivelmente" usando-se a func,a~o char(), a menos que indicado de forma diferente. .cp2 1. MAXL E' o comprimento do maior pacote que eu quero receber, um nu'mero ate' 94. Voce responde com o ma'ximo que quer receber. Isto permite que os sistemas se adaptem aos seus tamanhos de buffer ou a`s condic,o~es do meio de transmissa~o. .cp2 2. TIME Nu'mero de segundos depois dos quais eu quero que voce me coloque em timeout ou esperar um pacote meu. Voce responde com a quantidade de tempo que eu devo esperar pacotes de voce. Isto permite que ambos os lados se acomodem a diferentes velocidades de linha ou a outros fatores que possam causar problemas de tempo. Somente um dos lados precisa trabalhar com timeout. Se os dois lados o fazzem, os tempos de timeout na~o devem ser pro'ximos. .cp2 3. NPAD O nu'mero de caracteres de preenchimento que eu quero que precedam cada pacote que chegue a mim; voce responde da mesma forma. Preenchimento e' necessa'rio ao se trabalhar em sistemas half-duplex que precisam de algum tempo para inverter a direc,a~o da transmissa~o, embora na pra'tica tal situac,a~o seja normalmente manuseada por um mecanismo de handshaking. .cp2 4. PADC E' o caracter de controle que eu preciso para preenchimento, se for o caso, transformado pela func,a~o ctl() (na~o chr()) para torna'-la imprimi'vel. Voce me responde com o seu. Normalmente e' o NUL (ASCII 0) mas alguns sistemas usam o DEL (127). Este campo deve ser ignorado se o valor de NPAD for zero. .cp2 5. EOL O caracter que eu preciso para terminar um pacote que chega, se algum. Voce responde com o seu. A maioria dos sistemas que exigem um terminador de linha para um input de terminal aceitam CR para tal propo'sito. (note que, ja' que na~o ha' forma de se especificar que o EOL na~o deve ser enviado, e' melhor usar ctl() para este campo, ao inve's de char() mas agora e' muito tarde...). .cp2 6. QCTL (VERBATIM) O caracter imprimi'vel que eu vou usar para marcar caracteres de controle. Normalmente e, por default, "#". Voce responde com o que voce vai usar. Os campos a seguir esta~o relacionados com o uso de facilidades opcionais do protocolo KERMIT, descritas no capi'tulo "Facilidades Opcionais". .cp2 7. QBIN (VERBATIM) O caracter imprimi'vel que eu vou usar para marcar caracteres que tenham o oitavo bit ligado, para transmitir arquivos bina'rios quando o bit de paridade na~o puder ser usado para dados. Ja' que este tipo de marcac,a~o aumenta o overhead, tanto de transmissa~o quanto de processamento, normalmente deve ser evitado. O caracter de marcac,a~o deve estar na faixa ASCII 33-62 ("!" a ">") ou 96-126 ("@" a "^") mas diferente do caracter que marca caracteres de controle. Este campo e' interpretado da seguinte maneira: Y eu concordo com marcac,a~o do oitavo bit se voce pedir N na~o farei marcac,a~o do oitavo bit & (ou qualquer outro caracter na faixa 33-62 ou 96- 126): eu quero fazer marcac,a~o do oitavo bit com este caracter (isto sera' feito se o outro KERMIT colocar um Y neste campo ou responder com o mesmo caracter de prefixac,a~o, como &); o caracter prefixo de marcac,a~o recomendado e' "&" qualquer outra coisa: na~o sera' feita a marcac,a~o do oitavo bit. Note que este esquema permite que qualquer lado inicie o pedido e que a ordem na~o importa. Por exemplo: um micro capaz de se comunicar em 8 bits normalmente usara' um "Y" neste campo, enquanto um mainframe que usa paridade sempre usara' um "&". Na~o importa quem manda primeiro: esta combinac,a~o resultara' numa "eleic,a~o" da marcac,a~o do oitavo bit. .cp2 8. CHKT Tipo de checagem, o me'todo para detec,a~o de erros. E' "1" para checksum de um caracter (o me'todo normal e exigido), "2" para checksum de dois caracteres (opcional) e "3" para checksum CRC-CCITT (opcional). Se voce responde concordando, o me'todo designado sera' usado; sena~o sera' o checksum de um so' caracter. .cp2 9. REPT E' o prefixo que quero usar para indicar um caracter repetido. Pode ser qualquer caracter imprimi'vel na faixa ASCII 33-62 ou 96-126 mas diferente dos prefixos de oitavo bit e de controle. Espac,o (32) indica que na~o deve ser executado o processamento de contagem de repetic,o~es. Til ("~") e' o prefixo normal e recomendado. Se voce na~o responde identicamente, esta facilidade na~o sera' usada. Grupos de pelo menos 3 ou 4 caracteres identicos podem ser transmitidos mais eficientemente usando-se um contador de repetic,o~es, embora uma implementac,a~o individual possa preferir usar um princi'pio diferente. 10-?. CAPAS Ma'scara de bits, onde cada bit ligado representa uma capacidade do KERMIT. Cada caracter contem um campo de 6 bits (transformado pela func,a~o char()), cujo bit de mais baixa ordem estara' ligado se a este se segue outro byte de capacidades e desligado se este for o u'ltimo. Ate' agora as capacidades definidas sa~o as seguintes: .cp3 #1 reservada #2 reservada #3 habilidade em receber pacotes "A" (atrib. de arquivos). .cp7 O byte de capacidades ate' agora definido se apresenta assim: BIT5 BIT4 BIT3 BIT2 BIT1 BIT0 +----+----+----+----+----+----+ | #1 | #2 | #3 | -- | -- | 0 | +----+----+----+----+----+----+ Se todas estas capacidades estiverem "ligadas", o valor do byte seria 70 (octal). Quando as capacidades 4, 5 e 6 sa~o acrescentadas, a ma'scara de capacidade fica assim: BIT5 BIT4 BIT3 BIT2 BIT1 BIT0 +----+----+----+----+----+----+ | #1 | #2 | #3 | #4 | #5 | 1 | +----+----+----+----+----+----+ BIT5 BIT4 BIT3 BIT2 BIT1 BIT0 +----+----+----+----+----+----+ | #6 | -- | -- | -- | -- | 0 | +----+----+----+----+----+----+ Pro'ximos 4: campos reservados Instalac,o~es que queiram acrescentar seus pro'prios para^metros a` negociac,a~o do ini'cio da conexa~o, devem comec,ar no quinto campo depois do u'ltimo byte de capacidade. Qualquer campo no meio pode ser deixado em branco (isto e': podem conter o caracter SP, "espac,o"). Estes campos esta~o reservados para futuro uso pelo protocolo KERMIT. Os prefixos de controle, oitavo bit e de repetic,a~o devem ser distintos entre si. O KERMIT receptor responde com um pacote ACK ("Y") no mesmo formato para indicar suas pro'prias prefere^ncias, opc,o~es e para^metros. O ACK na~o precisa conter o mesmo nu'mero de campos como o SEND-INIT. Deste ponto, os dois programas KERMIT esta~o configurados para se comunicarem ate' o fim da transac,a~o. No caso de se usar a marcac,a~o do oitavo bit, um dos lados deve informar o caracter a ser usado e o outro concordar com um "Y" no mesmo campo mas a ordem em que isto ocorre na~o importa. Da mesma forma para os checksums: se um dos lados pede o de dois caracteres e o outro diz "1" (ou na~o diz) o jeito e' usar "1", ja' que na~o se pode esperar que todas as implementac,o~es trabalhem com dois bytes em checksums e/ou CRCs. E para contadores de repetic,a~o: se o campo de repetic,a~o do SEND-INIT e do ACK na~o concordam entre si, na~o havera' o processo. Todos os campos do SEND-INIT sa~o opcionais. O campo de dados pode ser deixado completamente em branco. Da mesma forma, campos intervenientes podem ter seus defaults acionados pelo fato de serem deixados em branco. As implementac,o~es de KERMIT devem saber o que fazer nesses casos, principalmente aplicar os defaults apropriados. Os defaults sa~o os seguintes: .cp9 MAXL = 80 NPAD = 0, sem preenchimento PADC = 0 (NUL) EOL = CR QCTL = o caracter "#" QBIN = nenhum, na~o faz marcac,a~o do oitavo bit CHKT = "1" (checksum de um caracter) REPT = na~o MASK = tudo zero (sem capacidades especiais) Na~o existem negociac,o~es prolongadas na seque^ncia inicial de conexa~o: existe apenas um SEND-INIT e um ACK de resposta; tudo deve ser acionado nesta troca. O primeiro SEND-INIT pode na~o passar se o KERMIT transmissor assumir coisas erradas acerca do receptor. Por exemplo, o receptor pode exigir alguma paridade, algum tipo de preenchimento, handshaking ou um EOL especial para que consiga ler o pacote SEND-INIT. Por esta raza~o, deve haver um modo do usua'rio especificar o que quer que seja necessa'rio para conseguir fazer passar o primeiro pacote. Na~o e' provido um campo de paridade no pacote SEND-INIT porque poderia na~o ser u'til, va'lido. Se o transmissor exige um certo tipo de paridade, tambe'm o estara' utilizando (e mandando). Se o receptor na~o souber disto de antema~o, antes de receber o SEND-INIT, ele na~o sera' capaz de receber o pacote SEND-INIT. .pa .heFacilidades Opcionais ..@adu 8. Facilidades Opcionais ..@ifacilidades opcionais ..@iopcionais, facilidades Discutimos, nas sec,o~es anteriores, as operac,o~es ba'sicas, exigidas para qualquer implementac,a~o de KERMIT. Nas pro'ximas sec,o~es discutiremos as facilidades avanc,adas opcionais. ..@bd 8.1. Prefixac,a~o de oitavo bit e contador de repetic,o~es ..@iprefixacao de oitavo bit ..@irepeticoes, contador ..@ioitavo bit, prefixacao ..@icontador de repeticoes A marcac,a~o de caracteres de controle e' obrigato'ria. Ale'm disto, a prefixac,a~o tambe'm pode ser usada para quantidades de 8 bits ou contadores de repetic,a~o, quando os dois programas KERMIT concordam em faze^-lo. Uma prefixac,a~o de oitavo bit pode permitir que dados bina'rios passem atrave's de links fi'sicos de 7 bits. Prefixac,a~o de contadores de repetic,a~o podem melhorar dramaticamente o throughput de certos tipos de arquivo; arquivos bina'rios (programas executa'veis particularmente) e textos estruturados (colunares ou altamente identados) tendem a ser os maiores beneficia'rios. Quando mais de um tipo de prefixac,a~o esta' em efeito, um u'nico caracter de dados pode ser precedido por mais de um caracter de prefixac,a~o. Um receptor nunca fara' qualquer tipo de prefixac,a~o, ja' que a prefixac,a~o so' ocorre no campo de dados e o receptor so' responde com ACKs ou NAKs com campos de dados vazios ou especiais. O processamento de contadores de repetic,a~o so' pode ser requisitado pelo transmissor e so' sera' utilizado pelo transmissor se o receptor concordar. A prefixac,a~o de oitavo bit e' um caso especial, porque seu uso normalmente na~o e' desejado, ja' que aumenta muito o overhead tanto na transmissa~o quanto na recepc,a~o. No entanto, uma vez que e' o u'nico mecanismo direto para transmissa~o de arquivos bina'rios disponi'vel aos sistemas que usurpam o oitavo bit para paridade, um receptor deve ser capaz de pedir ao trans missor que fac,a a marcac,a~o do oitavo bit, ja' que a maioria dos transmissores normalmente na~o o fara~o por default. O prefixo de repetic,a~o e' imediatamente seguido por um caracter (1 byte) de contador, codificado via func,a~o char(). seguido pelo pro'prio caracter (talvez prefixado por marca dores de controle ou de oitavo bit, como explicado abaixo). O contador de repetic,o~es pode expressar valores de 0 a 94. Se um caracter aparece mais de 94 vezes em uma linha, deve ser "cortado" em 94, emitido com todos os prefixos apropriados assim por diante ate' que todos tenham sido transmitidos. .cp 14 representac,a~o com contador de caracter marcada repetic,o~es para 6 A A ^(A ("(" e' ASCII 40-32=6) ^A #A ^(#A 'A &A ^(&A '^A &#A ^(&#A # ## ^(## '# &## ^(&## & #& ^(#& '& &#& ^(&#& ^ #^ ^(#^ '^ &#^ ^(&#^ NUL #@ ^^#@^:#@ (120 NULs) A representa qualquer caracter imprimi'vel ^A qualquer caracter de controle 'X qualquer caracter com o oitavo bit ligado # e' usado para marcar caracteres de controle & marca caracteres cujo oitavo bit esta' ligado O contador de repetic,o~es deve sempre preceder qualquer outro caracter de prefixac,a~o; e' tomado literalmente (depois de ter sido transformado pela unchar(). Por exemplo: "#" e "&" seguindo imediatamente um "^" denota contadores de repetic,a~o, na~o caracteres de oito bits ou de controle. O caracter de marcac,a~o de controle "#" cerca mais proximamente o caracter de dados, enta~o o prefixo para oito bits e, ai', o contador de repetic,o~es. Em outras palavras a ordem e': prefixo de repetic,a~o e contador marca de oito bits marca de controle caracter de dado. Como ilustrac,a~o, note que &#A na~o e' equivalente a #&A. Quando o bit de paridade esta' disponi'vel para dados, na~o deve ser utilizada a marcac,a~o de oitavo bit e o oitavo bit do caracter prefixado tera' o mesmo valor do oitavo bit do byte original de dados. Neste caso, a tabela fica assim: .cp 14 representac,a~o com contador de caracter marcada repetic,o~es para 6 'A 'A ^('A '^A #'A ^(#'A '# #'# ^(#'# '& '& ^('& Note que, desde que na~o se esta' fazendo marcac,a~o de oitavo bit, "&" na~o esta' sendo usado como um caracter de prefixac,a~o de oitavo bit, porisso na~o precisa ser marcado com "#". Note, tambe'm, que o oitavo bit esta' ligado no argumento final da seque^ncia de repetic,a~o, na~o importando qua~o longa seja e na~o em algum dos caracteres de prefixac,a~o. Lembre-se, finalmente, das seguintes regras: - seque^ncias prefixadas na~o podem ser quebradas de um pacote para outro - os prefixos para controle, oitavo bit e contadores de repetic,a~o devem ser diferentes entre si - os campos de dados de todos os pacotes devem passar pelo mecanismo de codificac,a~o de prefixos, menos os pacotes "S", "I" e "A" e os ACKs para eles. Na primeira regra acima, note que uma seque^ncia prefixada significa um u'nico caracter e todos os seus prefixos, como ^%&#X, na~o uma seque^ncia como #M#J, que sa~o duas seque^ncias prefixadas. ..@bd 8.2. Operac,a~o de SERVER (Servidor) ..@iSERVER, operacao ..@iservidor ..@ioperacao de SERVER Um SERVER e' um programa KERMIT rodando remotamente sem um "interface com o usua'rio". Todos os comandos para o KERMIT SERVER chegam em pacotes do KERMIT LOCAL. A operac,a~o de um KERMIT SERVER e' muito mais conveniente do que a operac,a~o ba'sica, ja' que o usua'rio na~o precisa interagir diretamente com o programa KERMIT remoto uma vez que o tenha acionado em modo SERVER e, dai' em diante, na~o manda mais comandos SEND e RECEIVE complementares, dos dois lados, para conseguir que um arquivo seja transferido. Ao inve's disso, um u'nico comando (SEND ou GET) no KERMIT local basta. Os SERVERs podem oferecer tambe'm servic,os que na~o os de transfere^ncia de arquivos. Entre transac,o~es, um KERMIT SERVER espera pacotes contendo comandos de SERVER. O nu'mero de seque^ncia de pacote sempre volta a 0 depois de uma transac,a~o. Um KERMIT SERVER esperando comando deve ficar procurando um pacote 0 e pacotes de comando mandados para um SERVER devem ser tambe'm 0. Certos comandos de SERVER resultara~o numa troca de diversos pacotes. Tais operac,o~es se processam exatamente como uma transfere^ncia de arquivo. Um programa KERMIT SERVER, esperando por um pacote de comando e' dito "em espera de comando SERVER". Uma vez posto neste estado, o SERVER nunca deve deixa'-lo ate' receber um pacote comandando-o para tal. Isto significa que depois que qualquer transac,a~o termina, normalmente ou por alguma condic,a~o de erro, o SERVER deve voltar ao estado de espera de comando SERVER. Enquanto em espera, um SERVER pode resolver mandar NAKs perio'dicos pelo pacote 0, o esperado pacote de comando. Uma vez que o usua'rio pode ter se desconectado do SERVER por longos peri'odos de tempo (horas), os intervalos entre os NAKs devem ser significativamente maiores que o tempo normal de timeout (digamos: 30-60 segundos, ao inve's de 5-10). Os NAKs perio'dicos sa~o u'teis para quebrar um deadlock que ocorreria se um programa local na~o fosse capaz de entrar em timeout e mandar um comando que se perdesse. Por outro lado podem causar problemas para KERMITs locais que na~o possam limpar seus buffers de input ou para sistemas que fazem cegamente XON/XOFF, forc,ando os NAKs a ficarem bufferi zados no host do SERVER e serem soltos de repente, em massa, quando chegar um XON. Por esta raza~o os SERVERs devem ter uma opc,a~o para preparar um intervalo para "acordar" ou para desabilita'-lo de uma vez. A operac,a~o de SERVER deve ser implementada em dois lugares: no SERVER, propriamente, e em qualquer programa KERMIT que venha a se comunicar com ele. O SERVER tem que ter co'digo para ler comandos SERVER de pacotes e para responde^- los. O USER KERMIT deve ter co'digo para analisar comandos do usua'rio relacionados com o SERVER, formar pacotes de comandos para o SERVER, transmiti-los e manusear as respostas a tais comandos. ..@cd 8.2.1. Comandos SERVER ..@iSERVER, comandos Os comandos SERVER esta~o relacionados abaixo. Nem todos eles foram implementados e alguns podem nunca chegar a se^-lo mas seus usos devem ser reservados. Embora a operac,a~o em modo SERVER seja opcional, certos comandos devem ser implementados em todos os SERVERs. Isto inclui os comandos SEND-INIT (S), RECEIVE-INIT (R) e GENERIC LOGOUT (GL) e/ou FINISH (GF). Se o SERVER recebe um comando que na~o entende ou na~o pode executar, deve responder com um pacote de erro (E) contendo uma mensagem como "UNIMPLEMENTED SERVER COMMAND (comando SERVER na~o implementado)" e ambos os lados devem voltar o nu'mero de seque^ncia de pacote para 0 e o SERVER permanecer em espera por comando. So' um comando GL ou GF pode encerrar uma operac,a~o de SERVER. .cp 20 Os comandos KERMIT sa~o os seguintes: S - SEND-INITIATE (troca para^metros; o SERVER espera arquivo) R - RECEIVE-INITIATE (pede ao SERVER arquivos especificados) I - INITIALIZE (troca para^metros) X - TEXT-HEADER (Permite transferencia de texto para a tela do usua'rio em resposta a um comando gene'rico ou do host. Isto funciona exatamente como uma transfere^ncia de arquivo exceto que o "equipamento de destino" e' uma tela, ao inve's de um arquivo. Os campos de dados podem conter um nome de arquivo, um ti'tulo ou outro cabec,alho qualquer.) C - Comando de host. O campo de dados conte'm uma seque^ncia de caracteres a ser executada pelo host como um comando direto. K - Comando KERMIT. O campo de dados conte'm uma seque^ncia de caracteres na linguagem interativa do KERMIT SERVER (normalmente um comando SET) a ser executada como se houvesse sido digitada a ni'vel de comando. G - Comando KERMIT gene'rico. Um u'nico caracter no campo de dados (possivelmente seguido de operandos, mostrados em chaves, campos opcionais, tambe'm em colchetes) especifica o comando: I LOGIN {[*user[*password[*conta]]]} C CWD, CHANGE WORKING DIRECTORY {[*directory[*password]]} L LOGOUT, BYE F FINISH ("derruba" o SERVER mas na~o da' LOGOUT) D DIRECTORY {[*especificac,a~o-de-arquivo]} U DISK USAGE QUERY {[*area]} E ERASE (DELETE) {*especificac,a~o-de-arquivo} T TYPE {*especificac,a~o-de-arquivo} R RENAME {*nome-antigo*nome-novo} K COPY {*fonte*destino} W quem esta' no ar? (FINGER) {[*ident-do-usua'rio]} W quem esta' no ar? (FINGER) {[*NETWORK HOST[*opc,o~es]]} M mensagem curta {*destinata'rio*texto} H HELP {[*to'pico]} Q SERVER STATUS QUERY P programa {*[espec.arq] [*comandos]} J JOURNAL {*comando[*argumento]} V varia'vel [*comando[*argumento*argumento]]} Note que a codificac,a~o do comprimento do campo e' usada dentro do campo de dados mas na~o dentro dos campos de dados de outros pacotes como S, I, R, X, K e C. Um asterisco (*), como usado acima, representa um campo de comprimento de um u'nico caracter, codificado via char(), para o operando que o segue; assim, comprimentos de 0 a 94 podem ser especificados; isto permite que operandos mu'ltiplos sejam claramente delimitados a despeito de seus conteu'dos. Todos os comandos SERVER que mandam argumentos em seus campos de dados devem passar pelo mecanismo de codificac,a~o de prefixos. Assim se um caracter de dados ou campo de comprimento acontece de corresponder a um caracter de prefixo ativo, ele pro'prio deve ser prefixado. O comprimento do campo denota o comprimento do campo antes da codificac,a~o de prefixo e (ainda bem!) depois da decodificac,a~o. Por exemplo, para mandar um comando gene'rico com dois campos, "ABC" e "ZZZZZZZZ", primeiro cada campo seria prefixado por char() de seu comprimento, neste caso char(3) e char(8), dando "#ABC(ZZZZZZZZ". Mas "#" e' o caracter de prefixo de controle normal, dai' deve repetir o prefixo (se o contador de repetic,o~es estiver ativo), de modo que o resultado da codificac,a~o seja "##ABC(~(Z" (assumindo que o prefixo de repetic,a~o seja til - "~"). O receptor decodifica de volta para o "#ABC(ZZZZZZZZ" original antes de tentar extrair os dois campos. Uma vez que um comando gene'rico deve caber em um u'nico pacote, o programa que manda o comando se assegura que cabe mesmo e na~o inclui campos de comprimento que apontam para depois do fim do pacote. Os SERVERs, no entanto, devem ser defensivos e na~o tentar processar qualquer caracter depois do campo de dados, mesmo se o campo de comprimento do argumento o leve a fazer isso. ..@cd 8.2.2. Temporizac,a~o ..@itemporizacao O KERMIT na~o prove^ um mecanismo para suspender e continuar uma transac,a~o. Isto significa que um texto mandado para a tela do usua'rio na~o deve ser "congelado" por longos peri'odos (i. e': na~o mais que o peri'odo de timeout vezes o limite de tentativas). Entre transac,o~es, quando o SERVER na~o tem servic,os pendentes, pode mandar NAKs perio'dicos (sempre com checksums do tipo 1) para evitar um deadlock no caso de um comando seja mandado para ele e perdido. Tais NAKs podem se empilhar no buffer de input do KERMIT USER (se ele tiver um), assim o KERMIT USER deve estar preparado para "limpar" seu buffer de input antes de mandar um comando para um SERVER. Enquanto isso, os SERVERs devem reconhecer que alguns sistemas na~o permitem que, por programa, se fac,a isto (ou, quando o fazem, o processo pode ser atrapalhado pelo firmware de controle de fluxo do sistema) e, enta~o, ter um jeito de deixar de mandar (ou diminuir o ri'tmo de) os NAKs de espera de comando. ..@cd 8.2.3. O Comando "R" ..@icomando, R O pacote R, geralmente mandado por um programa KERMIT local cujo usua'rio teclou um comando GET, diz ao SERVER para mandar os arquivos especificados por nome no campo de dados do pacote R. Ja' que na~o podemos assumir que dois KERMITs estejam rodando em sistemas semelhantes, o KERMIT (USER) local deve encarar a especificac,a~o do arquivo como uma cadeia de caracteres e deixar o SERVER analisa'-la. Se o SERVER puder abir e ler o arquivo especificado, ele o transmite um pacote SEND-INIT (S) (na~o um ACK !) para o USER e completa a transac,a~o de transmissa~o de arquivo, como ja' descrito. Se o SERVER na~o pode mandar o arquivo, deve responder com um pacote de erro (E) contendo a raza~o, como "FILE NOT FOUND (arquivo na~o encontrado)" ou "READ ACCESS REQUIRED (exigido acesso para leitura)". ..@cd 8.2.4. Respostas Curtas e Respostas Longas ..@irespostas curtas e longas Qualquer pedido feito a um SERVER pode ser respondido de duas formas e qualquer USER KERMIT que faz tal pedido deve estar preparado para qualquer uma delas: * Uma resposta curta. Consiste em um simples pacote ACK, que pode conter texto em seu campo de dados. Por exemplo, o usua'rio pode pedir informac,o~es sobre espac,o em disco ao SERVER e ele responder com uma curta cadeia de caracteres no campo de dados de seu pacote de ACK, como "12K BYTES FREE (12K bytes disponi'veis)". O USER KERMIT deve mostrar este texto em sua tela. * Uma resposta longa. Funciona como uma transfere^ncia de um arquivo (e em alguns casos pode se tratar disso mesmo). Comec,a com um dos seguintes: * um pacote "F" de cabec,alho de arquivo (seguido, opcionalmente, por um ou mais pacotes de atributos, discutidos mais tarde); * um pacote "X" de cabec,alho de texto; * um pacote "S" (SEND-INIT) seguido por um pacote "X" ou "F"; Depois do pacote X ou F vem um nu'mero arbitra'rio de pacotes de dados ("D") e, enta~o, um pacote "Z" (END-OF-FILE) e, finalmente, um pacote "B" (BREAK-TRANSMISSION), como para uma transfere^ncia normal de um arquivo. ..@cd 8.2.5. Comandos SERVER Adicionais ..@iSERVER, comandos adicionais ..@icomandos SERVER adicionais Os comandos SERVER a seguir pedem ao SERVER para executar tarefas que na~o as de transmitir e receber arquivos. Quase todos eles sa~o passi'veis de respostas curtas ou longas. Por exemplo, o comando ERASE gene'rico (GE) pode gerar um simples ACK ou uma rajada de pacotes contendo os nomes de todos os arquivos que ele apagou (ou na~o). Vejamos agora tais comandos em mais detalhes, os argumentos sa~o como providos nos comandos teclados para o USER KERMIT (sujeitos a codificac,a~o de prefixo); nenhuma transformac,a~o a qualquer forma normal ou cano^nica e' feita: nomes de arquivos e outros operandos esta~o na sintaxe do sistema host do SERVER. I LOGIN. Para uso quando um KERMIT SERVER e' mantido perpetuamente rodando numa linha dedicada. Isto permite a um novo usua'rio identificar-se perante o sistema do host. Se o campo de dados estiver vazio, ele remove a identificac,a~o do usua'rio, de forma que o pro'ximo na~o tenha acesso ao host com a mesma identificac,a~o. Um SERVER dedicado como este deve provavelmente desabilitar os comandos gene'ricos L e F, descritos abaixo. L LOGOUT, BYE. Este comando "derruba" o SERVER inteiramente, fazendo-o encerrar seu pro'prio JOB. Deve ser usado quando o SERVER foi iniciado manualmente pelo usua'rio que, enta~o, deve derruba'-lo remotamente. F FINISH. Isto e' para permitir que o usua'rio possa derrubar o SERVER, colocando seu terminal de volta ao modo normal (diferente de bina'rio ou natural) e o JOB do SERVER devolvido ao ni'vel de comando de sistema, ainda "logado", de forma a poder continuar seus afazeres no host. C CWD. Este comando torna ativo o direto'rio ou a'rea default para transfere^ncia de arquivos no host do SERVER. Sem operandos, passa a ser a pro'pria a'rea default do usua'rio. D DIRECTORY. Manda uma listagem do direto'rio para o usua'rio. O USER KERMIT tanto pode mostra'-la na tela quanto armazena'- -la em disco. Normalmente e' aceito algum tipo de designador de grupos de arquivos para pedir que o SERVER so' liste os nomes de arquivos cujos nomes satisfac,am a regra dada. U DISK USAGE QUERY. O SERVER responde com o total de espac,o em disco usado e livre em Kbytes (ou outra unidade, que deveria ser especificada). E ERASE (DELETE). Apaga o arquivo ou o grupo de arquivos especificado. T TYPE. Manda o arquivo ou grupo deles, indicando (comec,ando com um pacote X ao inve's de um F ou usando o atributo TYPE) que o arquivo deve ser mandado para a tela e na~o armazenado. R RENAME. Muda o nome do arquivo ou arquivos como indicado. A seque^ncia de caracteres indicando o novo nome pode conter outros atributos, como co'digo de protec,a~o, permitido nas especificac,o~es de arquivo do host. K COPY. Produz uma co'pia do arquivo ou grupo deles, como indicado, deixando o(s) arquivo(s) fonte(s) intacto(s). W WHO'S LOGGED IN? (FINGER). Sem argumentos, lista todos os usua'rios usando o sistema do host no momento. Se for especificado algum argumento, prove^ informac,o~es mais detalhadas sobre o usua'rio ou host da rede especificado. M SHORT MESSAGE. Manda o bilhete (de um u'nico pacote) para a tela do usua'rio indicado. P PROGRAM. Este comando tem dois argumentos: nome do programa [especif.arq.] e parametros para o programa. O primeiro campo e' exigido mas pode ser deixado nulo (i. e': comprimento zero). Se for nulo, o programa correntemente carregado e' alimentado com o comando. Se na~o nulo, o programa especificado e' carregado e iniciado; se um comando de programa for dado, e' passado para o programa que entrou como se fosse um comando inicial (por exemplo, como uma linha de argumentos em sistemas que aceitam tal conceito). Em qualquer um dos casos, a sai'da do programa e' mandada de volta em forma de respostas curtas ou longas, como ja' descrito. J JOURNAL. Este comando controla o "dia'rio" da transac,a~o do SERVER. O campo de dados conte'm um dos seguintes: + Comec,a a anotar a transac,a~o. Se e' dado um nome de arquivo, fecha qualquer transac,a~o ora aberta e abre o arquivo especificado como o novo LOG de transac,a~o. Se na~o existe LOG aberto nem e' dado um nome de arquivo, o SERVER deve abrir um arquivo com um nome default, como TRANSACTION.LOG. - Para de anotar a transac,a~o mas na~o fecha o LOG corrente. C Para de anotar a transac,a~o e fecha o LOG corrente. S Transmite o LOG. Se aberto, fecha-o primeiro. Anotar uma transac,a~o e' registrar o progresso de transfere^ncias de arquivos. Deve conter entradas mos trando o nome de cada arquivo transferido, quando a transfere^ncia comec,ou e quando acabou, se terminou com sucesso e, se na~o, por que. V Arma ou inquire uma varia'vel. O comando pode ser S ou Q. O primeiro argumento e' o nome da varia'vel. O segun do, se houver, e' seu valor. S Arma o valor da varia'vel especificada com o valor especificado. Se o valor for nulo, elimina a varia'vel. Se ela na~o existe, cria. O SERVER deve responder com um ACK cujo campo de dados conte'm um Y para indicar que a varia'vel foi preparada ou N, caso contra'rio; um campo de dados vazio vale um Y. Q questiona sobre o valor da varia'vel declarada. Se na~o for declarado um nome, mostra o valor de todas as varia'veis ativas. O SERVER responde com uma resposta curta ou longa, como descrito acima. Se a varia'vel na~o existe, volta um valor nulo. Os nomes das varia'veis sa~o cadeias de caracteres e tem caracteres como valores. Podem ser esta'ticas ou dina^micas. Por exemplo, um SERVER pode ter varia'veis built-in como "SYSTEM NAME", que nunca mudam, ou outras como "MAIL STATUS" que, quando inquirida, faz com que o SERVER busque alguma corresponde^ncia para o usua'rio. ..@cd 8.2.6. Comandos de Host ..@ihost, comandos ..@icomandos de host Sa~o conceitualmente simples mas podem ser difi'ceis de implementar em alguns sistemas. O pacote C contem um texto em seu campo de dados que e' simplesmente passado para o processador de comandos do sistema do host do SERVER; qualquer sai'da desse processador e' mandada de volta para o usua'rio no KERMIT em pacotes, em mensagens curtas ou longas. A implementac,a~o dessa facilidade sob UNIX, com sua estrutura processual em "fork" e seu redirecionamento de I/O via "pipes", e' muito natural. Em outros sistemas pode se tornar virtualmente impossi'vel. ..@cd 8.2.7. Trocando Para^metros Antes de Comandos SERVER ..@iSERVER, trocando parms antes No KERMIT ba'sico, a troca SEND-INIT sempre e' suficiente para configurar os dois lados entre si. Por outro lado, durante uma operac,a~o SERVER, algumas operac,o~es podem na~o comec,ar com um pacote SEND-INIT. Por exemplo, quando o USER manda um pacote R (pedindo para mandar um arquivo), o SERVER escolhe que opc,a~o de checagem de bloco usar. Ou se o usua'rio pede uma listagem do direto'rio, o SERVER na~o sabe que comprimento de pacote usar. A soluc,a~o e' o pacote "I" (INIT-INFO). E' exatamente como um pacote SEND-INIT e o ACK age exatamente da mesma forma. Entretanto, a recepc,a~o de um pacote I na~o implica na transic,a~o para o status de transmissa~o de arquivo. A troca do pacote I simplesmente permite que os dois lados ajeitem seus para^metros, preparando-se para a pro'xima transac,a~o. Um SERVER em espera de comando deve ser capaz de rece ber um pacote I e mandar um ACK por ele. Um KERMIT USER, no entanto, na~o precisa mandar pacotes I; neste caso, o SERVER assume todos os valores default para o USER relacionados na sec,a~o sobre prefixac,a~o, neste capi'tulo, ou qualquer que seja o valor para o para^metro, armado por outro meio (por exemplo, comandos SET teclados para o SERVER antes dele ser posto em modo SERVER). .cp5 ..@bd 8.3. Tipos alternativos de checagem de bloco ..@itipos alternativos de checagem de bloco ..@ichecagem de blocos, tipos alternativos ..@ibloco, tipos alternativos de checagem Existem dois tipos opcionais de cheques de bloco: TIPO 2 ====== Um checksum de 2 caracteres baseado nos 12 bits de mais baixa ordem da soma aritme'tica dos caracteres no pacote (do campo de comprimento ate' o u'ltimo caracter do campo de dados, inclusives) como se segue: 1 2 ---------+--------------+-------------+ dados | char(B6-B11) | char(B0-B5) | ---------+--------------+-------------+ Por exemplo, se o resultado de 16 bits for 154321 (octal), os dois caracteres de checagem de bloco seriam "C1". TIPO 3 ====== Um CRC-CCITT de 3 caracteres de 16 bits. O ca'lculo CRC trata os dados que opera como uma cadeia de bits com o bit de mais baixa ordem do primeiro caracter primeiro e o bit de mais alta ordem do u'ltimo caracter por u'ltimo. O valor inicial do CRC e' 0; o CRC de 16 bits e' o resto da divisa~o da cadeia pelo polino^mio 16 12 5 X + X + X + 1 (este ca'lculo, na realidade, pode ser feito um byte de cada vez, usando-se uma tabela simples e um algori'tmo de busca). O resultado e' representado como tres caracteres imprimi'veis no fim do pacote, assim: ---------+---------------+--------------+--------------+ dados | char(B12-B15) | char(B6-B11) | char (B0-B5) | ---------+---------------+--------------+--------------+ Por exemplo, se o resultado de 16 bits for 154321 (octal), enta~o o cheque de bloco de 3 caracteres seria "-C1". A te'cnica CRC escolhida aqui concorda com muitas implementac,o~es de hardware (p.e. a instruc,a~o CRC do VAX). Uma refere^ncia u'til para ca'lculos de CRC por tabela pode ser vista no artigo "BYTE-WISE CRC CALCULATIONS" de Aram Perez, na IEEE MICRO de junho de 1983, pa'gina 40. O checksum de um u'nico caracter se provou deveras adequado na pra'tica. As outras opc,o~es so' podem ser emprega das se os dois lados concordarem via troca de pacotes INIT (S ou I). Os cheques de bloco de 2 ou 3 caracteres tambe'm so' devem ser empregados sob severas condic,o~es de rui'do de linha e adulterac,a~o de pacotes. Ja' que cheques dos tipos 2 e 3 sa~o opcionais, nem todos os KERMITs sa~o capazes de entende^-los. Por este motivo, uma comunicac,a~o deve comec,ar com o tipo 1. Se durante a troca de pacotes S ou I o uso dos tipos 2 ou 3 forem aceitos pelos dois lados, a mudanc,a sera' levada a cabo somente depois que o SEND-INIT houver sido enviado e um ACK por ele recebido, usando-se o tipo 1 de checagem de bloco. Isto significa que o primeiro pacote com checagem do tipo 2 ou 3 sempre sera' um F ou um X. Depois de completada a transac,a~o, ambos os lados devem voltar ao tipo 1 (uma vez que nenhum dos dois lados pode saber se o outro parou e recomec,ou). A transac,a~o termina depois que um pacote B ou E foi transmitido e recebeu seu ACK ou depois de haver ocorrido qualquer erro que terminasse a transac,a~o prematura ou anormalmente. Uma conseque^ncia desta regra e' que se se vai usar uma checagem de bloco do tipo 2 ou 3, uma resposta longa mandada pelo SERVER deve comec,ar com um pacote SEND-INIT (S), mesmo se uma troca de pacote I ja' ocorreu. Se o tipo 1 esta' sendo empregado, o pacote S pode ser enviado e a transfere^ncia pode comec,ar com um pacote X ou F. Um SERVER que completou uma transac,a~o e esta' esperando um novo comando pode mandar NAKs perio'dicos por ele (pacote 0). Tais NAKs devem ter cheques de bloco do tipo 1. O uso de tipos alternados de cheques de bloco pode causar certas complicac,o~es. Por exemplo, se o SERVER recebe um erro "horri'vel" (ta~o ruim que nem consegue mandar um pacote de erro) e reverte em espera de comando, o fato de ficar mandando NAKs por pacote 0, usando cheque de bloco tipo 1, enquanto uma transfere^ncia usando tipo 2 ou 3 estava em progresso, fara' com que nenhum dos lados seja capaz de entender os pacotes do outro. A comunicac,a~o pode inclusive se estrangular se A manda um SEND-INIT pedindo cheque de bloco tipo 3, por exemplo, B ACK o pedido, passa para tipo 3 e espera por um pacote X ou F com cheque de bloco deste tipo mas o ACK se perdeu; dai'... A retransmite o pacote S com tipo 1. Situac,o~es como esta se resolvera~o, na pior das hipo'teses, depois que os dois lados atinjam seus limites de retransmisso~es mas podem ser retificadas antes atrave's do uso de duas heuri'sticas: - a rotina de leitura de pacotes assume que se o pacote e' S, enta~o o tipo de cheque de bloco e' o 1; - um pacote NAK na~o tem conteu'do em seu campo de dados; dai' o tipo de cheque de bloco pode ser deduzido pela rotina de leitura de pacotes pelo campo de comprimento de um NAK; de fato, e' o valor do campo de comprimento menos 2; um NAK pode, assim, ser encarado com um tipo de "sincronizador universal". Estas heuri'sticas tendem a desvirtuar a natureza desenhada do protocolo, uma vez que a rotina de leitura de pacotes normalmente na~o deve se preocupar com o tipo de pacote (que e' de interesse do ni'vel de aplicac,a~o que chama a rotina de leitura de pacotes). Um desenho melhor teria cada pacote inclui'do como um indicador do tipo de seu pro'prio cheque de bloco; isto deixaria o tipo ser trocado dinamicamente durante uma transac,a~o. Mas e' muito tarde para isto, agora... ..@bd 8.4. Interrompendo uma transfere^ncia de arquivo ..@itransferencia, interrompendo ..@iinterrompendo transferencia ..@iarquivo, interrompendo transferencia Esta sec,a~o descreve uma facilidade opcional do protocolo KERMIT que permite uma interrupc,a~o elegante de uma transfere^ncia de arquivo. Esta facilidade na~o se relaciona com operac,a~o de SERVER. Para interromper o envio de um arquivo, mande um pacote EOF (Z) em lugar do pro'ximo pacote de dados, incluindo um D (que significa "dispense") no campo de dados. O receptor manda um ACK pelo pacote Z, normalmente, mas na~o retem o arquivo. Isto na~o interfere com os antigos KERMITs que estiverem na recepc,a~o: eles na~o inspecionam o campo de dados e fecham normalmente o arquivo. O mecanismo pode ser engatilhado teclando-se um caracter de interrupc,a~o no console do programa KERMIT transmissor. Se um grupo de arquivos (wildcard) esta' sendo mandado, e' possivel pular para o pro'ximo arquivo ou encerrar todo o batch. O protocolo e' o mesmo em qualquer um dos casos mas a ac,a~o poderia ser selecionada por diferentes caracteres de interrupc,a~o, e.g. CTRL-X para passar para o pro'ximo arquivo, CTRL-Z para acabar de uma vez. Para interromper o receptor, ponha um X no campo de dados de um ACK por um pacote de dados. Para interromper a recepc,a~o de todo um grupo de arquivos, use um Z. O usua'rio pode engatilhar este mecanismo teclando um caracter de interrupc,a~o, digamos, CTRL-X ou CTRL-Z, respectivamente, no console do KERMIT receptor. Um transmissor que conhec,a tal facilidade, ao encontrar um desses co'digos, agiria como descrito acima: mandaria um pacote Z com um co'digo D; um transmissor que na~o implemente esta facilidade simplesmente ignoraria os co'digos e continuaria transmitindo. Neste caso e se o usua'rio quizesse interromper todo o batch (ou somente um arquivo), o programa KERMIT receptor, depois de descobrir que o transmissor ignorou o co'digo X ou Z, poderia mandar um pacote de erro (E) para parar a transfere^ncia. O transmissor pode tambe'm decidir mandar um pacote Z contendo o co'digo D quando descobre que o arquivo que esta' transmitindo na~o pode ser enviado correta ou completamente. Por exemplo, depois de haver mandado corretamente alguns pacotes, aparece um erro de leitura; ou repara que o "oitavo bit" de um dos bytes do arquivo de texto que esta' sendo transmitido esta' ligado e na~o sa havia feito proviso~es de transmissa~o de oito bits. ..@bd 8.5. Transmitindo atributos de arquivos ..@iarquivo, transmitindo atributos ..@iatributos ..@itransmitindo atributos de arquivos O pacote opcional de atributos (A) prove^ um mecanismo para que o transmissor de um arquivo possa dar maiores infor mac,o~es sobre ele. Este pacote pode ser mandado se o receptor indicar sua capacidade em processa'-lo, ligando o bit de atributo na ma'scara de capacidade. Se os dois lados ligam este bit na ma'scara de capacidade, o transmissor, depois de mandar o nome do arquivo no pacote F e receber o ACK correspondente, pode (mas na~o tem que) mandar um pacote A com informac,o~es de atributos do arquivo. Ligar o bit de atributo na ma'scara de capacidade na~o indica suporte a qualquer atributo em particular, somente que o receptor esta' preparado para receber o pacote A. Os atributos sa~o mandados no campo de dados do pacote A. Este campo consiste de 0 ou mais subcampos, que podem ocorrer em qualquer ordem. Cada subcampo e' da seguinte forma: +----------+-------------------+-------+ | atributo | char(comprimento) | dados | +----------+-------------------+-------+ onde atributo e' um u'nico caracter imprimi'vel diferente de espac,o, comprimento e' o comprimento dos caracteres de dados (0 a 94), com 32 somado para produzir um u'nico caracter imprimi'vel e dados e' "comprimento" caracteres com dados, todos imprimi'veis. Nenhuma prefixac,a~o ou marcac,a~o e' feita nesses dados. Mais de um pacote de atributos pode ser mandado. A u'nica exige^ncia e' que todos os pacotes A para um arquivo devem seguir imediatamente seu pacote de cabec,alho de arquivo (F) e preceder o primeiro pacote de dados. Podem existir 93 atributos diferentes, um para cada caracter ASCII imprimi'vel diferente de espac,o. Esta~o associados na ordem ASCII. ! (ASCII 33) Comprimento. O campo de dados da' o comprimento em K (1024) bytes, como um nu'mero decimal imprimi'vel, e.g. "!#109". Isto permitira' que o receptor determine com antecede^ncia se existe espac,o suficiente para o arquivo e/ou quanto tempo durara' a transfere^ncia. " (ASCII 34) Tipo. O campo de dados pode conter algum indicador da natureza do arquivo. Os operandos aparecem dentro de {chaves}, i'tens opcionais entre [colchetes]. A{[xx]} Texto ASCII, na~o contendo quantidades com 8 bits, registros lo'gicos (linhas) delimi tados pela seque^ncia de caracteres (marca) de controle [xx], representada aqui pela sua contraparte imprimi'vel (MJ = CRLF, J = LF etc.). Por exemplo "AMJ" significa que o aparecimento de #M#J (a seque^ncia normal CRLF prefixada) num pacote de dados de arquivo indica o fim de um registro, assu mindo que o prefixo de controle corrente seja "#". Se [xx] for omitido, sera' assu mido MJ. B{[xx]} Bina'rio. [xx] indica de que maneira o arquivo e' bina'rio: 8 (default) o arquivo e' uma seque^ncia de bytes de 8 bits, que devem ser salvos como esta~o. O oitavo bit pode ser mandado nu' ou prefixado de acor do com a negociac,a~o SEND-INIT acerca da prefixac,a~o de oitavo bit. 36 O arquivo esta' no formato PDP-11, no qual 5 dos 7 bits do byte ficam numa palavra de 36 bits, com o u'ltimo bit de cada palavra representando o "bit de paridade" de cada quinto caracter (talvez prefixado). D{x} Move daqui para atributo de formato F{x} Move daqui para atributo de formato I{[x]} Imagem. O arquivo esta' sendo transmitido exatamente como representado no sistema de origem. Para uso entre sistemas semelhantes. Existem [x] bits usa'veis por caracter, antes de uma prefixac,a~o. Por exemplo, para mandar dados bina'rios de um sistema com bytes de 9 bits, pode ser conveniente mandar 3 caracteres de 6 bits para cada 2 bytes de 9 bits. O valor default para [x] e' 8. # (ASCII 35) Data de criac,a~o, expressa no formato "[yy]yymmdd[hh:mm[:ss]] (formato juliano padra~o ISO), e.g. 850731 15:51. A hora e' opcional; se dada, deve estar no formato "24 horas", os segundos podem ser omitidos e um u'nico espac,o deve separar a hora da data. $ (ASCII 36) Identificac,a~o do criador, expressa numa cadeia de caracteres de comprimento dado. % (ASCII 37) Conta onde sera' cobrado o arquivo, expressa numa cadeia de caracteres de comprimento dado. & (ASCII 38) a'rea onde o arquivo sera' armazenado, expressa numa cadeia de caracteres de comprimento dado. ' (ASCII 39) Password para a a'rea descrita acima, cadeia de caracteres. ( (ASCII 40) Tamanho do bloco. O arquivo tem ou deve ser armazenado com o dado tamanho. ) (ASCII 41) Acesso: N Novo, o caso normal - cria um arquivo com o nome dado. S SUPERSEDE (OVERWRITE) qualquer arquivo do mesmo nome. A Acrescenta ao arquivo de nome dado. * (ASCII 42) Codificac,a~o: A ASCII, codificac,a~o normal, com qualquer prefixac,a~o necessa'ria. H Codificac,a~o hexadecimal (em nibbles). E EBCDIC (mandado como se fosse um arquivo bina'rio). S Conjunto de caracteres SIXBIT (equivalente a 16). R RADIX50. X Encriptado. Q{x} Codificac,a~o Huffman de compressa~o. Os primeiros x bytes do arquivo sa~o a chave. + (ASCII 43) Disposic,a~o (os operandos sa~o especificados na sintaxe do sistema do host receptor): M{usua'rio(s)} manda o arquivo como correio para o(s) usua'rio(s) especificado(s). O{destino} manda o arquivo como mensagem longa para terminal para o destino especificado (terminal, JOB ou usua'rio). S{[opc,o~es]} submete o arquivo como um JOB para batch do sistema, com as opc,o~es especificadas. P{[opc,o~es]} imprime o arquivo numa impressora do sistema, com as opc,o~es especificadas (uma impressora em particular, formula'rio etc.). T Tecla o arquivo na tela. L{[aaa]} Carrega o arquivo na memo'ria no enderec,o dado (opcional). X{[aaa]} Carrega o arquivo na memo'ria (no enderec,o dado) e executa-o. A Armazena o arquivo; salva o arquivo junto com os pacotes de atributo que o precederam, de forma a poderem ser mandados de volta ao sistema de origem com todos seus atributos intactos. Um arquivo armazenado desta maneira pode ser marcado especialmente de forma que o KERMIT que o mande de volta reconhec,a as informac,o~es de atributo como distintas do arquivo de dados. , (ASCII 44) Protec,a~o. Co'digo de protec,a~o para o arquivo, na sintaxe do sistema de arquivos do host. Sem operandos, armazena de acordo com a protec,a~o default do sistema para a a'rea designada como destino. - (ASCII 45) Protec,a~o. Co'digo de protec,a~o para o arquivo em relac,a~o ao "pu'blico" ou ao "mundo", expresso geralmente em uma quantidade de 16 bits, tornada imprimi'vel via char(), no qual os bits tem o seguinte significado: B0: acesso para leitura B1: " " gravac,a~o B2: " " execuc,a~o B3: " " append B4: " " apagar B5: listagem de direto'rio Um 1 na posic,a~o do bit significa habilitar o tipo de acesso correspondente, um 0, proibir. Por exemplo, a letra E neste campo daria o acesso a` leitura, execuc,a~o e listagem do direto'rio (unchar("E") = 69-32 = 37 = 100101 bina'rio). . (ASCII 46) Ma'quina e sistema operacional de origem. E' u'til em conjunc,a~o com o atributo de disposic,a~o do arquivo. Permite que um arquivo, uma vez armazenado, seja transferido entre diferentes tipos de sistemas, mantendo seus status de arquivo, ate' que se encontre em uma ma'quina com as caracteri'sticas certas para utiliza'-lo. Os sistemas sa~o denotados por co'digos; o primeiro caracter e' o designador maior de sistema, o segundo indica o modelo ou sistema operacional. Um terceiro caracter pode ser acrescentado para fazer maiores distinc,o~es, por exemplo a versa~o do sistema operacional. Os sistemas abaixo na~o formam uma colec,a~o completa; muitos mais podem e provavelmente sera~o inclui'dos. A Apple Microcomputers 1 Apple ][, DOS 2 Apple III 3 MacIntosh 4 Lisa B Sperry (UNIVAC) Mainframes 1 Se'rie 1100, EXEC C CDC Mainframes 1 Se'rie Cyber, NOS D DEC Systems 1 DECSYSTEM-10/20, TOPS-10 2 DECSYSTEM-10/20, TOPS-20 3 DECSYSTEM-10/20, TENEX 4 DECSYSTEM-10/20, ITS 5 DECSYSTEM-10/20, WAITS 6 DECSYSTEM-10/20, MAXC 7 VAX-11, VMS 8 PDP-11, RSX-11 9 PDP-11, IAS A PDP-11, RSTS/E B PDP-11, RT-11 C PROFESSIONAL-300, P/OS D WORD PROCESSOR (WPS ou DECMATE), WPS D Honeywell Mainframes 1 Sistemas Multic 2 Se'rie DPS, CP-6 F Ma'quinas Data General 1 RDOS 2 AOS G Ma'quinas Prime, PRIMOS H Ma'quinas Hewlett-Packard 1 HP-1000, RTE 2 HP-3000, MPE I I.B.M. Se'ries /370 e compati'veis 1 VM/CMS 2 MVS/TSO 3 DOS 4 MUSIC 5 GUTS 6 MTS J Tandy Microcomputers, TRSDOS K Atari Micros, DOS L-T (reservado) U Sistemas operacionais ou arquivos porta'veis 1 UNIX 2 Software Tools 3 CP/M-80 4 CP/M-86 5 CP/M-68K 6 MP/M 7 CP/M concorrente 8 MS-DOS 9 UCSD P-system A MUMPS / (ASCII 47) Formato dos dados dentro dos pacotes. A{xxx} Registros delimitados de comprimento varia'vel, terminados pela seque^ncia de caracteres {xx}, onde xx e' uma cadeia de caracteres de um ou mais caracteres de controle, representado aqui por seus equivalentes imprimi'veis na~o prefixados, e.g. MJ para ^M^J (CRLF). D{x} Registros na~o delimitados de comprimento varia'vel. Cada registro lo'gico comec,a com um campo de comprimento de {x} caracteres decimais ASCII (similar ao formato ANSI "D" de fita). Por exemplo, "D$" indicaria campos de comprimento de 4 di'gitos, como "0123". F{xxxx} Registros na~o delimitados de comprimento fixo. Cada registro lo'gico tem {xxxx} bytes. R{x} Para transfere^ncias orientadas para registros, a ser empregado combinado com um dos formatos dados acima. Cada registro comec,a (no caso do formato D, depois co campo de comprimento) com um campo de posic,a~o de {x} caracteres indicando a posicao do byte dentro do arquivo onde este registro deve ser colocado. 0 (ASCII 48) Para^metros especiais dependentes de sistema para armazenar o arquivo no sistema de origem, para especificac,a~o de atributos exo'ticos na~o cobertos explicitamente por qualquer dos descritores de atributos do KERMIT. Sa~o dados por uma cadeia de caracteres na pro'pria linguagem do sistema, por exemplo uma lista de para^metros de uma DCB, usando a Job Control Language IBM. 1-@ (ASCII 49-64) (reservado) Outros atributos podem ser imaginados e acrescentados mais tarde, se desejado. No entanto, dois pontos importantes devem ser observados: - O receptor pode na~o ter, absolutamente, forma alguma de honrar, ou mesmo gravar, um dado atributo. Por exemplo, o CP/M-80 na~o tem lugar para data de criac,a~o nem identificac,a~o do criador em sua FCB; o DEC-20 na~o tem o conceito de tamanho de bloco etc. - O receptor pode na~o ter forma de determinar os valores corretos de qualquer dos atributos. Isto e' particularmente verdade ao transmitir arquivos de origem estrangeira. O mecanismo do pacote A prove^ somente uma maneira de mandar certas informac,o~es sobre um arquivo para o receptor, sem garantia do que pode ser feito por quem recebe com o arquivo. Tal informac,a~o pode ser conseguida diretamente da entrada no direto'rio do arquivo (FCB,FDB, ...) ou especificado via comando de usua'rio. O ACK pelo pacote A pode, por sua vez, ter informac,o~es em seu campo de dados. No entanto, nenhuma negociac,a~o complicada acerca de atributos de arquivo pode ter lugar, porisso o resultado li'quido e' que o receptor tanto pode aceitar quanto recusar o arquivo. Pode responder ao pacote A com um ACK contendo, em seu campo de dados, qualquer um dos co'digos a seguir: <NULL> (campo de dados vazio) Aceitei o arquivo; va' em frente, transmita-o! N{[xxx]} Recusarei o arquivo como especificado, na~o o transmita! [xxx] e' uma cadeia de zero ou mais dos caracteres de atributo listados acima, para especificar quais aqueles estou rejeitando (e.g. "!" significa que e' muito longo, "&" que na~o tenho acesso a` a'rea especificada etc.) Y{[xxx]} Concordo em receber o arquivo mas na~o posso honrar os atributos [xxx], de modo que armazena-lo-ei de acordo com meus pro'prios defaults. Y (caso degenerado do anterior, equivalente ao <NULL>, acima.) Como o receptor realmente responde, e' uma decisa~o de implementac,a~o. Um NAK em resposta ao pacote A significa, claro, que o receptor na~o recebeu o "A" corretamente, na~o que se recuse a receber o arquivo. ..@bd 8.6. Tabela de estados do Protocolo KERMIT Avanc,ado ..@iestado, tabela avancada ..@iprotocolo, estados avancados ..@itabela dos estados do protocolo avancado A tabela simples apresentada anteriomente e' suficiente para se implementar um KERMIT ba'sico. A tabela de estados a seguir cobre todo o protocolo KERMIT, incluindo desde modo SERVER e comandos de transmissa~o ate' KERMIT SERVER. Na~o inclui o manuseio do pacote A, de atributos de arquivo. Note que os estados cujos nomes comec,am com "SEND" sempre mandam um pacote cada vez que entram (mesmo quando o estado anterior era o mesmo). Estados que comec,am com "REC" sempre esperam por um pacote a ser recebido (ate' o limite para timeout) e processa o pacote recebido. Estados cujos nomes na~o incluem "SEND" ou "REC" na~o processam pacotes diretamente; Sa~o estados que executam alguma operac,a~o local e mudam para outro estado. O estado inicial e' determinado pelo comando do usua' rio. Um comando "SERVER" entra em REC-SERVER-IDLE (inativi dade R/S). Um comando "SEND" entra em SEND-INIT. Um comando "RECEIVE" (a antiga versa~o na~o-SERVER, na~o um comando "GET") entra em REC-INIT. Qualquer comando gene'rico, o "GET" e o "HOST" entram tanto em SEND-SERVER-INIT quanto em SEND-GEN- CMD, dependendo da resposta esperada. Sob "MENS.REC." (mensagem recebida), e' mostrado o tipo de pacote da mensagem que chega, seguido pelo nu'mero dele entre pare^nteses; (n) e' o pacote corrente, (n-1) e (n+1) o pre'vio e pro'ximo pacote (mo'dulo 64), (0) e' pacote 0. Seguin do o nu'mero do pacote pode aparecer uma barra e uma letra, indicando algum sinal especial no campo de dados. Por exem plo, Z(n)/D indica um pacote Z (EOF), nu'mero sequencial n, com um "D" em seu campo de dados. Sob "AC,A~O", "R+" significa que o contador de tentativas e' incrementado e comparado com um limite. Se tal limite for excedido, um pacote de erro e' mandado e o estado muda para "ABORT". "N+" quer dizer que o nu'mero de pacote e' incremen tado, mo'dulo 64, e o contador de tentativas, R, e' devolvido a zero. .pa ESTADO MENS.REC. AC,A~O PROX.ESTADO ====== ========= ==== =========== REC-SERVER-IDLE -- SERVER esperando alguma mensagem Po~e N e R em 0 I(0) Manda ACK REC-SERVER-IDLE S(0) Processa parms, ACK c/parms, N+ REC-FILE R(0) Salva nome.arq. SEND-INIT K, C, OR G(0) Resposta curta: ACK(0)/REPLY REC-SERVER-IDLE Resposta longa: INIT necessario SEND-INIT INIT desnecessario, N+ OPEN-FILE TIMEOUT Manda NAK(0) REC-SERVER-IDLE outro erro REC-SERVER-IDLE REC-INIT -- Entrada p/ comando RECEIVEde na~o-SERVER Po~e N e R em 0 S(0) Proces.parms, manda ACK c/parms, N+ REC-FILE TIMEOUT manda NAK(0),R+ REC-INIT outro NAK ABORT REC-FILE -- Busca mensagem de cabec,alho de arquivo ou de EOT F(N) Abre arq., ACK, N+ REC-DATA X(N) Prepara p/ mostrar na tela,ACK, N+ REC-DATA B(N) ACK COMPLETE S(N-1) ACK c/ parms, R+ REC-FILE Z(N-1) ACK, R+ REC-FILE TIMEOUT NAK, R+ REC-FILE outro NAK ABORT REC-DATA -- Recebe dados ate' final de arquivo D(N) Guarda dados,ACK,N+; se quer interrup- c,a~o, inclua X ou Z no ACK REC-DATA D(N-1) Manda ACK,R+ REC-DATA Z(N) Fecha arq.,ACK,N+ REC-FILE Z(N)/D Abandona arq,ACK,N+ REC-FILE F(N-1) Manda ACK,R+ REC-DATA X(N-1) Manda ACK,R+ REC-DATA TIMEOUT Manda ACK,R+ REC-DATA outro Manda E ABORT SEND-INIT -- Entrada p/ comando SEND tambe'm Po~e N e R em 0, Manda S(0) com para^metros Y(0) Processa parms,N+ OPEN-FILE N, TIMEOUT R+ SEND-INIT outro R+ SEND-INIT OPEN-FILE -- Abre arquivo ou prepara texto para enviar SEND-FILE SEND-FILE -- Manda cabec,alho ou arquivo de texto Manda F ou X(n) Y(N), N(N+1) Pega prim.buffer de dados,N+ SEND-DATA ou SEND-EOF se arq.vazio ou texto N, TIMEOUT R+ SEND-FILE outro ABORT SEND-DATA -- Manda conteu'do de arquivo ou informac,a~o textual Manda D(n) com buffer corrente Y(N), N(N+1) N+, Pega prox.buff SEND-DATA ou SEND-EOF se no fim do arq. ou texto Y(N)/X ou Z N+ SEND-EOF N, TIMEOUT R+ SEND-DATA outro ABORT SEND-EOF -- Manda indicador de fim de arquivo Manda Z(n); se interrompendo, manda Z(n)/D Y(N), N(N+1) Abre prox.arq.,N+ SEND-FILE se mais ou SEND-BREAK se acabou ou se interrupc,a~o "Z". N,TIMEOUT R+ SEND-EOF outro ABORT SEND-BREAK -- Fim de Transac,a~o (END OF TRANSACTION) Manda B(n) Y(N), N(0) COMPLETE N(N), TIMEOUT SEND-BREAK outro ABORT SEND-SERVER-INIT -- Entrada para comandos SERVER que esperam resposla longa. Manda I(0) com para^metros Y(0) Processa parms. SEND-GEN-CMD N, TIMEOUT R+ SEND-SERVER-INIT E Usa parms. default SEND-GEN-CMD outro ABORT SEND-GEN-CMD -- Entrada para comandos SERVER que esperam resposta curta (ACK) Manda G, R ou C(0) S(0) Processa parms, ACK c/parms, N+ REC-FILE X(1) Prepara p/ teclar no term., N+ REC-DATA Y(0) Tecla dados no tty COMPLETE N, TIMEOUT R+ SEND-GEN-CMD outro ABORT COMPLETE -- Transac,a~o completada com sucesso Arma N e R em 0 Se SERVER, restaura parms, REC-SERVER-IDLE sena~o EXIT ABORT -- Te'rmino prematuro de transac,a~o Restaura qualquer arquivo aberto, arma N e R em 0 Se SERVER, restaura para^metros, REC-SERVER-IDLE sena~o EXIT EXIT/LOGOUT --termina ou executa "LOGOUT" Note que os comandos gene'ricos determinam o pro'ximo estado da seguinte maneira: 1. Se o comando na~o for suportado, um pacote de erro e' transmitido e o pro'ximo estado e' ABORT. 2. Se o comando gera uma resposta que pode caber no campo de dados de um ACK, um ACK e' mandado com o texto (marcado como se fizer necessa'rio) no seu campo de dados. 3. Se o comando gera uma resposta grande ou tem que transmitir um arquivo, nada e' mandado do estado REC- SERVER-IDLE e o pro'ximo estado e' ou SEND-INIT (ou se na~o foi recebida mensagem I ou se deve ser usado um tipo de checagem de bloco alternativo) ou OPEN-FILE (se chegou uma mensagem I ou se deve usar a checagem de bloco de um u'nico caracter). 4. Se o comando e' LOGOUT, e' mandado um ACK e o novo estado e' LOGOUT. 5. Se o comando e' EXIT, e' mandado um ACK e o novo estado e' EXIT. .pa .heComandos KERMIT ..@adu 9. Comandos KERMIT ..@icomandos KERMIT ..@iKERMIT, comandos Sugerimos os comandos e termos KERMIT como na lista abaixo. Na~o e' intenc,a~o recomendar um estilo particular de ana'lise de comandos, somente promover um vocabula'rio consistente, tanto em documentac,a~o quanto na escolha dos nomes para os comandos. ..@bd 9.1. Comandos Ba'sicos ..@icomandos basicos ..@icomando, SEND ..@iSEND SEND Este verbo diz ao programa KERMIT para mandar um ou mais arquivos de sua pro'pria estrutura de arquivos. ..@iRECEIVE ..@icomando, RECEIVE RECEIVE Informa ao KERMIT para esperar um ou mais arquivos que devem chegar. ..@iGET ..@icomando, GET GET Diz a um USER KERMIT para pedir que o SERVER do outro lado da conexa~o mande um ou mais arquivos. Algumas implementac,o~es do KERMIT tem comandos separados de GET e RECEIVE; outros usam o RECEIVE para os dois propo'sitos, o que gera confusa~o. O fato de se poder especificar nomes diferentes para arquivos fonte e destino pode ser u'til e, a`s vezes, necessa'rio. Porisso esses comandos podem ter operandos opcionais [entre colchetes] como aparecem abaixo. ..@iSEND ..@icomando, SEND SEND nome-local-fonte [nome-remoto-destino] Se for inclui'da a especificac,a~o do arquivo em seu destino, ela ira' no pacote de cabec,alho de arquivo, em lugar do nome local. ..@iRECEIVE ..@icomando, RECEIVE RECEIVE [nome-local-de-destino] Se a especificac,a~o do arquivo em seu destino e' dada, o arquivo chegante sera' armazenado sob tal nome, ao inve's do que vier no pacote de cabec,alho de arquivo. ..@iGET ..@icomando, GET GET nome-fonte-remoto [nome-local-destino] Se o nome local for especificado, o arquivo chegante sera' armazenado sob tal nome, abandonando o nome que vier no pacote de cabec,alho de arquivo. Na~o se deve usar nomes alternados se um grupo de arqui vos estiver sendo transmitido ou recebido. ..@bd 9.2. Comandos de gere^ncia do programa ..@icomandos de gerencia do programa ..@iprograma, comandos de gerencia ..@igerencia, comandos de - do programa ..@iEXIT ..@icomando, EXIT EXIT Deixa o programa KERMIT, fazendo antes qualquer limpeza que seja necessa'ria -- desassociando pe rife'ricos, fechando arquivos etc. ..@iQUIT ..@icomando, QUIT QUIT Deixa o programa KERMIT, sem fazer antes qualquer arrumac,a~o, de maneira a permitir alguma posterior manipulac,a~o de arquivos e perife'ricos. ..@iPUSH ..@icomando, PUSH PUSH Preserva o atual ambiente KERMIT e entra no processador de comandos do sistema. ..@iTAKE ..@icomando, TAKE TAKE Le^ e executa comandos KERMIT a partir de um arquivo local. ..@iLOG ..@icomando, LOG LOG Especifica um arquivo de LOG para transac,o~es de transfere^ncia de arquivos ou para LOGGIN de sesso~es de terminal. ..@bd 9.3. Comandos de emulac,a~o de terminal. ..@icomandos de emulacao de terminal ..@iterminal, comandos de emulacao ..@iemulacao, comandos de - de terminal ..@iCONNECT ..@icomando, CONNECT CONNECT Este verbo, va'lido somente para um KERMIT local, significa entrar no modo emulac,a~o de terminal; cria a ilusa~o de ser um terminal do sistema remoto. Prove^ um "caracter de escape" para permitir que o usua'rio "volte" ao sistema local. O caracter de escape, quando teclado, pede um argumento de um u'nico caracter; sa~o sugeridos os seguintes: 0 (zero) transmite um NUL B transmite um BREAK C encerra a emulac,a~o P forc,a a entrada no processador de comandos do sistema Q encerra o logging (se estiver sendo feito) R reinicia (RESUME) o logging S mostra o status da conexa~o ? mostra os argumentos va'lidos para o caracter de escape (outro caracter de escape): transmite o pro'prio caracter de escape Os equivalentes minu'sculos devem ser aceitos. Se um argumento inva'lido for teclado, soar um bip. (veja, tambe'm, o comando SET.) ..@bd 9.4. Comandos em modo-usua'rio especiais ..@icomandos em modo-usuario especiais ..@imodo-usuario, comandos especiais Tais comandos somente sa~o usados por USERs em SERVERs. ..@icomando, BYE ..@iBYE BYE Este comando manda uma mensagem para o SERVER remoto para que ele se LOGOUT e, apo's o sucesso desta operac,a~o, termina o programa KERMIT local. ..@icomando, FINISH ..@iFINISH FINISH Forc,a o SERVER remoto a terminar sem encerrar seu JOB, deixando o KERMIT local em ni'vel de comando, permitindo que o usua'rio se reconecte ao JOB remoto. ..@bd 9.5. Comandos cujo objeto deve ser especificado ..@icomandos com objeto ..@icomando, com objetos Algumas implementac,o~es do KERMIT incluem diversos servic,os de gerenciamento de arquivos locais e comandos para invoca'-los. Por exemplo, uma implementac,a~o pode ter comandos que permitam que voce tenha listagens de direto'rio, apague arquivos, troque de discos e saiba quanto espac,o tem disponi'vel sem que, para isto, tenha que sair e reiniciar o programa. SERVERs remotos tambe'm podem prover tais servic,os. Um USER KERMIT pode ser capaz de distinguir entre comandos direcionados ao seu pro'prio sistema daqueles que devem ser repassados para o sistema remoto. Quando passi'vel de confusa~o, um comando pode ser prefixado por um dos "prefixos objeto": ..@iREMOTE ..@icomando, REMOTE REMOTE Pede que o SERVER remoto fac,a este servic,o. ..@iLOCAL ..@icomando, LOCAL LOCAL Faz o servic,o localmente. Se o "prefixo objeto" for omitido, o comando deve ser executado localmente. Os servic,os sa~o: ..@iLOGIN ..@icomando, LOGIN LOGIN Deve ser empregado no seu sentido de compartilhamento de tempo, para criar uma identificac,a~o ("JOB", "sessa~o", "acesso", "conta") no sistema. ..@iLOGOUT ..@icomando, LOGOUT LOGOUT Para terminar uma sessa~o iniciada com LOGIN. ..@iCOPY ..@icomando, COPY COPY faz uma co'pia do arquivo especificado com o nome dado. ..@iCWD ..@icomando, CWD CWD Muda o direto'rio de trabalho. Este e' feio mas verbos naturais como CONNECT e ATTACH sa~o muito imprecisos. CWD e' o comando padra~o para trans fere^ncia de arquivos na ARPANET para invocar esta func,a~o. ..@iDIRECTORY ..@icomando, DIRECTORY DIRECTORY Prove^ uma lista de nomes e possivelmente outros atributos dos arquivos no direto'rio de trabalho corrente ou especificado. ..@iDELETE ..@icomando, DELETE DELETE Apaga o(s) arquivo(s) especificado(s). ..@iERASE ..@icomando, ERASE ERASE Poderia ser um sino^nimo para DELETE. Na~o parece ser bom incluir UNDELETE ou UNERASE na lista padra~o: a maioria dos sistemas na~o suportam uma func,a~o como esta e na~o se deve brincar com as expectativas de um usua'rio... ..@iKERMIT ..@icomando, KERMIT KERMIT Manda um comando para o analisador de comandos do SERVER remoto. ..@iRENAME ..@icomando, RENAME RENAME Muda o nome do arquivo especificado. ..@iTYPE ..@icomando, TYPE TYPE Mostra o conteu'do do arquivo especificado na tela do usua'rio. ..@iSPACE ..@icomando, SPACE SPACE Informa quanto espac,o esta' usado e quanto esta' disponi'vel para armazenamento de arquivos no direto'rio corrente ou especificado. ..@iSUBMIT ..@icomando, SUBMIT SUBMIT Submete o arquivo especificado para processamento em batch. ..@iPRINT ..@icomando, PRINT PRINT Imprime o(s) arquivo(s) especificado(s) numa impressora. ..@iMOUNT ..@icomando, MOUNT MOUNT Pede a montagem de um disco, fita ou outro meio de armazenamento de massa removi'vel. ..@iWHO ..@icomando, WHO WHO Mostra quem esta' "logado" (num sistema de timesharing) ou da' informac,o~es a respeito de um determinado usua'rio ou host (numa rede de computadores). ..@iMAIL ..@icomando, MAIL MAIL Manda uma corresponde^ncia eletro^nica para determinado(s) usua'rio(s). ..@iMESSAGE ..@icomando, MESSAGE MESSAGE Manda uma mensagem de terminal (numa rede ou sistema de timesharing). ..@iHELP ..@icomando, HELP HELP Da' breves informac,o~es sobre como usar o KERMIT. ..@iSET ..@icomando, SET SET Prepara va'rios para^metros relacionados com depurac,a~o, transmissa~o, modo de arquivo etc. ..@iSHOW ..@icomando, SHOW SHOW Mostra como os para^metros esta~o preparados, potencialidades etc. ..@iSTATISTICS ..@icomando, STATISTICS STATISTICS Da' informac,o~es acerca da performance da transfere^ncia de arquivos mais recente -- tempo decorrido, baud rate efetivo, diversos contadores etc. ..@iHOST ..@icomando, HOST HOST Repassa a cadeia de caracteres (de comando) dada para o host (local ou remoto) especificado para execuc,a~o em sua pro'pria linguagem de comandos. ..@iLOGGING ..@icomando, LOGGING LOGGING Abre ou fecha um LOG remoto de transac,a~o ou de depurac,a~o. .cp 4 ..@bd 9.6. O comando SET ..@icomando, SET ..@iSET Deve ser provido um comando SET para que o usua'rio possa adaptar uma conexa~o a`s particularidades do caminho da comunicac,a~o, ao sistema de arquivos local ou remoto etc. Aqui esta~o alguns para^metros passi'veis de alterac,a~o atrave's de um comando SET: ..@iBLOCK-CHECK BLOCK-CHECK Especifica o tipo de checagem de bloco a ser utilizada: checksum de um u'nico caracter, de dois ou CRC de 3 caracteres. ..@iDEBUGGING DEBUGGING Mostra ou "LOGa" o tra'fego e nu'meros dos pacotes e os estados em que entra o programa. Muito u'til para depurar novas verso~es de KERMIT, combinac,o~es ine'ditas de KERMITs etc. ..@iDELAY DELAY Quantos segundos um KERMIT remoto (na~o SERVER) deve esperar antes de mandar o pacote SEND-INIT, para dar tempo ao usua'rio para "escapar" de volta ao KERMIT local e teclar um comando RECEIVE. ..@iDUPLEX DUPLEX Para emulac,a~o de terminal, especifica full duplex (eco remoto) ou half duplex (eco local). ..@iEIGHT-BIT-PREFIXING EIGHT-BIT-PREFIXING Ativa a prefixac,a~o de oitavo bit. ..@iEND-OF-LINE ..@iEOL END-OF-LINE Especifica qualquer terminador de linha que deva ser empregado depois de um pacote. ..@iESCAPE ESCAPE Informa qual caracter de escape deve ser usado numa emulac,a~o de terminal. ..@iarquivo, atributo ..@iatributos de arquivos ..@iFILES ATTRIBUTES FILE ATTRIBUTES Quase todos os atributos listados antes (sec,a~o 8.5). A necessidade mais comum e' a de dizer ao KERMIT se o arquivo a ser transmitido ou recebido e' texto ou bina'rio. ..@iFLOW-CONTROL ..@iXON/XOFF ..@iDTR/CTS ..@ifcontrole de fluxo ..@ifluxo, controle de FLOW-CONTROL Especifica o mecanismo de controle de fluxo para a linha, como XON/XOFF, DTR/CTS etc. Permite acionar ou retirar controle de fluxo, que e' feito somente em conexo~es full duplex. ..@iHANDSHAHE HANDSHAKE Especifica qualquer negociac,a~o de acesso a` linha que deva ser empregada ou simulada durante uma transfere^ncia de arquivo. Por exemplo, um sistema half duplex frequentemente precisa "virar a linha" depois de mandar um pacote, de forma a lhe dar permissa~o para responder. Um handshake comum e' XON (^Q); o usua'rio corrente da linha transmite um XON quando termina de transmitir seus dados ..@iLINE LINE Especifica a linha ou designador de dispositivo para a conexa~o. Para emprego em um programa KERMIT que possa rodar tanto em modo local quanto remoto; a linha default e' o terminal de controle (para operac,a~o remota). Se um dispositivo externo e' usado, presume-se operac,a~o local. ..@iLOG LOG Informa o arquivo local onde guardar um LOG da transac,a~o. Podem existir LOGs para depurac,a~o (tra'fego de pacotes, transic,o~es de estado etc) e para propo'sitos de auditoria (registrar nome e disposic,a~o de cada transfere^ncia de arquivo). ..@iMARKER MARKER Muda o marcador de ini'cio de pacote, do seu default SOH (^A) para algum outro caracter de controle, no caso de um (ou ambos) os sistemas ter problema em usar SOH para tal propo'sito. ..@iPACKET-LENGTH ..@ipacote, comprimento do ..@icomprimento do pacote PACKET-LENGTH O maior comprimento de um pacote. Normalmente na~o deve ser menor que 30 ou 40 e nunca maior que 96. Pacotes curtos podem ser uma vantagem em linhas com muito rui'do; eles reduzem a probabilidade de um pacote ser corrompido, bem como o overhead de retransmisso~es quando acontece o erro. ..@iPADDING ..@ipreenchimento PADDING O nu'mero de caracteres de preenchimento que devem ser transmitidos antes de cada pacote e qual deve ser tal caracter. Raramente necessa'rio. ..@iPARITY ..@iparidade PARITY Especifica a paridade (ODD, EVEN, MARK, SPACE, NONE) na conexa~o fi'sica. Se diferente de NONE, o oitavo bit na~o pode ser usado para transmitir dados e na~o pode ser usado por qualquer dos dos lados no ca'lculo de checagem de bloco. ..@iPAUSE PAUSE Quantos segundos pausar depois de receber um pacote e antes de mandar o pro'ximo. Normalmente 0 mas quando um processador de comunicac,a~o de um sistema (front end) esta' com problemas de tra'fego, uma pequena pausa entre pacotes pode ajudar; grac,as aos ce'us algo abaixo de 1 segundo e' suficiente. ..@iPREFIX .cp 2 PREFIX Muda o prefixo default para caracteres de controle, caracteres de 8 bits ou quantidades repetidas. ..@iPROMPT PROMPT Troca o prompt do programa. E' u'til ao rodar KERMIT entre dois sistemas com o mesmo prompt, eliminando a confusa~o acerca de qual dos KERMITs esta' falando com voce. ..@iREPEAT-COUNT-PROCESSING ..@icontador de repeticoes REPEAT-COUNT-PROCESSING Muda o default para o processamento do contador de repetic,o~es. Normalmente sera' feito se ambos os KERMITs concordarem com isto. ..@iRETRY ..@iretransmissoes ..@ilimite de retransmissoes RETRY Nu'mero ma'ximo de tentativas em mandar ou receber um pacote antes de desistir. O nu'mero normal e' em torno de 5 mas o usua'rio deve estar capacitado a ajusta'-lo de acordo com as condic,o~es da linha, a carga nos sistemas etc. ..@iTIMEOUT TIMEOUT Especifica a quantidade de tempo a ser dada para uma espera por um pacote. ..@bd 9.7. Macros (o comando DEFINE) ..@iDEFINE ..@imacros ..@icomando, DEFINE Ale'm dos comandos SET individuais, uma facilidade de "macro comandos" e' recomendada, para permitir que os usua'rios combinem as caracteri'sticas de determinados sistemas em um u'nico comando SET. Por exemplo: ..@iUNIX ..@iIBM ..@iexemplo ..@iparidade ..@iTELENET ..@ihandshake ..@iDUPLEX ..@iFULL ..@iHALF ..@iMARK DEFINE IBM = PARITY ODD, DUPLEX HALF, HANDSHAKE XON DEFINE UNIX = PARITY NONE, DUPLEX FULL DEFINE TELENET = PARITY MARK Isto pode ser feito provendo-se um analisador caprichado para comandos como este (que podem utilizar o pro'prio arquivo de inicializac,a~o do KERMIT USER durante a inicializac,a~o do programa) ou simplesmente escrito dentro da tabela do comando SET, no fonte do KERMIT. Feitas estas definic,o~es, o usua'rio simplesmente teclaria "SET UNIX" ou qualquer outra coisa, que prepararia todo o programa, de uma so' vez, para se comunicar com o sistema remoto. .pa .heEmulac,a~o de Terminal ..@adu 10. Emulac,a~o de terminal ..@iterminal ..@iterminal, emulacao O sistema local tem que ser capaz de agir como um terminal, de modo a permitir que o usua'rio se conecte ao sistema remoto, identifique-se la' e inicie o KERMIT remoto. Qualquer programa KERMIT que rode localmente deve prover emulac,a~o de terminal, para que o usua'rio na~o tenha que ficar trocando de programas de forma a transferir arquivos e operar protocolo de terminal. Nos sistemas menores isto e' particularmente importante por va'rias razo~es (reiniciar o programa e reentrar todos os comandos SET necessa'rios e' muito inconveniente e desperdic,a muito tempo; em alguns micros, entrar e sair de emulac,a~o de terminal pode fazer a portadora cair etc.). O KERMIT so' precisa suprir uma emulac,a~o de teminal bem simples, pe'-de-boi. Na~o ha' a necessidade de simular qualquer terminal particularmente "esperto". Uma simulac,a~o de qualquer terminal "burro" e' suficiente para fazer o servic,o. E' bom ter uma emulac,a~o mais caprichada, no entanto, para se tirar vantagem das capacidades de visualizac,a~o e edic,a~o do sistema remoto. Em alguns casos o firmware do microcomputador cuidara' disto. Para construir uma emulac,a~o de um tipo especial de terminal no programa, voce deve interpretar e agir sobre as seque^ncias de ESCAPE conforme elas forem chegando na porta. Durante a emulac,a~o de terminal na~o e' feita checagem de erros. Esta' "fora do protocolo"; os caracteres va~o e ve^m "nus". Sob este ponto de vista, emular um terminal atrave's do KERMIT na~o e' melhor que usar, realmente, um terminal real. Algumas implementac,o~es de KERMIT podem permitir logar a emulac,a~o de terminal em um arquivo local. Tal facilidade ajuda a "capturar" arquivos teclados remotamente, (lembre-se: sem correc,a~o ou checagem de erros). Quando existe tal facili dade, e' deseja'vel ter uma forma conveniente de ligar e desligar a gravac,a~o do LOG. Se o sistema local na~o prove^ controle de fluxo a ni'vel de sistema (ou de firmware), como XON/XOFF, o programa de emulac,a~o de terminal deve tentar simula'-lo, especialmente se estiver sendo feito LOG. A facilidade de emulac,a~o de terminal deve ser capaz de lidar tanto com eco local quanto remoto (full ou half duplex), qualquer handshake exigido, bem como transmitir qualquer paridade exigida pelo lado remoto ou meio de comunicac,a~o. Os emuladores de terminal funcionam amostrando conti nuamente tanto inputs da console do terminal local quanto da linha de comunicac,a~o. As func,o~es simples de input e output na~o sera~o suficientes, entretanto, ja' que se voce pede input de um determinado dispositivo na~o houver a disponibilidade, geralmente voce vai bloquear ate' que haja, realmente, um input e durante este tempo estara' perdendo inputs do outro dispositivo. Assim voce tem que ter uma maneira de "olhar" para um lado e para o outro, independentemente de haver ou na~o um input disponi'vel. Diversos mecanismos sa~o comunmente usados: * "Pular" para frente e para tra's, continuamente, entre o registrador de status da porta e da console, checando os bits de status em busca de input disponi'vel. Isto so' e' pra'tico em sistemas mono-usua'rio, mono-processo, onde a CPU na~o tem mais nada a fazer. * Emitir um pedido de input blocado normal para a porta mas habilitando interrupc,a~o por input da console ou vice-versa. * Manusear o input da porta em um processo e da console em outro, paralelamente. O programa KERMIT para UNIX listado neste manual emprega este me'todo. Qualquer input da porta deve ser mostrado, imediatamente, na tela. Qualquer input da console deve ser, em seguida, transmitido porta a fora. Adicionalmente, se a conexa~o for half duplex, o input da console deve ser mostrado na tela, tambe'm. O co'digo de emulac,a~o de terminal deve examinar cada caracter da console para determinar se e' o "caracter de escape". Se for, deve tomar o pro'ximo como um comando especial, que, enta~o, executa. Estes comandos foram descritos anteriormente, na sec,a~o 9.3. O emulador de terminal deve ser capaz de transmitir todos os caracteres ASCII, do NUL ao DEL, e ser capaz tambe'm de transmitir um sinal BREAK (na~o e' um caracter mas um "escape" de uma transmissa~o ASCII na qual um 0 e' colocado na linha durante cerca de 1/4 de segundo, a despeito do baud rate, sem bits de framing). O BREAK e' importante ao se comunicar com va'rios sistemas, como mainframes da IBM. Finalmente, a`s vezes, e' necessa'rio executar certas transformac,o~es no caracter CR que normalmente e' teclado para terminar uma linha de input. Alguns sistemas usam LF, EOT ou outro caracter para esta func,a~o. Para complicar, alguns equipamentos de comunicac,a~o intervenientes (particularmente redes de comutac,a~o de pacotes publicas) podem ter seus pro'prios requisitos independentes. Assim, ao se usar o KERMIT para se comunicar atrave's, digamos, da TRANSPAC, com um sistema que emprega LF para fim-de-linha, pode ser necessa'ria a transformac,a~o do CR em LFCR (LF antes -- o CR comanda a rede para transmitir o pacote, que contera' o LF e o host usa o LF para terminac,a~o). O usua'rio deve ser provido de um mecanismo para especificar esta transformac,a~o, um comando como "SET CR seque^ncia". .pa .heEscrevendo um programa KERMIT ..@adu 11. Escrevendo um programa KERMIT ..@iKERMIT, escrevendo um ..@iprograma, escrevendo um KERMIT Antes de escrever uma nova implementac,a~o de KERMIT ou modificar uma existente, entre em contato com o Centro de Distribuic,a~o do KERMIT, na Universidade de Colu'mbia, para se assegurar que voce na~o estara' duplicando o esforc,o de outra pessoa e de que tera' todo o material mais atualizado para trabalhar. Caso voce realmente escreva ou modifique significantemente (ou documente) um programa KERMIT, por favor: mande-o de volta para o C.U.C.C.A., onde sera' inclui'do na distribuic,a~o padra~o do KERMIT e outros podera~o ser beneficiados. E' somente atrave's desta forma de compartilhamento que o KERMIT cresceu de seu modesto ini'cio para a escala atual. As sec,o~es a seguir prove^em algumas "dicas" de programac,a~o KERMIT. ..@bd 11.1. Organizac,a~o do programa ..@iprograma, organizacao ..@iorganizacao do programa Uma implementac,a~o ba'sica de KERMIT pode usualmente ser escrita como sendo um programa relativamente pequeno, auto- contido num u'nico fonte. Entretanto e' normal o caso de um programa que foi escrito para rodar em um sistema, ser adaptado para rodar em outros sistemas tambe'm. Neste caso e' melhor evitar ter fontes totalmente divergentes, porque quando novas facilidades sa~o acrescentadas (ou problemas corrigidos) em partes do programa independentes de sistema (i. e': no protocolo em si), somente uma implementac,a~o colhera' os benefi'cios inicialmente, enquanto que as outras exigira~o ajustes dolorosos, propensos a erro(s) ate' que sejam levadas ao mesmo ni'vel. Assim, se houver alguma chance de um programa KERMIT vir a rodar em mais de um tipo de ma'quina ou sistema operacional ou, ainda, suportar mais de um tipo de porta ou modem etc., e' deseja'vel isolar as partes dependentes de sistema de uma forma a deixar as partes comuns utiliza'veis pelas va'rias implementac,o~es. Existem diversos enfoques: 1. Suporte em tempo de execuc,a~o. Se possi'vel, o programa pode inspecionar o hardware ou pedir para^metros relevantes sobre o sistema e se configurar dinamicamente em tempo de inicializac,a~o. E' a forma mais difi'cil de implementar. 2. Compilac,a~o (montagem) condicional. Se o nu'mero de sistemas ou opc,o~es a serem suportados for pequeno, a parte do co'digo dependente de sistema pode ser inclui'do em rotinas compiladas condicionalmente (como IF IBMPC ... ENDIF). Como exemplo, veja a listagem de um KERMIT para UNIX fornecida com este manual. No entanto, conforme o nu'mero de depende^ncias de sistema a serem suportadas cresce, este me'todo tende a se tornar canhestro e passi'vel de erros (instalar suporte para o sistema X pode tornar inva'lido o suporte para o sistema Y). 3. Composic,a~o modular. Quando existir a potenciali dade de um grande nu'mero de opc,o~es vir a ser suportadas, o programa deve ser quebrado em mo'dulos separados, com convenc,o~es de chamada simples e claramente especificadas. Isto permite que pessoas com novas opc,o~es de^em seu pro'prio suporte a elas de forma fa'cil, sem perigo de causar mal ao suporte existente. Os mo'dulos sugeridos para um programa KERMIT sa~o: - manuseio de protocolo independente de sistema: troca de estado, formac,a~o de pacotes, codificac,a~o (prefixac,a~o), deco dificac,a~o etc. - interface com o usua'rio: o analisador de comandos; sendo um mo'dulo separado, permite inclusa~o de analisadores de comando de acordo com o gosto do usua' rio, mimetizando o estilo do analisador de comandos do host ou de algum aplica tivo popular etc. - manuseio da tela: este mo'dulo conteria os co'digos de controle de tela, rotinas de posicionamento do cursor etc. - manuseio da porta: permite o suporte de va'rios hardwares de porta; este mo'dulo pode definir a localizac,a~o do registra dor de status da porta, o significado de seus bits e dai' em diante e pode imple mentar as func,o~es de receber e transmitir caracteres pela porta - controle de modem: deve suportar qualquer tipo de modem "inteligente", que na~o seja meramente uma extensa~o transparente da porta de comunicac,a~o; tais modems podem aceitar comandos especiais para executar func,o~es como discar, rediscar o u'ltimo nu'mero, desligar etc. e podem carecer de inicializac,a~o especial (forc,ar sinais como DTR, p.e.) - input de console: este mo'dulo deve suprir a func,a~o de pegar um caracter da console; ele saberia as localizac,o~es dos registradores de status e o significado de seus bits, estrutura de interrupc,a~o, conversa~o tecla-caracter etc., implementar redefinic,o~es de teclas, macros de teclado, func,o~es programa'veis, controles expandidos, meta-func,o~es etc. - emulac,a~o de terminal: este mo'dulo deve interpretar seque^ncias de escape no fluxo de caracteres que chegam (obtido do mo'dulo de I/O da porta) para o tipo particular de terminal sendo emulado e interpreta'-lo fazendo os "call's" apropriados ao mo'dulo de I/O de tela e mandaria o que o usua'rio teclasse (obtido do mo'dulo de entrada por console) pela porta serial (novamente usando o mo'dulo de I/O de porta); a ide'ia e' poder trocar este mo'dulo por outros, de forma a emular diferentes tipos de terminais (ANSI, VT52, ADM3A etc.) - I/O de arquivos: conte'm todo o conheci mento a respeito da estrutura de sistema de arquivamento de host; como abrir e fechar arquivos, operac,o~es de "pegar o pro'ximo arquivo", ler, gravar, determi nar e alterar seus atributos, detectar o fim de um arquivo etc.; prove^ tambe'm as func,o~es (incluindo a de bufferizac,a~o) de ler um caracter de um arquivo e grava'- lo em outro; este mo'dulo tambe'm pode prover servic,os de gerenciamento de arquivos em termos locais (listagens de direto'rio, apagar, renomear, copiar etc.) - definic,o~es e dados: mo'dulos separados podem ser tambe'm guardados para definic,o~es de para^matros para tempo de compilac,a~o e para dados globais para tempo de execuc,a~o. .pa ..@bd 11.2. Linguagem de programac,a~o ..@iprogramacao, linguagem ..@ilinguagem de programacao A linguagem a ser usada para se escrever um programa KERMIT e' qualquer coisa mais do que mera questa~o de gosto. A considerac,a~o prima'ria e' que a linguagem escolhida deve dar a funcionalidade e velocidade necessa'rias. Por exemplo, uma implementac,a~o do BASIC em um microcomputador pode na~o permitir o tipo de acesso em baixo ni'vel aos registradores dos dispositivos necessa'rio em uma emulac,a~o de terminal ou para detetar input da console durante uma transfere^ncia de arquivo ou, mesmo, se pode fazer essas coisas, pode na~o ser capaz de rodar ra'pido o suficiente para manter a linha de comunicac,a~o na baud rate desejada. A segunda considerac,a~o em escolher a linguagem e' sua portabilidade. Pode ser encarada de duas maneiras: 1) se a linguagem e' de domi'nio pu'blico (ou, equivalentemente, distribui'da sem o^nus como parte de um sistema ba'sico) e 2) se e' bem padronizada e de uso difundido em va'rios sistemas. Uma linguagem porta'vel nesses dois sentidos deve ter prefere^ncia. Qualquer que seja a linguagem escolhida, e' importante que todas as linhas do programa fonte na~o excedam 80 carac teres (depois da expansa~o dos TABs). Isto porque material KERMIT frequentemente precisa ser transportado por RJE e outros links de comunicac,a~o que obedecem o formato "carta~o". E, finalmente, e' importante que os nomes de todos os arquivos usados na criac,a~o e suporte de uma determinada implementac,a~o do KERMIT seja (possivelmente um subset) da forma NOME.TIPO, onde NOME esta' limitado a 6 caracteres e TIPO a 3; onde o nome de cada arquivo comece com um prefixo comum de 2 ou 3 caracteres. Isto e' assim para que todos os arquivos relacionados ficara~o agrupados numa listagem alfabe'tica de direto'rio e tambe'm, quando todas as centenas de arquivos relacionados com o KERMIT fiquem colocados juntos em uma fita, todos os nomes sera~o tanto legais quanto u'nicos, especialmente em sistemas (como o do PDP-11) com convenc,o~es restritivas de batismo de arquivos. ..@bd 11.3. Documentac,a~o ..@idocumentacao Um programa KERMIT novo deve ser pesadamente documentado. Um dos pontos altos do KERMIT e' sua documentac,a~o. Deve ser tanto a ni'vel de usua'rio (como usar o programa, quais comandos existem e porque etc., similarmente a` documentac,a~o presentemente encontrada no "Guia do Usua'rio"), quanto a ni'vel de implementac,a~o (descrevendo depende^ncias do sistema, pontos para possi'vel adaptac,a~o para outros sistemas etc.). Ale'm disso, os pro'prios programas devem conter, copiosamente, comenta'rios. Como o programa fonte, a documentac,a~o deve ser mantida no limite dos 80 caracteres por linha. Se possi'vel, uma sec,a~o para a implementac,a~o deve ser escrita para ser anexada ao Guia do Usua'rio usando-se a linguagem de formatac,a~o do SCRIBE, da Unilogic (subsets do qual podem ser encontrados em alguns softwares de processamento de texto para microcomputadores, como Perfect Writer, ou Final Word), usando a mesma convenc,a~o geral das sec,o~es de implementac,a~o do EXISTIC, formato Scribe. Programas KERMIT tambe'm devem conter um histo'rico das reviso~es, onde cada alterac,a~o e' explicada sucintamente, associada a um "nu'mero de edic,a~o", programador responsa'vel e lugar e/ou data. As linhas ou sec,o~es editadas devem ser marcadas com o nu'mero de edic,a~o correspondente e o programa KERMIT, ao se iniciar, deve anunciar sua versa~o e nu'mero de edic,a~o, de forma que um usua'rio, ao perceber um defeito, possa se referir a essas informac,o~es. O nu'mero da versa~o muda quando a funcionalidade mudou suficientemente para requerer maiores reviso~es na documentac,a~o. O nu'mero de edic,a~o deve crescer (monotonicamente, na~o relacionado com o nu'mero da versa~o) sempre que uma alterac~ao for feita no programa. Os nu'meros de edic,a~o sa~o muito importantes para a gere^ncia do fonte; depois de mandar para algue'm uma versa~o do, digamos, CP/M KERMIT-80, costumamos receber muitas co'pias dele de volta, cada uma contendo seu pro'prio conjunto de mudanc,as, que precisamos reconciliar de alguma maneira. O uso dos nu'meros de edic,a~o auxiliam muito esta tarefa. ..@bd 11.4. Bootstrapping ..@ibootstrapping Finalmente, deve ser dado um procedimento de bootstrap. O KERMIT geralmente e' distribui'do em fita magne'tica para grandes instalac,o~es; os usua'rios precisam de maneiras de "baixar" as va'rias implementac,o~es para seus micros e outros sistemas locais. Um procedimento simples de bootstrap consistiria de instruc,o~es precisas de como conseguir um co'pia "sem garantia" do programa. Talvez um simples, pequeno programa possa ser escrito para cada ponta que fac,a o servic,o; listagens e instruc,o~es podem ser dadas para que o usua'rio digite e rode tais programas. .pa .heFormato e Tipos dos Pacotes ..@x ..@adu A. Formato e Tipos dos Pacotes ..@ipacote, formato ..@iformato dos pacotes ..@ilayout dos pacotes Layout de um pacote KERMIT: +------+-----+-----+------+------+-------+ | mark | len | seq | type | data | check | +------+-----+-----+------+------+-------+ Layout do campo de dados do pacote SEND-INIT: +------+------+------+------+-----+------+ | maxl | time | npad | padc | eol | qctl | ... +------+------+------+------+-----+------+ +------+------+------+-------+ ... | qbin | chkt | rept | capas | +------+------+------+-------+ Tipos e subtipos de pacotes KERMIT (* = exigido): ..@ipacote, tipos Y* ACK (aceito) N* NAK (na~o aceito) S* SEND-INIT (troca de para^metros) I INIT (troca de para^metros) F* cabec,alho de arquivo A atributos de arquivo D* dados Z* EOF (fim de arquivo) B* EOT (interrupc,a~o da transmissa~o) E* erro R REC-INIT (pede arquivos especificados ao SERVER) C comando para o host K comando para o KERMIT T reservado para uso interno G comando KERMIT gene'rico; subcomandos: I LOGIN/LOGOUT C CWD (troca de direto'rio corrente) L BYE F FINISH D DIRECTORY U pergunta sobre uso de disco E ERASE/DELETE T TYPE R RENAME K COPY W WHO? (quem esta' "logado"?) M mensagem curta H HELP Q pergunta status do SERVER P invoca programa J controle de jornalizac,a~o V varia'veis (inquire, arma) .pa .heRelac,a~o das Facilidades ..@adu B. Relac,a~o das Facilidades ..@irelacao das facilidades ..@ifacilidades, relacao das Na~o existe uma escala linear verdadeira ao longo da qual se mec,a uma implementac,a~o de KERMIT. Uma implementac,a~o ba'sica, mi'nima, prove^ transfere^ncia de arquivos em ambas as direc,o~es e, para microcomputadores (PC's, workstations, outros sistemas mono-usua'rio), emulac,a~o de terminal. Mesmo dentro desta estrutura podem haver variac,o~es. Por exemplo: pode o programa mandar um grupo de arquivos em um u'nico programa ou deve emitir um comando para cada arquivo? Aqui esta' uma lista de facilidades que podem ser apresentadas; para qualquer implementac,a~o de KERMIT a documentac,a~o deve mostrar se a facilidade existe e como invoca'-la. - Grupos de arquivos. Pode mandar um grupo de arquivos com um u'nico comando, usando "wildcard" ("coringa"), modelo ou notac,a~o de lista? Pode, com sucesso, transmi tir ou receber um grupo de arquivos de tipos diferen tes? Pode recuperar-se de um erro em um arquivo em particular e continuar com o pro'ximo? Pode manter um LOG dos arquivos envolvidos, mostrando o arranjo de cada um? - Nomes de arquivos. Ele consegue evitar destruir um arquivo local quando chega um novo arquivo com o mesmo nome? Pode converter nomes de arquivo para/de forma "legal" ou "normal"? - Tipos de arquivos. Arquivos bina'rios sa~o ta~o bem transmitidos quanto os arquivos de texto? - Prefixac,a~o de oitavo bit. Ele pode mandar e receber dados de 8 bits por um canal de 7 bits usando o mecanismo de prefixac,a~o? - Processamento do contador de repetic,o~es. Consegue transmitir e receber dados com caracteres repetidos substitui'dos por uma seque^ncia prefixada? - Emulac,a~o de terminal. Tem ele facilidade de emulac,a~o de terminal? Prove^ va'rias opc,o~es de comunicac,a~o, como selec,a~o de duplex, paridade e handshake? Pode transmi tir todos os caracteres ASCII? Transmite um BREAK? Consegue "logar" uma sessa~o remota localmente, para prover captura de arquivo sem teste de eventuais erros? - Opc,o~es de checagem de bloco. Ale'm do checksum ba'sico de um u'nico caracter, pode ser selecionado um CRC de 2 ou 3 caracteres? - SERVER ba'sico. Pode rodar em modo SERVER, aceitando comandos para mandar ou receber arquivos ou terminar a si pro'prio? - SERVER avanc,ado. Aceita comandos SERVER para apagar arquivos, dar listagens de direto'rio, mandar mensagens etc.? - Mandar comandos para um SERVER. Consegue mandar mensa gens para um SERVER e manusear todas as possi'veis respostas? - Comandos de host. E' capaz de analisar e transmitir comandos para um host remoto? Se e' um SERVER, consegue passar tais comandos para o processador de comandos do host e devolver os resultados para o KERMIT usua'rio local? - Interromper transfere^ncias de arquivos. Pode ele inter romper uma transmissa~o ou recepc,a~o de um arquivo? Consegue responder a pedidos de interrupc,a~o vindos do outro lado? - Servic,os de gerenciamento de arquivos locais. Existem comandos para dar listagens do direto'rio local, apagar arquivos locais etc.? - Atributos de arquivos. Ele consegue transmitir informa c,o~es sobre atributos de arquivos locais e lidar com informac,o~es deste tipo que porventura cheguem? Disposi c,o~es alternativas podem ser alteradas? Arquivos podem ser armazenados? - Capacidade de depurac,a~o. O tra'fego de pacotes pode ser "logado", examinado, refeito passo-a-passo? .pa .heProblemas na~o resolvidos ..@adu C. Problemas na~o resolvidos ..@iproblemas nao resolvidos O KERMIT na~o faz tudo. Esta' aqui uma relac,a~o das coisas que ele na~o faz ou poderia fazer melhor. - O KERMIT na~o pode ser utilizado atrave's de emuladores do protocolo IBM 3270. Sa~o equipamentos que possibilitam terminais ASCII assi'ncronos ou PCs comunicarem-se com mainframes IBM como se fossem terminais si'ncronos de tela completa. Os problemas incluem: a) o conversor de protocolo traduz de EBCDIC para ASCII (isto e': assume que esta' recebendo EBCDIC quando se espera que o KERMIT esteja transmitindo em ASCII) de acordo com uma tabela interna pro'pria, que pode variar de instalac,a~o para instalac,a~o e nunca e' um mapeamento biuni'voco; b) caracteres de controle na~o imprimi'veis, como SOH, na~o podem ser transmitidos, de forma alguma; c) o conversor de protocolos busca comandos de formatac,a~o 3270 e os traduz para seque^ncias ESC para o terminal ASCII, possi'velmente modificando o pacote de dados; d) o sistema IBM automaticamente pausa no final de cada pa'gina cheia; e) o conversor de protocolos pensa que sabe o que esta' "na tela" e pode tentar otimizar; geralmente na~o se sabe exatamente como um conversor de protocolos vai agir ou quanto pode diferir de um outro; apesar disto, pode ser possi'vel contornar esses problemas se os KERMITs nas duas pontas sejam colocados num "modo especial 3270", "limparem a tela" entre dois pacotes e concordarem com alguma convenc,a~o especial para delimitar pacote e traduzir dados. - Prefixac,a~o de caracteres de controle. Isto pode vir a ficar bem caro para arquivos bina'rios ou outros arqui vos cheios de caracteres de controle. Pode ser uma boa ide'ia fazer com que cada host informe quais os carac teres que consegue receber sem prefixac,a~o. Por outro lado, o tiro pode sair pela culatra, quando os dois hosts esta~o ligados atrave's de uma rede ou equipamento que filtra caracteres de controle mesmo que nenhum dos dois hosts os filtre. Em conexo~es diretas, sem fatores desconhecidos, no entanto, muitos caracteres de con trole podem ser transmitidos sem prefixac,a~o. - Quando esta~o sendo transmitidas longas seque^ncias de caracteres dentro da faixa de controle, a prefixac,a~o individual de cada caracter fica onerosa. Co'digos "entra/sai" podem ser aqui empregados mais efetivamente. Idem para longas cadeias com o oitavo bit ligado, quando se faria prefixac,a~o de oitavo bit. O custo seria mais um conjunto de caracteres de prefixac,a~o e a complexidade associada a` formac,a~o e decodificac,a~o dos pacotes. - Em algumas situac,o~es, certos caracteres impri'veis na~o conseguem passar pelo link de comunicac,a~o. Por exemplo: um SERVER terminal de uma rede pode reservar "@" como seu caracter de "atenc,a~o". Deve o protocolo permitir uma forma de codificar tais caracteres para traduc,a~o? Um conjunto de seque^ncias ESC defini'vel pelo usua'rio poderia ser u'til neste caso. - Ironicamente, alguns sistemas na~o se da~o bem com os pequenos tamanhos dos pacotes KERMIT. Sa~o, tipicamente, os grandes sistemas que esperam se comunicar com termi nais em modo "bloco", recebendo milhares de caracteres de uma vez. Tais sistemas acham o KERMIT simplesmente muito caros de rodar. Enquanto isso, outros sistemas que podem rodar KERMIT sem dificuldade, acham sua per formance desapontadora (a eficie^ncia geralmente da' um jeito em cerca de 50 a 80 porcento, isto e': caracteres de dados dividido pela velocidade de transmissa~o da linha, em caracteres por segundo). Estes dois problemas podem ser resolvidos de duas maneiras: permitir a transmissa~o de pacotes mais longos ou de pacotes de dados mu'ltiplos ponto-a-ponto. * Sem mudar o formato ou a codificac,a~o dos campos dos pacotes de controle, pode ser possi'vel ter pacotes mais longos, reservando-se os comprimentos de 0, 1, 2 e 3 como co'digos para nu'meros maiores como 200, 500, 1000, 2000. No entanto, quanto maior for o pacote, maior a probabilidade de ser corrompido e maior a retransmissa~o, se houver NAK. Ale'm disto, a adequac,a~o da checagem de bloco de um caracter seria muito reduzida para pacotes longos, que deveriam, por conseguinte, ser transmitidos com checagem dos tipos 2 ou 3. * Seria possi'vel extender o protocolo para permitir transmissa~o de pacotes de dados enquanto ainda estiverem pendentes ACKs e qualquer ACK poderia valer para o pacote especi'fico ou para todos os precedentes. Um limite para o nu'mero de ACKs pendentes poderia ser combinado; o tamanho ma'ximo de tal "janela varia'vel" teria que ser menor que 64, que e' o ponto onde o nu'mero de um pacote volta a zero e a janela na~o poderia se extender ale'm de 63 sob pena do KERMIT perder a noc,a~o de quantas vezes 64 pacotes foram transmitidos. Uma janela varia'vel de 8 e um tamanho de pacote de 95 teria o mesmo efeito que pacotes de 700 caracteres. Um NAK poderia exigir que o transmissor repetisse tudo desde o pacote que recebeu o NAK. Uma futura edic,a~o deste manual podera' incluir uma especificac,a~o para estas janelas. .pa .heUm programa KERMIT ..@adu D. Um programa KERMIT ..@iprograma, fonte KERMIT em C ..@ifonte de um KERMIT ..@iKERMIT, fonte em C O que temos a seguir e' uma listagem de uma versa~o real de KERMIT, escrita na linguagem C (Kernighan & Ritchie, The C Programming Language, Prentice Hall, 1978). Foi desenhada para rodar sob diversas verso~es do sistema operacional UNIX. A funcionalidade ba'sica do KERMIT esta' presente mas muito pouco das facilidades opcionais. Somente o analisador de comandos mais rudimentar (estilo UNIX) esta' presente. O programa ilustra muitas das considerac,o~es descritas neste manual, com respeito ao protocolo, o desenho do programa etc. Deve ser enfatizado que e' uma implementac,a~o mi'nima do KERMIT. Qualquer um que for escrever um novo KERMIT a partir do zero, deve se sentir encorajado a consultar na fonte a respeito das mais novas implementac,o~es avanc,adas como modelo (cheque, no Guia de Usua'rios KERMIT, a lista de implementac,o~es de KERMIT e suas facilidades). Embora voce possa na~o entender a linguagem em que foi escrito, os profusos comenta'rios podem ser u'teis. O programa a seguir usa notac,a~o decimal para nu'meros e tochar() ao inve's de char() na conversa~o integer-caracter. /* * K E R M I T File Transfer Utility * * UNIX KERMIT, Columbia University, 1981, 1982, 1983 * Bill Catchings, Bob Cattani, Chris Maio, * Frank da Cruz, Alan Crosswell * * also: Jim Guyton, Rand Corporation * Walter Underwood, Ford Aerospace * * usage: kermit c [lbe line baud escapechar] to connect * kermit s [d..ifbl line baud] file ...to send files * kermit r [d..ifbl line baud] to receive files * * where c=connect, s=send, r=receive, * d=debug, i=image mode, f=no filename conversion, * l=tty line, b=baud rate, e=escape char. * * for remote kermit, format is either: * kermit r to receive files * or kermit s files ... to send files * */ /* * modification history: * * oct. 17 included fixes from Alan Croswell (CUCCA) * for IBM_uts: * - change MYEOL character from \N to \R. * - change char to int in bufill so getc would return -1 on * EOF instead of 255 (-1 truncated to 8 bits) * - added read() in rpack to eat the EOL character * - added fflush() call in printmsg to force the output * note: the last three changes are not conditionally * compiled since they should work equally well on any * system. * * changed Berkeley 4.x conditional compilation flag from * UNIX4X to UCB4X. * added support for error packets and cleaned up the printing * routines. */ #include <stdio.h> /* definic,o~es standard UNIX */ /* Compilac,a~o condicional para sistemas/ma'quinas dif. */ /* Uma e so' uma das linhas abaixo pode ser 1 */ #define ucb4x 1 /* berkeley 4.x unix */ #define tops-20 0 /* tops-20 */ #define ibm_uts 0 /* amdahl uts em sistema IBM */ #define vax_vms 0 /* vax_vms (na~o implementada, ainda)*/ /* Compilac,a~o condicional para variantes UNIX */ /* Zero significa na~o compila; na~o-zero compila */ #if ucb4x #define v6_libs 0 /* na~o usa "retrofit libraries" */ #define no_fionread 0 /* temos ioctl(fionread,...) para flushinput() */ #define no_tandem 0 /* temos disciplina XON/XOFF */ #endif #if ibm_uts #define v6_libs 0 /* na~o usa "retrofit libraries" */ #define no_fionread 1 /* na~o temos ioctl(fionread,...) para flushinput() */ #define no_tandem 1 /* sem XON/XOFF */ #endif #if v6_libs #include <retrofit/sgtty.h> #include <retrofit/signal.h> #include <retrofit/setjmp.h> #else /* #include <sgtty.h> */ /* #include <signal.h> */ /* #include <setjmp.h> */ #endif #if no_tandem #define tandem 0 /* na~o suportada */ #endif /* definic,a~o de si'mbolos */ #define maxpacksiz 94 /* maior tamanho para um pacote */ #define soh 1 /* start of header */ #define cr 13 /* carriage return */ #define sp 32 /* espac,o */ #define del 127 /* delete (rubout) */ #define escchr '^' /* escape default no CONNECT */ #define maxtry 10 /* numero de tentativas por pacote */ #define myquote '#' /* caracter de marcac,a~o (quote ) */ #define mypad 0 /* nu'mero de carac.preenchimento */ #define mypchar 0 /* caracter preenchimento (null) */ #if ibm_uts #define myeol '\R' /* end-of-line para sistemas UTS */ #else #define myeol '\N' /* end-of-line */ #endif #define mytime 10 /* segundos para me porem em timeout */ #define maxtim 60 /* timeout ma'ximo*/ #define mintim 2 /* timeout mi'nimo */ /* #define true -1 */ /* constantes boleanas */ /* #define false 0 */ /* macros */ /* * tochar: converte um caracter de controle em caracter * imprimi'vel, somando um espac,o. * * unchar: desfaz tochar. * * ctl: converte caracteres de controle para imprimi'vel * e vice-versa, trocando o bit de controle (isto * e': ^A vira A e A vira ^A). */ #define tochar(ch) ((ch) + ' ') #define unchar(ch) ((ch) - ' ') #define ctl(ch) ((ch) ^ 64 ) /* varia'veis globais */ int size, /* tamanho do dado presente */ rpsiz, /* maior tamanho de pacote recebido */ spsiz, /* maior tamanho de pacote transmitido */ pad, /* quanto mandar de preenchimento */ timint, /* timeout para host estrangeiro em TX */ n, /* nu'mero do pacote */ numtry, /* vezes que retransmiti este pacote */ oldtry, /*vezes que pacote anterior foi retransmitido*/ ttyfd, /* fd de tty para I/O, 0 se remoto */ remote, /* -1 ==> sou KERMIT REMOTO */ image, /* -1 ==> modo 8 bits */ debug, /* ni'vel de sai'da de depurac,a~o */ /* 0 = nenhum */ filnamcnv, /* -1 ==> converte nome arq. p/maiu'sc.*/ filecount; /* nu'mero de arquivos deixados de TX */ char state, /* estado atual */ padchar, /* caracter de preenchimento a mandar */ eol, /* end-of-line a mandar */ escchr, /* caracter de escape num CONNECT */ quote, /* caracter de marcac,a~o que chega */ **filelist, /* lista de arquivos a TX */ *filnam, /* nome do arquivo corrente */ recpkt[maxpacksiz], /* buffer p/receber o pacote */ packet[maxpacksiz]; /* buffer para o pacote */ file *fp, /* pointer para arquivo em disco atual */ *log; /* pointer para arquivo de LOG */ jmp_buf env; /* prt.do ambiente para "timeout longjump" */ /* * m a i n * * main routine - analisa comandos e opc,o~es, * prepara a linha tty, * e pula para a rotina apropriada. */ main(argc,argv) int argc; /* pointers de caracteres e contadores */ char **argv; /* argumentos de linha de comando */ { char *ttyname, /* nome tty p/arg.linha */ *cp; /* pointer de caracter */ int speed, /* velocidade do tty */ cflg, rflg, sflg; /*flags p/connect,receive,send*/ struct sgttyb rawmode, /* controlando tty (raw mode) */ cookedmode, /* controlando tty (cooked mode) */ ttymode; /* modo de linha tty em opc,a~o de linha */ if (argc < 2) usage(); /* existe linha de comando? */ cp = *++argv; argv++; argc -= 2; /* arma ptrs p/args */ /* inicializa esses valores e torce p/que o primeiro pacote * passe numa boa... */ eol = cr; /* eol para pacotes saintes */ quote = '#'; pad = 0; /* sem preenchimento */ padchar = null; /* uso null se na~o se quer preench.*/ speed = cflg = sflg = rflg = 0; /* desliga todos os flags de analise */ ttyname = 0; /* o default e' modo remoto */ #if ucb4x /* default: mascarar em 7 bits, crlf */ image = false; /* maiu'sculas no que chegar e nos nomes de arquivos */ filnamcnv = true; /* conversion for unix systems */ #else image = true; filnamcnv = false; #endif escchr = escchr; /* caracter default p/escape */ while (( *cp) != null) /* analisa carac. no prim.arg.*/ switch (*cp++) { case 'C': cflg++; break; /* CONNECT */ case 'S': sflg++; break; /* SEND */ case 'R': rflg++; break; /* RECEIVE */ case 'D': /* increm. contador de depurac,a~o */ debug++; break; case 'F': /* F = na~o faz conv.maiu'sc.*/ filnamcnv = false; /*em nomes de arq. */ break; case 'I': /* modo imagem (8 bits) */ image = true; break; /* (este e' o default p/ na~o-UNIX)*/ case 'L': /* L = linha tty a usar */ if (argc--) ttyname = *argv++; else usage(); if (debug) printf("Linha p/ host remoto: %s/n", ttyname ); break; case 'E': /* E = caracter de escape */ if (argc--) escchr = **argv++; else usage(); if (debug) printf("Escape = \"%c\"\n",escchr); break; case 'B': /* baud rate */ #if ucb4x if (argc--) speed = atoi(*argv++); else usage(); if (debug) printf("Velocidade da linha p/ host: %d\n",speed); break; #else printmsg("Preparar velocidade so' sob UNIX."); exit(1); #endif } /* fazendo a ana'lise */ if ((cflg+sflg+rflg) != 1) /* so' pode 1 comando */ usage(); if (ttyname) /* se foi especificada linha, */ { /* opera em modo local */ ttyfd = open(ttyname,2); /* abre linha tty */ if (ttyfd < 0) { printmsg("%s nao abre.", ttyname); exit(1); } remote = false;/* indica modo local */ } else /* linha nao especificada */ { ttyfd = 0; remote = true; } /* poe o tty certo no modo correto */ if (remote) { gtty(0,&cookedmode); /* salva modo corrente*/ gtty(0,&rawmode); rawmode.sg_flags \= (raw\tandem); rawmode.sg_flags &= ^(echo\crmod); stty(0,&rawmode); /* poe tty em raw mode */ } else /* local, usa linha associada */ { gtty(ttyfd,&ttymode); ttymode.sg_flags \= (raw\tandem); ttymode.sg_flags &= ^(echo\crmod); #if ucb4x /* so' muda velocidade sob UNIX */ if (speed) /* usuario especificou veloc.? */ { switch(speed) { case 110: speed = b110; break; case 150: speed = b150; break; case 300: speed = b300; break; case 1200: speed = b1200; break; case 2400: speed = b2400; break; case 4800: speed = b4800; break; case 9600; speed = b9600; break; default: printmsg("Velocidade errada."); exit(1); } ttymode.sg_ispeed = speed; ttymode.sg_ospeed = speed; } #endif /* ucb4x */ stty(ttyfd,&ttymode); /* tty em in raw mode */ } /* tudo preparado, executa-se o comando dado. */ if (debug) { printf("Nivel de depuracao: %d\n\n",debug); if (cflg) printf("Comando CONNECT\n\n"); if (sflg) printf("Comando SEND\n\n"); if (rflg) printf("Comando RECEIVE\n\n"); } if (cflg) connect(); /* comando CONNECT */ if (sflg) /* comando SEND */ { if (argc--) filnam = *argv++; /* pega arq. p/TX */ else { if (remote) stty(0,cookedmode); /*restaura tty */ usage(); /* e da' o erro */ } fp = null; /* indica que ainda nao abriu arq. */ filelist = argv; /* prep. resto da lista de arq.*/ filecount = argc; /* num.arq.deixados de TX */ if (sendw() == false) /* manda o(s) arq(s) */ printmsg("SEND falhou."); else printmsg("Pronto."); } if (rflg) /* comando RECEIVE */ { if (recsw() == false)/* recebe o(s) arq.(s) */ printmsg("RECEIVE falhou."); else printmsg("Feito."); } if (remote) stty(0,&cookedmode); /* restaura modos tty */ } /* * s e n d s w * * E' o "switcher" da tabela de estados para mandar * arquivos. Fica em "loop" ate' acabar ou acontecer um erro. * As rotinas chamadas por ela sa^o responsa'veis pelas * mudanc,as na tabela. * */ sendsw() { char sinit(), sfile(), sdata(), seof(), sbreak(); state = 'S'; /* este e' o estado inicial */ n = 0; /* inicializa nu'mero da mensagem */ numtry = 0; /* nenhuma retransm., ainda */ while(true) /* faz isto enquanto for necessa'rio */ { if (debug) printf("Estado SENDSW: %c\n",state); switch(state) { case 'S': state = sinit(); break; /*send-init*/ case 'F': state = sfile(); break; /*send-file*/ case 'D': state = sdata(); break; /*send-data*/ case 'Z': state = seof(); break; /*send-eof*/ case 'B': state = sbreak(); break; /*send-break*/ case 'C': return (true); /* completo */ case 'A': return (false); /* "abort" */ default: return (false); /*desconhecido,falha*/ } } } /* * s i n i t * * SEND-INIT: manda os para^metros deste host e * pega os do outro lado. * */ char sinit() { int num, len; /* nu'mero e comprimento do pacote */ if (numtry++ > maxtry) return('A'); /* se muitas */ /* retransmisso~es, desiste */ spar(packet); /* preenche pacote infos iniciais*/ flushinput(); /* input pendente */ spack('S',n,6,packet); /* manda umpacote S */ switch(rpack(&len,&num,recpkt)) /* qual a resposta ? */ { case 'N': return(state); /* nak, tenta de novo */ case 'Y': /* ack */ if (n !=num) /* se ack errado, fica no estado S */ return(state); /* e tenta de novo */ rpar(recpkt); /* pega infos do outro lado */ if (eol == 0) eol = '\N'; /* checa e arma defaults */ if (quote == 0) quote = '#'; numtry = 0; /* zera contador de retransm. */ n = (n+1)%64; /* "pula" contador de pacotes */ return('F'); /* ok, muda estado para F */ case 'E': /* chegou pacote de erro */ prerrpkt(recpkt); /* imprime-o e */ return('A'); /* aborta */ case false: return(state); /* falha de RX, retenta */ default: return('A'); /* qq. outra coisa, aborta */ } /* * s f i l e * * manda cabec,alho de arquivo */ char sfile() { int num, len; /* nu'mero do pacote, comprimento */ char filnam1[50], /* nome de arquivo convertido */ *newfilnam, /* pointer para arq. a transmitir */ *cp; /* char pointer */ if (numtry++ > maxtry) return('A'); /* se muitas */ /* retransm., desiste */ if (fp == null) /* se ainda na~o aberto, */ { if (debug) printf("Abrindo %s para transmitir.\n",filnam); fp = fopen(filnam,"r"); /* abre o arquivo p/ ser TX */ if (fp == null) /* se pointer de arq.furado, desiste*/ { error("Nao da' p/ abrir %s", filnam); return('A'); } } strcpy(filnam1,filnam); /* copia nome do arquivo */ newfilnam = cp = filnam1; while (*cp != '\0') /* tira nomes do ini'cio do */ if (*cp++ == '/') /* direto'rio (ie. ate' u'ltimo) */ newfilnam = cp; if (filnamcnv) /* converte p/maiu'sculas */ for (cp = newfilnam; *cp != '\0'; cp++) if (*cp >= 'A' && *cp <= 'Z') *cp ^= 040; len = cp - newfilnam; /* computa compr.novo nome arq. */ printmsg("Transmitindo %s como %s", filnam, newfilnam); spack('F',n,len,newfilnam); /* manda um pacote F */ switch(rpack(&len,&num,recpkt)) /* qual a resposta? */ { case 'N': /* nak: fica neste estado */ num = (--num<0 ? 63:num); /* a menos que seja */ /* pelo pro'ximo pacote */ if (n != num) /* que e' como ack */ return(state); /* este pacote cai em... */ case 'Y': /* ack */ if (n != num) return(state); /* se ack errado, */ /* fica no estado F */ numtry = 0; /* zera contador de retransmisso~es */ n = (n+1)%64; /* "vira contador de pacote */ size = bufill(packet); /* pega prim.dado do arq.*/ return('D'); /* muda estado para D */ case 'E': /* Chegou pacote de erro */ prerrpkt(recpkt); /* imprime-o e */ return('A'); /* aborta */ case false: return(state); /* falha de RX: fica em F*/ default: return('A'); /* qq. outra coisa, aborta */ } } /* * s e o f * * manda end-of-file. */ char seof() { int num, len; /* nu'mero e compr. do pacote */ if (numtry++ > maxtry) return('A'); /* muitas = aborta */ spack('Z',n,0,packet); /* manda um pacote Z */ switch(rpack(&len,&num,recpkt)) /* qual foi a resposta ? */ { case 'N': /* nak: fica neste estado */ num = (--num<0 ? 63:num); /* a menos que seja um */ /* nak p/ pro'ximo pacote, */ if (n != num) /* que e' como um ack para este estado */ return(state); /* cai em...*/ case 'Y': /* ack */ if (n != num) return(state); /*se ack errado,segura*/ numtry = 0; /* zera contador de retransmisso~es */ n = (n+1)%64; /* e "vira" contador de pacote */ if (debug) printf("Fechando arquivo de entrada %s, ",filnam); fclose(fp); /* fecha o arquivo de entrada */ fp = null; /* arma flag = nenhum arquivo aberto */ if (debug) printf("Buscando proximo arquivo...\n"); if (gnxtfl() == false) /* nenhum outro arquivo a TX?*/ return('B'); /* se na~o, break, eot, pronto! */ if (debug) printf(" novo arquivo e' %s\n",filnam); return('F'); /* mais arquivos, estado vira F */ case 'E': /* chegou pacote de erro */ prerrpkt(recpkt); /* imprime-o e */ return('A'); /* aborta */ case false: return(state); /* falha de RX: fica em Z */ default: return('A'); /* qq. outra coisa, aborta */ } } /* * s b r e a k * * manda break (eot) * */ char sbreak() { int num, len; /* nu'mero e comprimento do pacote */ if (numtry++ > maxtry) return('A'); /* muitas=aborta */ spack('B',n,0,packet); /* manda pacote B */ switch (rpack(&len,&num,recpkt)) /* qual a resposta ? */ { case 'N': /* nak: fica neste estado */ num = (--num<0 ? 63:num); /* a menos que nak p/ */ /* pacote anterior, */ if (n != num) /* que e' como um ack */ return(state); /* p/este, dai' cai em*/ case 'Y': /* ack */ if (n != num) return(state); /* ack errado=falha*/ numtry = 0; /* zera contador de retransmisso~es */ n = (n+1)%64; /* e "vira" o nu'mero do pacote */ return('C'); /* estado vira completo */ case 'E': /* chegou pacote de erro */ prerrpkt(recpkt); /* imprime-o e */ return('A'); /* aborta */ case false: return(state); /* falha de RX: fica em B*/ default: return ('A'); /* qq.outra coisa: aborta */ } } /* * r e c s w * * Este e' o switcher da tabela de estados de RX de arq. * */ recsw() { char rinit(), rfile(), rdata(); /*usa estas procedures*/ state = 'R'; /* receive-init e' o estado inicial */ n = 0; /* inicializa nu'mero da mensagem */ numtry = 0; /* nenhuma retransmissa~o ainda */ while(true) { if (debug) printf(" Estado recsw: %c\n",state); switch(state) /* faz ate' acabar */ { case 'R': /* receive-init */ state = rinit(); break; case 'F': /* receive-file */ state = rfile(); break; case 'D': /* receive-data */ state = rdata(); break; case 'C': return(true); /* estado completo */ case 'A': return(false); /*estado de aborc,a~o */ } } } /* * r i n i t * * recebe inicializac,a~o * */ char rinit() { int len, num; /* comprimento e nu'mero do pacote */ if (numtry++ > maxtry) return('A'); /* muitas=aborta */ switch(rpack(&len,&num,packet)) /* pega um pacote */ { case 'S': /* send-init */ rpar(packet); /* pega o outro lado */ spar(packet); /* enche pacote c/minhas infos de */ /* inicializac,a~o */ spack('Y',n,6,packet); /* ack c/meus parms. */ oldtry = numtry; /* salva cont.retransmisso~es */ numtry = 0; /* inicializa novo contador */ n = (n+1)%64; /* "vira" num.pacote */ return('F'); /* entra em estado file-receive */ case 'E': /* chegou pacote de erro */ prerrpkt(recpkt); /* imprime-o e */ return('A'); /* aborta */ case false: /* na~o pegou pacote*/ spack('N',n,0,0); /* retorna nak */ return(state); /* fica tentando */ default: return('A'); /* qq.outro tipo aborta */ } } /* * r f i l e * * recebe cabec,alho de arquivo * */ char rfile() { int num, len; /* nu'mero e comprimento do pacote */ char filnam1[50]; /* guarda nome do arq. convertido */ if (numtry++ > maxtry) return('A'); /* muitas=aborta */ switch(rpack(&len,&num,packet)) /* pega um pacote */ { case 'S': /* send-init, talvez nosso ack se perdeu */ if (oldtry++ > maxtry) return('A'); /* muitas=abort */ if (num == ((n==0) ? 63:n-1)) /* pac.ant.mod 64?*/ { /* sim: ack de novo */ spar(packet); /* com nossos parms.*/ /* de send-init */ spack('Y',num,6,packet); numtry = 0; /* zera contador de retransm.*/ return(state); /* fica neste estado */ } else return('A'); /* sem pacote pre'vio: aborta*/ case 'Z': /* end-of-file */ if (oldtry++ > maxtry) return('A'); if (num == ((n==0) ? 63:n-1)) /*pac.ant.mod 64 ?*/ { /*sim: ack de novo*/ spack('Y',num,0,0); numtry = 0; return(state); /* fica este estado */ } else return('A'); /* sem pac.anterior: aborta */ case 'F': /* file header (o que queri'amos) */ if (num != n) return('A'); /* o num.pacote deve estar OK!*/ strcpy(filnam1,packet); /* copia o nome do arq. */ if (filnamcnv) /* converte p/minu'sculas */ for (filnam=filnam1; *filnam != '\0'; filnam++) if (*filnam >= 'A' && *filnam <= 'Z') *filnam \= 040; if ((fp=fopen(filnam1,"w"))==null) /*tenta abrir*/ /* novo arq. */ { error("nao da' p/criar %s",filnam1); /*se na~o*/ /* da', desiste */ return('A'); } else /* ok: da' mensagem */ printmsg("Recebendo %s como %s",packet,filnam1); spack('Y',n,0,0); /* ack p/ cab.arq. */ oldtry = numtry; /* Zera cont.retransm. */ numtry = 0; /* ... */ n = (n+1)%64; /* "vira" num.pacote mod 64 */ return('D'); /* entra em estado de dados */ case 'B': /* interrompe transmissa~o (eot) */ if (num != n) return('A'); /* preciso #pacote certo aqui */ spack('Y',n,0,0); /* diz OK */ return('C'); /* vai p/estado completo */ case 'E': /* chegou pacote de erro */ prerrpkt(recpkt); /* imprime-o e */ return('A'); /* aborta */ case false: /* na~o pegou pacote */ spack('N',n,0,0); /* devolve um nak */ return(state); /* fica tentando */ default: return('A'); /* qq.outro pacote: aborta */ } } /* * r d a t a * * recebe dados * */ char rdata() { int num, len; /* nu'mero e comprimento do pacote */ if (numtry++ > maxtry) return('A'); /* muitas = aborta */ switch(rpack(&len,&num,packet)) /* pega pacote */ { case 'D': /* pegou pacote de dados */ if (num != n) /* pacote certo? */ { /* na~o */ if (oldtry++ > maxtry) return('A'); /* muitas=aborta */ if (num == ((n==0) ? 63:n-1)) /* sena~o checa nu'mero do pacote */ { /* pacote anterior de novo? */ spack('Y',num,6,packet); /* sim: re-ack */ numtry = 0; /* zera cont.retransm. */ return(state); /* na~o grava dados */ } else return('A'); /*desculpe: nu'mero errado.*/ } /* pega dados c/nu'mero certo */ bufemp(packet,len); /* grava os dados no arquivo*/ spack('Y',n,0,0); /* ack p/pacote */ oldtry = numtry; /* zera cont.retransm. */ numtry = 0; /* ... */ n = (n+1)%64; /* "vira" num.pacote */ return('D'); /* permanece em estado de dados */ case 'F'; /* pega cabec,alho de arquivo */ if (oldtry++ > maxtry) return('A'); /* muitas=aborta */ if (num == ((n==0) ? 63:n-1)) /*senao checa #pac*/ { /* era o pacote anterior */ spack('Y',num,0,0); /* ack de novo */ numtry = 0; /* zera cont.retr. */ return(state); /* fica em est.dados*/ } else return('A'); /* na~o pac.pre'vio: aborta */ case 'Z': /* end-of-file */ if (num != n) return('A'); /* deve ter num.pac certo */ spack('Y',n,0,0); /* ok: ack */ fclose(fp); /* fecha o arq. */ n = (n+1)%64; /* "vira" #pacote */ return('F'); /* volta estado recebe arq. */ case 'E': /* chegou pacote de erro */ prerrpkt(recpkt); /* imprime-o e */ return('A'); /* aborta */ case false: /* na~o pegou pacote */ spack('N',n,0,0); /* retorna nak */ return(state); /* fica tentando*/ default: return('A'); /* qq.outro pacote = aborta */ } } /* * c o n n e c t * * Estabelece conexa~o de terminal virtual com o host * remoto via linha tty. * */ connect() { int pid, /* guarda identificac,a~o da crianc,a */ connected; /* flag de conexa~o */ char bel = '\07', c; struct sgttyb rawmode, /* controlando tty, modo raw */ cookedmode; /* controlando tty, modo cooked */ if (remote) /* nada a que conectar em remoto */ { printmsg("nenhuma linha especificada para conexa~o."); return; } gtty(0,&cookedmode); /* salva modo corrente */ gtty(0,&rawmode); rawmode.sg_flags \= (rawmode\tandem); rawmode.sg_flags &= ^(echo\crmod); stty(0,&rawmode); /* po~e tty em modo raw */ pid = fork(); /* comeca a "garfar" o que */ /* o host remoto "digitar" */ if (pid) /* pai: manda teclas p/ host remoto */ { printmsg("conectado...\r"); connected = true; /* entra em modo conectado */ while (connected) { read(0,&c,1); /* pega um caracter */ if ((c&0177) == escchr) /* ve se caracter de esc*/ { read(0,&c,1); if ((c&0177) == escchr) write(ttyfd,&c,1); else switch (c&0177) { case 'C': connected = false; write(0,"\r\n",2); break; case 'H': write(0,"\r\nyes,ainda estou aqui...\r\n",26); break; default: write(0,&bel,1); break; } } else { /* se na~o caracter de escape, */ write(ttyfd,&c,1); /* transmite-o */ c = null; /* nulifica-o (por que?) */ } } kill(pid,9); /* pronto: mata a crianc,a */ wait(0); /* e queima-a */ stty(0,&cookedmode); /* restaura modo tty */ printmsg("disconectado.") return; /* pronto */ } else /* a crianc,a le^ do host remoto */ { while(1) /* faz isto p/sempre */ { read(ttyfd,&c,1); write(1,&c,1); } } } /* * utilita'rios kermit. */ clkint() /* timer interrupt handler */ { longjmp(env,true); /* manda rpack desistir */ } /* * r p a c k * * manda um pacote * */ spack(type,num,len,data) char type, *data; int num, len; { int i; /* contador de loop de caracter */ char chksum, buffer[100]; /* checksum, buffer de pacote*/ register char *bufp; /* pointer do buffer */ if (debug>1) /* mostra pacote sainte */ { if (data != null) data[len] = '\0'; /*termina dados c/nulo p/impr.*/ printf(" tipo do spack: %c\n",type); printf(" numero: %d\n",num); printf(" comprimento: %d\n",len); if (data != null) printf(" dados: \"%s\"\n",data); } bufp = buffer; /* arma pointer do buffer */ for (i=1; i<=pad; i++) write(ttyfd,&padchar,1); /* manda qq. preenchi/o */ *bufp++ = soh; /* marcador de pacote (soh) = ASCII 1 */ *bufp++ = tochar(len+3); /* manda o contador de carac. */ chksum = tochar(len+3); /* inicializa o checksum */ *bufp++ = tochar(num); /* numero do pacote */ chksum += tochar(num); /* atualiza o checksum */ *bufp++ = type; /* tipo do pacote */ chksum += type; /* atualiza o checksum */ for (i=0; i<len; i++) /* loop para todos os caracteres */ { *bufp++ = data[i]; /* pega um caracter */ chksum += data[i]; /* atualiza o checksum */ } chksum = (((chksum&0300) >> 6)+chksum)&077; /* calcula checksum final */ *bufp++ = tochar(chksum); /* po~e no pacote */ *bufp = eol; /* terminador de linha extra-packet */ write(ttyfd,buffer,bufp-buffer+1; /* manda o pacote */ } /* * r p a c k * * le^ um pacote */ rpack(len,num,data) int *len, *num; /* nu'mero e comprimento do pacote */ char *data; /* dados do pacote */ { int i, done; /* nu'mero carac. de dados, sai'da do loop */ char t, /* caracter de input corrente */ type, /* tipo do pacote */ cchksum, /* nosso (do computador) checksum */ rchksum; /* checksum recebido do host */ #if ucb4x /* o tops-20 na~o manuseia timeouts... */ if (setump(env)) return false; /* atingiu timeout: falhou */ signal(sigalrm,clkint); /* arma o timeout */ if ((timint > maxtim) \\ (timint < mintim)) timint = mytime; alarm(timint); #endif /* ucb4x */ while (t != soh) /* espera cabec.arquivo */ { read(ttyfd,&t,1); t &= 0177; /* manuseia paridade */ } done = false; /* recebeu soh, inicia loop */ while (!none) /* loop p/ conseguir um pacote */ { read(ttyfd,&t,1); /* pega caracter */ if (!image) t &= 0177; /* trata paridade */ if (t == soh) continue; /* resincroniza se soh */ cchksum = t; /* inicializa o checksum */ *len = unchar(t)-3; /* contador de caracteres */ read(ttyfd,&t,1); /* pega caracter */ if (!image) t &= 0177; /* trata paridade */ if (t == soh) continue; /* resincroniza se soh */ cchksum = cchksum + t; /* atualiza checksum */ *num = unchar(t); /* nu'mero do pacote */ read(ttyfd,&t,1); /* pega caracter */ if (!image) t &= 0177; /* trata paridade */ if (t == soh) continue; /* atualiza checksum */ type = t; /* tipo do pacote */ for (i=0; i<*len; i++) /* o pro'prio dado, se existir*/ { /* loop para contar caracteres */ read(ttyfd,&t,1); /* pega caracter */ if (!image) t &= 0177; /* manuseia paridade */ if (t == soh) continue; /* resincroniza se soh */ cchksum = cchksum + t; /* atualiza checksum */ data[i] = t; /* inclui checksum no buffer */ } data[*len] = 0; /* marca fim de dados */ read(ttyfd,&t,1); /* pega u'ltimo caracter (checksum)*/ rchksum = unchar(t); /* converte p/ numerico */ read(ttyfd,&t,1); /* pega caracter de eol e joga */ if (!image) t &= 0177; /* manuseia paridade */ if (t == soh) continue; /* resincroniza se soh */ done = true; /* pegou checksum, feito */ } #if ucb4x alarm(0); /* desabilita o timer interrupt */ #endif if (debug>1) /* mostra pacote chegante */ { if (data != null) data[*len] = '\0'; /* encerra dado c/nulo p/impr*/ printf(" tipo rpack: %c\n",type); printf(" numero: %d\n",*num); printf(" comprimento: %d\n",*len); if (data != null) printf(" dados: \"%s\"\n",data); } cchksum = (((cchksum&0300) >> 6)+cchksum)&077; /*checksum final*/ if (cchksum != rchksum) return(false); return(type); /* tudo bem; retorna tipo do pacote */ } /* * b u f i l l * * Pega buffer cheio de dados do arquivo sendo * transmitido. * So' e' feito controle de marcac,a~o; * na~o sa~o manuseadas as prefixac,o~es de * oitavo bit e * contador de repetic,o~es. */ bufill(buffer) char buffer[]; /* buffer */ { int i, /* indice do loop */ t; /* caracter lido do arquivo */ char t7; /* versa~o 7-bit d'acima */ i = 0; /* inicializa pointer do buffer de dados */ while((t = getc(fp)) != eof) /*pega pro'ximo caracter */ { t7 = t & 0177; /* pega 7 bits de mais baixa ordem */ if (t7 < sp \\ t7==del \\ t7==quote) /* este caracter precisa manuseio especial? */ if (t=='\n' && !image) { /* faz mapeamento lf->crlf se !image */ buffer[i++] = quote; buffer[i++] = ctl('\r'); } buffer[i++] = quote; /* marca o caracter */ if (t7 != quote) { t = ctl(t); /* e descontrolifica-o */ t7 = ctr(t7); } } if (image) buffer[i++] = t; /* deposita o pro'prio caracter */ else buffer[i++] = t7; if (i >= spsiz-8) return(i); /* checa comprimento */ } if (i==0) return (eof); /*sobrevoa por aqui so' se eof*/ return(i); /* trata buffer parcial */ } /* * b u f e m p * * po~e dado do pacote chegante num pacote * */ bufemp(buffer,len) char buffer[]; /* buffer */ int len; /* comprimento */ { int i; /* contador */ char t; /*guardador de carac*/ for (i=0; i<len; i++) /* loop pelo campo de dados */ { t = buffer[i]; /* pega caracter */ if (t == myquote) /*marca de controle?*/ { /* sim */ t = buffer[++i]; /* pega caracter marcado */ if ((t & 0177) != myquote) /* bits de mais baixa ordem batem c/carac.marc.?*/ t = ctl(t); /* na~o: descontrolifica-o */ } if (t==cr && !image) /* na~o passa cr se em modo imagem */ continue; putc(t,fp); } } .foKERMIT: Manual do Protocolo # /* * g n x t f l * * Pega pro'ximo arquivo de um grupo. */ gnxtfl() { if (debug) printf(" gnxtfl: lista de arq. = \"%s\"\n",*filelist); filnam = *(filelist++); if (filecount-- == 0) return false; /* se na~o mais, falhou */ else return true; /* sena~o: funcionou */ } /* * s p a r * * Enche a matriz de dados c/meus para^metros de send-init * */ spar(data) char data[]; { data[0] = tochar(maxpacksiz); /*maior pacote posso RX */ data[1] = tochar(mytime); /* quando quero ser timeout */ data[2] = tochar(mypad); /* quanto preechi/o preciso */ data[3] = ctl(mychar); /* quero este carac.preench.*/ data[4] = tochar(myeol); /* eol que eu quero */ data[5] = myquote; /* marcac,a~o que eu mando */ } /* * r p a r * * Pega os para^metros de send-init do outro host * */ rpar(data) char data[]; { spsiz = unchar(data[0]); /* maior pacote */ timint = unchar(data[1]); /* quando timeout */ pad = unchar(data[2]); /* quanto preenchimento */ padchar = ctl(data[3]); /* eol que devo mandar */ quote = data[5]; /* marca que vira' */ } /* * f l u s h i n p u t * * Para o lixo com todo input pendente, de forma a limpar * NAKs porventura empilhados. * (Implementado so' por causa do UNIX de Berkeley, desta * vez.) * */ #if ucb4x&(^no_fionread) flushinput() { long int count; /* nu'mero de bytes prontos para ler */ long int i; /* nu'mero de bytes para ler em loop */ ioctl(ttyfd,fionread,&count); /*quantos bytes faltam ler*/ if (!count) return; /* se zero, na~o precisa dispensar input */ while (count) /* loop ate' todos dispensados */ { i = (count<sizeof(recpkt)) /* le min.do cont e */ count : sizeof(recpkt); /* buffer de leitura */ read(ttyfd, recpkt, i); /* le um monte, */ count -= i; /* subtrai do total a ler */ } } #else flushinput() /* versa~o nula p/ unix na~o-berkeley */ [] #endif /* ucb4x&(^fionread) */ /* * Rotinas de impressa~o do KERMIT. * * usage - imprime as opc,o~es da linha de comando, * mostrando a sintaxe correta * printmsg - como printf com "kermit: " antes * error - como printmsg se kermit local; * manda pacote de erro se remoto * prerrpkt - imprime o conteu'do do pacote de erro recebido * do host remoto * */ /* * u s a g e * * Imprime suma'rio do uso e termina * */ usage() { #if ucb4x printf("uso: kermit c[lbe line baud esc.char] (connect mode)\n"); printf(" ou: kermit s[diflb line baud] file...(send mode)\n"); printf(" ou: kermit r[diflb line baud] (receive mode)\n"); #else printf("uso: kermit c[le line esc.char] (connect mode)\n"); printf(" ou: kermit s[diflb line] file ... (send mode)\n"); printf(" ou: kermit r[diflb line] (receive mode)\n"); #endif exit(1); } /* * p r i n t m s g * * Imprime mensagem no output padra~o se na~o remoto. * */ /*varargs1*/ printmsg(fmt, a1, a2, a3, a4, a5) char *fmt; { if (!remote) { printf("kermit: "); printf(fmt,a1,a2,a3,a4,a5); printf("\n"); fflush(stdout); /* forca output (uts precisa!) */ } } /* * e r r o r * * Imprime mensagem de erro * * Se local, imprime com printmsg. * Se remoto, manda um pacote de erro com a mensagem. * */ /*varags1*/ error(fmt, a1, a2, a3, a4, a5) char *fmt; { char msg[80]; int len; if (remote) { sprintf(msg,fmt,a1,a2,a3,a4,a5); /* tranf. em string*/ len = strlen(msg); spack('e',n,len,msg); /* manda o pacote de erro */ } else printmsg(fmt, a1, a2, a3, a4, a5); return; } /* * p r e r r p k t * * Imprime o conteu'do do pacote de erro recebido do host * remoto. * */ prerrpkt(msg) char *msg; { printf("KERMIT ABORTANDO C/MENSAGEM DO REMOTO:\n%s\n",msg); return; } .pa O conjunto de caracteres ASCII ..@adu E. O conjunto de caracteres ASCII (ANSI X3.4-1968) ..@iANSI ..@iASCII ..@icaracteres, ASCII Existem 128 caracteres no alfabeto ASCII (American national Standard Code for Information Interchange). Esta~o listados em ordem de seus valores ASCII. As colunas sa~o entituladas como ASCII DEC representac,a~o decimal (base 10) ASCII OCT representac,a~o octal (base 8) ASCII HEX representac,a~o hexadecimal (base 16) EBCDIC HEX equivalente hexadecimal EBCDIC para as tabelas de convera~o do KERMIT CHAR representac,a~o gra'fica ou nome do caracter OBS. descric,a~o do caracter. O primeiro grupo e' constitui'do de caracteres de controle na~o imprimi'veis. ===ASCII=== =EBCDIC= DEC OCT HEX HEX CHAR OBS. 000 000 00 00 NUL ^@, nulo, morto 001 001 01 01 SOH ^A, ini'cio de cabec,alho 002 002 02 02 STX ^B, ini'cio de texto 003 003 03 03 ETX ^C, fim de texto 004 004 04 37 EOT ^D, fim de transmissa~o 005 005 05 2D ENQ ^E, consulta 006 006 06 2E ACK ^F, reconhecimento 007 007 07 2F BEL ^G, bell, bip, campainha 008 010 08 16 BS ^H, back-space 009 011 09 05 HT ^I, tabulac,a~o horizontal 010 012 0A 25 LF ^J, line-feed 011 013 0B 0B VT ^K, tabulac,a~ vertical 012 014 0C 0C FF ^L, alimentac,a~o de formula'rio 013 015 0D 0D CR ^M, retorno de carro 014 016 0E 0E SO ^N, shift-out (sai) 015 017 0F 0F SI ^O, shift-in (entra) 016 020 10 10 DLE ^P, data link escape 017 021 11 11 DC1 ^Q, device control 1 (XON) 018 022 12 12 DC2 ^R, device control 2 019 023 13 13 DC3 ^S, device control 3 (XOFF) 020 024 14 3C DC4 ^T, device control 4 021 025 15 3D NAK ^U, na~o reconhecimento 022 026 16 32 SYN ^V, marca de sincronismo 023 027 17 26 ETB ^W, fim de transmissa~o de bloco 024 030 18 18 CAN ^X, cancela 025 031 19 19 EM ^Y, fim de mi'dia 026 032 1A 3F SUB ^Z, substituto 027 033 1B 27 ESC ^[, escape, prefixo, altera modo 028 034 1C 1C FS ^\, separador de arquivos 029 035 1D 1D GS ^], separador de grupos 030 036 1E 1E RS ^^, separador de registros 031 037 1F 1F US ^_, separador de unidades Os quatro u'ltimos sa~o associados usualmente a`s verso~es de controle de barra-inversa, abre-colchete, circunflexo (seta-para-cima) e sublinhado, respectivamente mas alguns terminais na~o transmitem esses caracteres de controle. Os que seguem sa~o imprimi'veis. Primeiro, caracteres de pontuac,a~o: ===ASCII=== =EBCDIC= DEC OCT HEX HEX CHAR OBS. 032 040 20 40 SP espac,o, branco 033 041 21 5A ! ponto de exclamac,a~o 034 042 22 7F " aspas 035 043 23 7B # sustenido, jogo-da-velha, lasanha 036 044 24 5B $ do'lar 037 045 25 6C % porcento 038 046 26 50 & "e"-comercial 039 047 27 7D ' apo'strofo, acento agudo 040 050 28 4D ( abre-pare^nteses 041 051 29 5D ) fecha-pare^nteses 042 052 2A 5C * asterisco 043 053 2B 4E + mais 044 054 2C 6B , vi'rgula 045 055 2D 60 - hi'fen, menos, trac,o 046 056 2E 4B . ponto, pingo 047 057 2F 61 / barra caracteres nume'ricos: ===ASCII=== =EBCDIC= DEC OCT HEX HEX CHAR OBS. 048 060 30 F0 0 zero 049 061 31 F1 1 um 050 062 32 F2 2 dois 051 063 33 F3 3 tres 052 064 34 F4 4 quatro 053 065 35 F5 5 cinco 054 066 36 F6 6 seis 055 067 37 F7 7 sete 056 070 38 F8 8 oito 057 071 39 F9 9 nove mais caracteres de pontuac,a~o: .cp10 ===ASCII=== =EBCDIC= DEC OCT HEX HEX CHAR OBS. 058 072 3A 7A : dois-pontos 059 073 3B 5E ; ponto-e-vi'rgula 060 074 3C 4C < menor-que 061 075 3D 7E = igual 062 076 3E 6E > maior-que 063 077 3F 6F ? ponto de interrogac,a~o 064 100 40 7C @ arro^ba .cp30 caracteres alfabe'ticos maiu'sculos (letras) ===ASCII=== =EBCDIC= DEC OCT HEX HEX CHAR OBS. 065 101 41 C1 A 066 102 42 C2 B 067 103 43 C3 C 068 104 44 C4 D 069 105 45 C5 E 070 106 46 C6 F 071 107 47 C7 G 072 110 48 C8 H 073 111 49 C9 I 074 112 4A D1 J 075 113 4B D2 K 076 114 4C D3 L 077 115 4D D4 M 078 116 4E D5 N 079 117 4F D6 O 080 120 50 D7 P 081 121 51 D8 Q 082 122 52 D9 R 083 123 53 E2 S 084 124 54 E3 T 085 125 55 E4 U 086 126 56 E5 V 087 127 57 E6 W 088 130 58 E7 X 089 131 59 E8 Y 090 132 5A E9 Z .cp10 mais caracteres de pontuac,a~o: ===ASCII=== =EBCDIC= DEC OCT HEX HEX CHAR OBS. 091 133 5B AD [ abre-colchete 092 134 5C E0 \ barra-inversa 093 135 5D BD ] fecha-colchete 094 136 5E 5F ^ circunflexo, seta-para-cima 095 137 5F 6D _ sublinhado 096 140 60 79 ` acento grave .cp30 caracteres alfabe'ticos minu'sculos: ===ASCII=== =EBCDIC= DEC OCT HEX HEX CHAR OBS. 097 141 61 81 a 098 142 62 82 b 099 143 63 83 c 100 144 64 84 d 101 145 65 85 e 102 146 66 86 f 103 147 67 87 g 104 150 68 88 h 105 151 69 89 i 106 152 6A 91 j 107 153 6B 92 k 108 154 6C 93 l 109 155 6D 94 m 110 156 6E 95 n 111 157 6F 96 o 112 160 70 97 p 113 161 71 98 q 114 162 72 99 r 115 163 73 A2 s 116 164 74 A3 t 117 165 75 A4 u 118 166 76 A5 v 119 167 77 A6 w 120 170 78 A7 x 121 171 79 A8 y 122 172 7A A9 z .cp8 mais caracteres de pontuac,a~o: ===ASCII=== =EBCDIC= DEC OCT HEX HEX CHAR OBS. 123 173 7B C0 { abre-chave 124 174 7C 4F | barra-vertical 125 175 7D D0 } fecha-chave 126 176 7E 7E ~ til .cp5 e, finalmente, mais um caracter na~o imprimi'vel: ===ASCII=== =EBCDIC= DEC OCT HEX HEX CHAR OBS. 127 177 7F 07 DEL delete, rubout. .pa