Resumo
- SLIP é apresentado por RFC 1055 como uma convenção mínima de enquadramento de IP em linha serial: END fecha a unidade e ESC protege os valores que poderiam fingir ser estrutura.
- O END enviado antes do pacote seguinte custa, numa linha limpa, uma unidade vazia descartada; numa linha ruidosa, ele impede que uma sobra incerta se torne o começo do próximo datagrama.
- Borda de moldura, integridade dos bytes e alinhamento de um decodificador que guarda estado são responsabilidades diferentes. RFC 1144 e RFC 1662 ajudam a vê-las sem atribuir todas ao delimitador.
A virtude de uma promessa estreita
RFC 1055 é incomumente claro sobre o que SLIP não é. Publicado em 1988, chama Serial Line IP de padrão de fato para conexões TCP/IP ponto a ponto em série, mas não de Internet Standard. Mais importante, diz que SLIP é apenas um protocolo de framing de pacotes: define uma sequência de caracteres que enquadra datagramas IP em uma linha serial, e nada além disso.
Essa frase desenha uma fronteira de responsabilidade. SLIP não carrega informação de endereçamento. Não possui campo de tipo para separar protocolos diferentes na mesma linha. Não detecta nem corrige erro. Não comprime. Os pares precisam saber por outro meio quais endereços IP usar; um pacote que chegou entre dois delimitadores não recebe por isso um atestado de que seus bits são os originais.
Seria fácil ler essas ausências como uma lista de defeitos que PPP resolveria depois. A leitura histórica mais rigorosa é outra. Em um elo serial de baixa velocidade, o problema mínimo era converter uma corrente temporal de octetos em uma unidade que ambos os lados reconhecessem como datagrama. Para isso, o acordo precisava de uma borda e precisava impedir que dois valores de dados fossem confundidos com a própria borda. Não precisava fingir que essa borda decidia todo o resto da conexão.
O acordo reserva END, octal 0300 e decimal 192, para assinalar o fim, e ESC, octal 0333 e decimal 219, para o byte stuffing. Se os dados contêm END, o emissor manda ESC seguido de 0334; se contêm ESC, manda ESC seguido de 0335. Ao terminar os dados, envia END. O receptor, dentro da gramática SLIP, desfaz essas duas conversões e toma END como conclusão da moldura.
Não se trata de uma regra genérica sobre caracteres. END só é estrutural para o leitor que está na condição de montar uma moldura SLIP. ESC só introduz as duas substituições acordadas. O emissor deixa uma marca transitória para proteger o dado contra a interpretação da camada externa; o receptor dessa camada a remove. A operação preserva transparência do payload, mas não o declara íntegro, seguro ou semanticamente correto.
Uma moldura termina antes que a outra comece
O refinamento atribuído a Phil Karn dá ao protocolo seu pequeno gesto de recuperação. RFC 1055 sugere começar o pacote também com END, para eliminar dados errôneos que possam ter se acumulado no receptor por ruído na linha.
Num caso normal, há dois END seguidos: o que fechou o pacote anterior e o que precede o novo. O documento aceita a consequência sem dramatização. A dupla pode gerar um pacote IP vazio ou inválido; a pilha IP o descartaria, e a função receptora mostrada no RFC simplesmente ignora um END quando nenhum byte foi recolhido. O pacote vazio é o custo explícito de conservar uma borda limpa.
Depois de uma perturbação, o mesmo END faz algo diferente. Talvez o buffer contenha uma sequência que não pode ser atribuída de modo confiável ao pacote anterior, mas que seria tomada como prefixo do próximo se nada interrompesse a leitura. O END inicial encerra esse acúmulo. A sobra de ruído é abandonada antes de os bytes do novo datagrama serem aceitos; o receptor volta a esperar conteúdo após uma fronteira conhecida.
É por isso que END não “recupera o pacote” no sentido forte. Ele recupera uma posição de leitura. Não repara os bytes descartados, não mostra que a moldura seguinte passou incólume pela linha e não ensina a uma camada superior qual estado ela deveria lembrar. Ele apenas retira do fragmento anterior a capacidade de escrever o início da próxima interpretação.
O código de exemplo em RFC 1055 mantém a honestidade do modelo. Só devolve uma unidade quando vê END depois de algum dado; ignora as unidades de tamanho zero criadas pelos END duplicados. Depois de ESC, reconhece duas sequências especiais; se vier outro valor, chama aquilo de violação de protocolo e armazena o byte sem uma grande cerimônia de rejeição. É um leitor de borda com uma proteção mínima de dados, não um verificador universal.
Onde a borda deixa de ser suficiente
RFC 1144, sobre compressão de cabeçalhos TCP/IP em links seriais lentos, mostra por que a moldura recuperada não pode levar sozinha a palavra “recuperação”. O fluxo descrito passa o pacote IP por um compressor e, depois, por um framer. O compressor mantém, para conexões no enlace serial, cópias de cabeçalhos anteriores; um pacote comprimido pode carregar diferenças em relação a esse estado.
Assim, o receptor pode encontrar corretamente uma fronteira e ainda carecer de duas coisas: prova de que os bytes daquela unidade não foram corrompidos e o estado anterior que permite interpretar diferenças. RFC 1144 coloca a detecção de erro no nível de framing e observa que o descompressor precisa receber indicação do erro para descartar o pacote ruim e evitar que um erro se propague. O END inicial do SLIP não fornece essa indicação. Sua função termina antes.
Convém separar perguntas que muitas operações confundem: onde está a moldura? Os bytes dentro dela são íntegros? O consumidor que depende da história anterior tem a mesma história que o emissor? Uma soma de verificação ou FCS pode ajudar na segunda; uma redefinição de contexto pode tratar da terceira. Um delimitador responde somente à primeira.
RFC 1662 oferece uma comparação posterior precisa. O framing PPP de estilo HDLC define uma Flag Sequence para início ou fim, transparência por octeto, FCS e manejo de molduras inválidas. Ele também avisa que aproveitar a flag de fechamento como abertura da próxima economiza um octeto, mas pode baixar a confiabilidade depois de um período ocioso: sem uma nova flag de abertura, caracteres de ruído podem entrar na moldura seguinte. Não é preciso transformar PPP em veredito contra SLIP. Basta reconhecer que o contrato mais amplo especifica de modo separado a borda, a verificação e o descarte.
Fazer a autoridade do marcador acabar no lugar certo
As Notas 64 e 65 de Heng Lu sugerem o teste editorial adequado: localizar a menor função determinística que uma implementação em execução pode comprovar localmente e não promover essa função a autoridade geral. Em SLIP, END pode fechar uma acumulação e iniciar uma nova leitura. ESC pode proteger dois valores. Nenhum deles pode certificar o payload que se segue ou restaurar o estado que outro mecanismo precisa.
Uma análise de recomeço de fluxo deve guardar separadamente os bytes brutos antes da marca, a marca END vista, os bytes que formaram a moldura seguinte, o veredicto de integridade e o estado usado por qualquer decodificador dependente de pacotes anteriores. “Pacote recuperado” é uma frase curta demais para quatro fatos que podem divergir.
Fontes e limites da evidência
O conjunto fechado é RFC 1055, RFC 1144 e RFC 1662. Ele sustenta a gramática END/ESC, a finalidade do END inicial, as ausências declaradas de SLIP, a separação compressor/framer e a comparação limitada com PPP. Não sustenta adoção universal, comportamento de dispositivos contemporâneos, uma taxa medida de ruído, um resultado de segurança ou uso de RFC 1144 em toda linha SLIP.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
