ESCAPE DE BYTES SERIAIS
Como um delimitador também pode ser um dado?
Um receptor serial recebe caracteres, enquanto a aplicação precisa identificar mensagens. O SLIP aplica escape a C0 e DB na carga útil usando sequências de dois bytes, para que END sem escape possa delimitar um pacote. O receptor reverte o mapeamento, preservando seu estado entre leituras. Esses valores específicos pertencem ao SLIP e não fornecem automaticamente verificação de erros nem segurança.
Caractere versus pacote
O limite de um caractere, por si só, não identifica uma mensagem da aplicação.
Aplicar escape a dados especiais
O SLIP representa bytes especiais da carga útil com sequências de dois bytes.
Manter o estado
Um analisador deve manter seu estado de escape mesmo quando uma leitura termina após DB.
Mapeie as extremidades e o escopo.
Confirme o protocolo e as configurações efetivamente utilizados.
Teste com dados inofensivos e autorização.
Lista de verificação para seleção e validação — expandir
Confirme o protocolo e a camada de captura; teste bytes comuns e especiais; verifique leituras divididas, marcadores duplicados e tratamento de erros em um ambiente autorizado.
Uma linha serial fornece um fluxo de bytes. Como o programa receptor sabe onde uma mensagem termina? Uma abordagem consiste em reservar um marcador. Mas uma medição ou um arquivo pode conter o mesmo valor de byte, e enviá-lo sem alteração pode fazer com que seja confundido com um encerramento. O escape de bytes resolve essa ambiguidade. Para entendê-lo, separe a recepção de caracteres, os limites dos pacotes e o significado para a aplicação, em vez de considerar apenas a taxa de transmissão.
Caracteres corretos não formam automaticamente um pacote
Uma interface serial assíncrona comum usa um bit de início, bits de dados e bits de parada para identificar um caractere. Quando os caracteres chegam a um programa, formam uma sequência de bytes. O receptor não sabe automaticamente onde uma leitura de temperatura começa e termina. Os limites dos caracteres e os limites de mensagens completas são problemas distintos.
Um protocolo de aplicação pode usar um comprimento fixo, um campo de comprimento, temporização ou marcadores especiais para delimitar mensagens. Cada opção tem condições e compromissos. Este artigo usa o SLIP, um exemplo simples de enquadramento serial, para explicar marcadores e escape. Isso não significa que todo protocolo serial use SLIP ou que um protocolo existente deva ser alterado sem os devidos cuidados.
O servidor de dispositivos seriais FCT-1100-F1S1 da Feichang, de porta única e três em um, fornece um contexto real de comunicação serial para rede. Bytes encaminhados por uma interface ou rede não adquirem automaticamente um novo significado de negócio. Este artigo não deduz o protocolo de enquadramento interno do produto; consulte a documentação e a configuração para conhecer seus recursos reais.
Por que um marcador pode ter duas funções
Suponha que ambas as extremidades concordem que determinado byte marca o fim. Ao recebê-lo, um analisador entrega os dados anteriores armazenados no buffer. A ideia se assemelha à pontuação que marca o fim de uma frase. O conteúdo binário, porém, pode conter qualquer valor de byte; nenhum valor escolhido está automaticamente ausente da carga útil.
Um registro de medição pode conter o mesmo valor do marcador de fim. O analisador deve tratar essa ocorrência como dado ou como limite? O valor, por si só, não permite distinguir as duas funções. O transmissor e o receptor precisam de uma regra compartilhada que altere a representação dos valores especiais no meio de transmissão.
Simplesmente proibir um valor restringe o que os dados originais podem expressar e pode alterar medições silenciosamente. Substituir cobre por fibra também não elimina a ambiguidade: a conversão óptica altera o meio de transmissão, não a interpretação do protocolo de aplicação. A qualidade do enlace e as regras de codificação devem ser verificadas separadamente.
O escape altera a representação, não os dados
O escape pode ser entendido como um sinal para interpretar o byte seguinte segundo uma regra acordada. O transmissor examina a carga útil e substitui os valores de byte protegidos por sequências especiais. O receptor reverte o mapeamento e deve obter o mesmo conteúdo original.
No exemplo de SLIP descrito na RFC 1055, o valor hexadecimal C0 é END e DB é ESC. Um C0 dentro da carga útil torna-se DB DC; um DB dentro da carga útil torna-se DB DD. Um C0 sem escape fornece o limite final efetivo. Esses valores específicos pertencem a este exemplo, não a todos os protocolos seriais.
Por que aplicar escape também a DB? Ele introduz uma interpretação especial do byte seguinte. Se um DB original fosse enviado sem distinção, o próximo valor comum poderia ser confundido com um sufixo de escape. Proteger tanto o delimitador quanto o introdutor de escape evita criar uma nova ambiguidade.
Acompanhe um exemplo curto do transmissor ao receptor
Considere a carga útil original 11 C0 22 DB 33. Os dois valores especiais não podem ser inseridos diretamente no fluxo enquadrado como conteúdo comum. A codificação produz 11 DB DC 22 DB DD 33; os marcadores END efetivos delimitam o resultado para que o receptor possa distinguir as funções de controle dos dados restaurados.
Esta ilustração coloca C0 antes e depois do pacote. A RFC 1055 aborda o envio de um END no início como forma de descartar ruído acumulado; um resultado de comprimento zero decorrente de marcadores consecutivos não deve ser entregue como um pacote IP normal. Outros protocolos não usam necessariamente marcadores idênticos nas duas extremidades.
Após a decodificação, C0 e DB da carga útil voltam a ser dados comuns. Os próprios delimitadores não fazem parte do conteúdo entregue. A codificação pode aumentar o número de bytes no meio de transmissão. Contadores do servidor serial, capturas e comprimentos observados na aplicação podem diferir quando medidos em camadas diferentes, sem que isso comprove perda de dados.
Um receptor deve manter seu estado atual
O analisador nem sempre pode interpretar cada byte isoladamente. Ele precisa, no mínimo, distinguir a leitura normal da espera por um sufixo após um introdutor de escape. No estado normal, um END marca o limite do pacote; um DB muda o estado para espera pelo sufixo, em vez de emitir imediatamente DB como dado original.
No estado de espera, o receptor aplica o mapeamento acordado e retorna ao estado normal. A relação entre dois bytes é mantida pelo estado do analisador; os bytes não precisam chegar na mesma operação de leitura do software. Se uma leitura termina com DB e a seguinte começa com DC, o receptor deve manter o estado e concluir a conversão.
Uma implementação real também precisa de regras para sufixos inválidos, limites de buffer, pacotes vazios e interrupções. Este artigo não impõe uma estratégia universal de tratamento de erros. Se o software reiniciar o estado de análise a cada leitura de rede, ou presumir que cada leitura é uma mensagem, o enquadramento poderá falhar mesmo que o transporte tenha entregado todos os bytes.
Um limite não é uma verificação de erros nem uma garantia de segurança
O escape resolve a ambiguidade de representação. Ele não acrescenta automaticamente detecção de erros, retransmissão, autenticação ou criptografia. Dividir um fluxo em pacotes não comprova que cada pacote esteja correto nem que seu remetente seja confiável. O próprio SLIP oferece serviços limitados e não deve ser tratado como um protocolo geral de segurança para controle industrial.
Protocolos diferentes também podem aplicar verificações e escape em etapas diferentes. O enquadramento semelhante ao HDLC do PPP tem suas próprias regras de sinalização, transparência e verificação de quadros; esses detalhes não são idênticos aos do SLIP. Misturar valores de marcadores, sufixos de escape ou etapas de verificação pode fazer com que ambos os lados recebam bytes sem que nenhum deles aceite um pacote.
Mapeie onde se encontram os dados originais da aplicação, a codificação, o transporte físico ou de rede, a decodificação e a validação da aplicação. Ao investigar erros, identifique a camada de observação antes de comparar o conteúdo esperado. Uma comparação direta, byte a byte, entre o tráfego codificado e os campos decodificados da aplicação pode criar uma falha aparente que não existe.
Verifique as regras acordadas com pequenas amostras repetíveis
Comece pela documentação do dispositivo e do protocolo. Registre versões, configurações de interface, empacotamento e pontos de captura. Teste dados comuns, dados que contenham o valor de fim, dados que contenham o valor de escape e valores especiais consecutivos. Verifique as formas codificadas e decodificadas. Estes são métodos ilustrativos, não uma afirmação de que um produto específico foi submetido a medições.
Em seguida, teste leituras divididas, leituras agrupadas e conexões interrompidas quando a implementação precisar lidar com essas situações. Use dados inofensivos em um ambiente autorizado, não bytes de exemplo como comandos em um ambiente de produção ativo. Se as extremidades usarem protocolos diferentes, determine quem realiza a conversão antes de alterar repetidamente as taxas de transmissão.
Lembre-se das camadas: a UART identifica caracteres, uma regra de enquadramento identifica mensagens e o escape impede que valores especiais da carga útil sejam confundidos com marcadores de controle. Separá-las explica por que uma porta pode receber bytes enquanto a aplicação ainda não consegue reconstruir uma mensagem completa.
Referências principais
RFC 1055: SLIP, junho de 1988, não é um padrão da Internet; RFC 1662: PPP em enquadramento semelhante ao HDLC, julho de 1994. Contexto do produto: servidor de dispositivos seriais FCT-1100-F1S1; isso não afirma que ele use SLIP.
Traduzido do artigo técnico em chinês: Leia o artigo original em chinês.
Dúvidas práticas frequentes
Receber caracteres seriais identifica automaticamente um pacote?
Não. A recepção de caracteres pela UART e o enquadramento da aplicação são processos distintos; ambas as extremidades precisam das mesmas regras de enquadramento.
Como o SLIP aplica escape a C0 e DB na carga útil?
C0 na carga útil torna-se DB DC, e DB na carga útil torna-se DB DD; END sem escape indica um limite. Outros protocolos podem usar regras diferentes.
O escape de bytes substitui verificações de integridade ou criptografia?
Não. Ele elimina a ambiguidade entre marcadores de controle e valores da carga útil; não fornece automaticamente detecção de erros, retransmissão, autenticação ou criptografia.
Escopo e leituras adicionais
Exemplo genérico de enquadramento SLIP, não uma afirmação sobre um produto específico ou dados medidos.
Encerramento parcial de TCP e respostas seriais · Cargas unitárias de RS485 e capacidade de acionamento do driver
