Resumo

  • A RFC 1179 documentou o LPD como prática existente: um daemon TCP no porto 515 recebia comandos para uma fila nomeada, inclusive o comando para iniciar a impressão dos trabalhos em espera.
  • Em Receive job, há confirmação do subcomando de arquivo, uma marca do cliente ao terminar os bytes declarados e uma segunda confirmação do daemon. A sequência comprova uma troca de arquivos delimitada, não uma página impressa.

Um trabalho atravessava estados que não pertenciam ao mesmo ator

Uma solicitação de impressão passa pelo cliente, pelo daemon, pela fila, pelo processo que é acionado, pelo arquivo de controle que interpreta os dados e, só depois, pelo equipamento de saída. A interface pode mostrar uma palavra verde para todos esses estados. O protocolo, porém, não os confundia.

Publicada em agosto de 1990, a RFC 1179 descreve um protocolo de servidor de impressão já usado na Internet. É um documento informativo, não um Internet Standard. O texto define comandos, formatos de arquivo e respostas do daemon. Não promete que uma resposta de rede carregue também o veredicto sobre papel, formatação ou entrega física.

LPD usa TCP e o daemon escuta a porta 515. Cada comando ao daemon abre uma nova conexão. Um código binário vem seguido do nome ASCII da fila e, quando necessário, de outros operandos. A RFC diz que os nomes dos comandos devem ser entendidos como instruções dadas ao daemon. Uma instrução recebida não é a mesma coisa que o efeito solicitado.

O comando Print any waiting jobs torna isso concreto. Ele inicia o processo de impressão se este ainda não estiver ativo. Não afirma que um trabalho específico foi escolhido, que os arquivos podem ser interpretados, que existe papel ou que qualquer página saiu. É uma ordem de início, situada entre a recepção da fila e a possível observação do resultado.

A recepção tinha dois momentos de confirmação

Depois de entrar em Receive job, o cliente pode mandar subcomandos para receber um arquivo de controle ou de dados. Após cada subcomando, deve esperar uma confirmação do daemon. Um octeto com todos os bits em zero é positivo; outro padrão é negativo. Essa primeira resposta trata da próxima operação do intercâmbio.

O arquivo cria uma fronteira adicional. O subcomando informa uma contagem de bytes e um nome. O cliente envia essa quantidade na mesma conexão e, depois de completá-la, envia um octeto zero para declarar o arquivo transmitido completo. Em seguida deve ocorrer um segundo nível de confirmação. O mesmo desenho vale para um arquivo de dados cuja extensão foi indicada.

Esses eventos têm objetos distintos. O primeiro acuse responde ao subcomando. O zero do cliente é a declaração de que alcançou a quantidade prometida. O segundo acuse é a resposta do daemon após essa fronteira. A cadeia permite localizar o progresso da transferência sem converter esse progresso em uma alegação sobre a impressora.

O número de bytes não interpreta o documento. A RFC permite qualquer valor de oito bits no arquivo de dados e atribui sua interpretação ao arquivo de controle correspondente. Uma contagem correta não demonstra que o conteúdo era imprimível, que o formatador o compreendeu ou que o equipamento o converteu em folha.

O arquivo de controle era instrução, não identidade certificada

O arquivo de controle podia informar host, identificação de usuário, nome do arquivo de origem, formato e pedido de e-mail quando impresso. Essas linhas dizem ao daemon como tratar os dados. Elas não verificam uma pessoa, não demonstram propriedade do documento e não comprovam que o e-mail foi entregue. O número do trabalho distingue itens no modelo limitado da fila, não cria uma identidade global persistente.

Também as operações de fila permanecem limitadas. LPD pode apresentar estado de fila e aceitar uma ordem de remoção com fila, agente e nomes ou números. A RFC impõe limites a um agente que não seja root ao remover trabalho de outro usuário. Trata-se de uma regra de comando local, não de uma prova de quem leu, liberou ou recebeu o documento.

O valor histórico do LPD está em nomear os fatos que ele realmente alcança. Podemos dizer que o daemon aceitou um subcomando, que o cliente declarou bytes completos, que o daemon respondeu depois e que recebeu uma ordem para iniciar trabalhos pendentes. Para dizer que houve impressão, recolha ou efeito posterior, é preciso evidência de outra superfície.

Fontes