Treinamento em Redes de Automação Petrobras Parte 1

Treinamento em Redes de Automação Petrobras Parte 1

(Parte 6 de 9)

Costuma-se atribuir o código ASCII equivalente a Control - Q (DC1 ou 11H) para XON e o valor Control - S (DC3 ou 13H) para XOFF.

Um problema comum como o XON / XOFF pode ocorrer quando fazemos transmissão de arquivos de texto tipo documentos que utilizam caracteres especiais para indicar texto em negrito, sublinhado, etc., num sistema onde o receptor ecoa os caracteres recebidos pelo transmissor, como uma espécie de verificação contra erros.

Caso o texto seja gerado no editor de texto Wordstar, modo documento, ao se utilizar de um trecho sublinhado, o Wordstar automaticamente insere o caracter 13H (coincidentemente o mesmo valor utilizado para XOFF!) para servir de controle no começo e no fim do trecho sublinhado, como pode ser visto na figura abaixo.

Código ASCII do Texto Texto

0D 0A 64 69 6 69 63 69 6C 20 13 64 69 7A 65 72 difícil dizer 20 71 75 65 20 6 6F 69 20 62 6F 6E 69 74 6F

13 que foi bonito

OD 0A 69 6E 75 74 69 6C 20 63 6F 6E 74 61 72 20 inútil contar 6F 20 71 75 65 20 70 65 72 64 1A 1A 1A 1A 1A 1A o que perdi

Assim que for transmitido o caracter 13H, o Receptor o ecoa de volta ao Transmissor que, ao recebê-lo, interpreta-o como XOFF, parando de transmitir e aguardando então um XON para voltar a transmissão.

SENAI-SP 29/67

Redes de Automação – Treinamento Petrobrás

Como o Receptor não enviou o caracter XOFF por sua iniciativa, foi apenas eco do que recebeu, não tem por que enviar XON e assim fica aguardando o transmissor. Conclusão: ambos aguardam que o outro transmita e assim a comunicação cessa! É a síndrome do "Esperando Godot", referência à peça teatral de Becket; para evitar essa situação basta desabilitar o eco.

Transferência de arquivos Os produtos para transmissão assíncrona de arquivos costumam trabalhar com blocos de arquivo, e a necessidade dessa estratégia é fácil de reconhecer a partir da seguinte questão: Como deve ser feita a verificação de erros numa transmissão de arquivo: a cada byte ou apenas após a transmissão de todo o arquivo?

É fácil verificar que nenhuma das duas condições é satisfatória: a verificação a cada byte seria certamente mais demorada, e a verificação apenas ao final da transmissão poderia ser ineficiente - caso um único byte chegue errado, deve ser retransmitido todo o arquivo.

A solução intermediária é dividir o arquivo em blocos de tamanho conveniente, organizá-los apropriadamente de modo a ser fácil o reconhecimento do seu início ou do seu fim antes de enviá-los.

Essa organização é feita com a ajuda de Campos de controle auxiliares, anexados ao bloco de dados de modo a facilitar o controle e a recuperação do arquivo original. A figura a seguir exemplifica esse processo de organização de blocos de dados através de campo de controle.

Processo de organização de blocos de dados através de Campo de controle.

Assim sendo, na figura acima, a função do campo 1 pode ser a de identificar o início deste bloco de dados, os caracteres que fazem parte do Bloco de dados podem ser associados a um campo de dados; o campo 4 pode conter informações que ajudem na verificação de erros; o campo 2 pode conter o número seqüencial que ajude na recuperação posterior do arquivo, e assim por diante.

SENAI-SP 30/67

Redes de Automação – Treinamento Petrobrás

Os campos associados ao Bloco de Dados caracterizam uma unidade de transmissão chamada Pacote; um exemplo de transmissão de Pacotes com quatro campos pode ser visto na figura a seguir:

Exemplo de transmissão de Pacotes com quatro campos.

Conforme o Protocolo que estivermos estudando, podemos encontrar vários tipos de

Campos, entretanto, alguns são freqüentemente utilizados em vários Protocolos, diferindo apenas quanto ao tamanho ou posição dentro de um Pacote.

Vamos então considerar quatro tipos básicos de Campos: de Identificação, de Controle de Seqüência, de Dados e de Verificação de Erros, assinalando para cada um algumas características gerais.

Campo de Identificação:

* Caracterização: Este campo serve para a Identificação do Pacote, uma vez que podemos necessitar de Pacotes com funções especiais tais como Confirmação de Bloco, Bloco Recusado, etc., além de Bloco com Dados. * Tamanho: Costuma ser de um byte.

* Posição no Pacote: Este Campo costuma ser o primeiro, devido à sua natureza.

SENAI-SP 31/67

Redes de Automação – Treinamento Petrobrás

Campo de Controle de Seqüência

* Caracterização: Trata-se de um contador que é incrementado a cada Pacote enviado pelo Transmissor para auxiliar o Receptor a detectar perda de Pacotes; esse contador é relativo, ou seja, supondo ser de um byte seu tamanho, a contagem será de 0 a 255 com retorno a zero novamente, repetindo-se indefinidamente. * Tamanho: Costuma ser de um byte ou menor.

* Posição no Pacote: Pode ser após o Campo de Identificação e antes do Campo de Dados.

Campo de Dados

• Caracterização: Possui os dados propriamente ditos, muitas vezes separados por caracteres especiais para indicar início de bloco, fim de bloco ou fim de arquivo.

• Posição no Pacote: Costuma ser sempre após o Campo de Controlede
Seqüência e antes do Campo de Verificação de Erros.

• Tamanho: Pode ser de tamanho fixo ou variável; cada um tem vantagens e desvantagens.

Campo de Verificação de Erros

de Dados somente.
byte no caso de BCC.

• Caracterização: Utilizado para enviar o BCC ou CRC calculado sobre o Campo • Tamanho: Costuma ser de dois bytes no caso de CRC e Checksum, e de um • Posição no Pacote: É normalmente colocado no final do Pacote.

Uma observação vale aqui: conforme a natureza do Pacote, não se torna necessário utilizar todos os Campos acima descritos; por exemplo, num Pacote de Confirmação de Dados Recebidos, apenas o Campo de Identificação é o que interessa.

Os campos podem ter apenas um byte de tamanho e neste caso utilizamos um conjunto de caracteres existentes na Tabela ASCII selecionados para este fim, descritos na tabela abaixo.

SENAI-SP 32/67

Redes de Automação – Treinamento Petrobrás

Abreviação Código ASCII Descrição Uso Comum

SOH 01H Start of Header

Indica o início de um cabeçalho (header) ou Campo de Identificação.

STX 02H Start of Text Indica o início do bloco de dados, e marca o fim do header.

ETX 03H End of Text Indica o fim do bloco de dados.

EOT 04H End of Transmission

Indica fim de uma transmissão quando enviado no lugar de SOH.

ENQ 05H Enquiry

Quando se está estabelecendo uma ligação, pode significar "Você está me ouvindo?"; durante uma sessão pode significar pedido de identificação ou status atual.

ACK 06H ACKnowledge Utilizado quando é feita uma recepção livre de erros.

DLE 10H Data Link Escape

Utilizado quando se deseja utilizar caracteres com o significado de controle, não de dados.

NAK 21H Not ACKnowledge

(Parte 6 de 9)

Comentários