Resumo
- O RFC 1014, publicado pela Sun Microsystems em junho de 1987, organizava os itens codificados em múltiplos de quatro bytes. Uma string variável levava um contador de quatro bytes, o conteúdo e zeros até a próxima fronteira.
- No exemplo do próprio RFC,
sillyprogocupa nove bytes de caracteres e três de preenchimento. O tipo de arquivo começa no deslocamento 16. O contador mede o nome; os zeros posicionam o campo seguinte.
A Sun Microsystems escolheu uma cena simpática para explicar um formato rígido. O usuário john guarda um programa Lisp chamado sillyprog, cujo conteúdo é (quit). Antes de escrever as nove letras do nome no fluxo, o XDR escreve o número 9 em quatro bytes. Depois das letras vêm três zeros. O tipo do arquivo aparece no deslocamento 16. Nenhum desses zeros pertence ao nome; cada um ajuda a arrumar o corredor para quem vem atrás.
Em 1987, uma estação Sun, um VAX, um IBM PC e um Cray podiam trocar dados sem compartilhar a mesma arquitetura. O RFC citava esses exemplos ao apresentar XDR, External Data Representation, como descrição e codificação comuns. Sun RPC e NFS o utilizavam para descrever seus dados. O acordo começava com a ideia de que um byte de oito bits poderia viajar preservando o sentido. Sobre esse tijolo básico, XDR construía uma regra repetida: os itens ocupavam sempre múltiplos de quatro bytes.
Um inteiro de 32 bits já preenchia uma unidade inteira. Um nome com nove caracteres deixava três espaços vagos na última unidade. O formato completava esses espaços com zeros. Assim, o nome continuava tendo comprimento 9, porém consumia doze bytes no fluxo depois do contador. O receptor lia nove caracteres e saltava os três zeros para chegar ao próximo campo. O custo era pequeno e visível. O benefício era poder calcular a posição do campo seguinte sem perguntar como a máquina de origem organizava sua memória.
A tabela hexadecimal do RFC mostra a conta aberta. Nos deslocamentos 0 a 3 fica o comprimento 9. De 4 a 12 vêm as letras de sillyprog. As posições 13, 14 e 15 recebem zeros. No 16 começa EXEC, o tipo do arquivo representado pelo valor 2. Se alguém incluísse os zeros no nome, alteraria o nome. Se avançasse apenas nove bytes e tentasse ler o próximo valor, começaria três posições cedo demais. A fronteira de quatro bytes tirava essa negociação das mãos de cada implementação.
O restante do exemplo mostra que o método não depende do tamanho natural de cada dado. EXEC seleciona o ramo da estrutura que traz o intérprete lisp: contador 4 e quatro letras. O proprietário john recebe o mesmo tratamento. Já os dados (quit) têm seis bytes, com contador 6 antes e dois zeros depois. A cada etapa, o leitor sabe quantos bytes são conteúdo e quantos completam o bloco. A sequência pode mudar de assunto sem perder o lugar.
O RFC distinguia strings de dados opacos. Uma string era descrita como bytes ASCII; uma sequência opaca mantinha os bytes sem o XDR atribuir significado a eles. Ambas podiam ter limite máximo declarado, e codificar um comprimento acima desse teto era um erro. O contador ajudava a localizar o fim do conteúdo e a testar esse limite. O preenchimento servia a outra pergunta: onde começa o campo seguinte? O formato separava as duas tarefas com uma disciplina que cabia numa linha de aritmética.
Também havia uma escolha sobre quem mandava na interpretação. A estrutura de um programa em memória pertence ao compilador e à máquina que a criou. Ponteiros locais não apontam para o mesmo lugar em outro computador. A descrição XDR definia os tipos e sua ordem; a codificação definia os bytes compartilhados. No arquivo de john, o valor EXEC ativava um ramo que continha o intérprete. O receptor seguia esse roteiro e encontrava cada novo campo na fronteira prevista.
Zeros de preenchimento têm preço. O nome paga três, os dados de seis bytes pagam dois. O RFC os exibe em vez de escondê-los atrás de uma promessa vaga de portabilidade. O pequeno programa sillyprog prova o acordo numa escala que qualquer leitor pode conferir: o nome termina, o bloco se completa e EXEC começa no deslocamento 16. Na rede, até os lugares vazios precisam constar da planta.
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





