Resumo

  • O MessageID precisava ser distinto apenas entre solicitações ainda ativas na mesma sessão LDAP. Todas as entradas, referências e o desfecho de uma busca repetiam o número, permitindo respostas intercaladas.
  • Abandon levava um ID próprio no envelope e outro para a operação-alvo, mas não devolvia confirmação. O RFC 3909 criou Cancel quando a aplicação precisava distinguir sucesso, impossibilidade ou chegada tardia.
  • Cada página de uma busca paginada usava novo message ID; a continuidade ficava com um cookie opaco. O número não era credencial, nome durável da consulta nem prova de rollback.

Uma busca produzia uma sequência, não uma resposta

O adjetivo lightweight reduzia o custo de acesso ao modelo de diretório X.500. Não fazia uma consulta de subárvore caber em uma única mensagem. O servidor podia devolver muitas entradas, referências a outros contextos de nomes e, somente ao fim, um resultado de sucesso ou erro.

Em julho de 1993, o RFC 1487 envolveu toda operação em LDAPMessage. O campo comum era o inteiro messageID, diferente dos demais pedidos pendentes na mesma sessão. O servidor ecoava o valor em todos os envelopes de resposta correspondentes.

Portanto, não era numeração de pacote. Uma centena de entradas podia pertencer ao mesmo estado de busca. O distinguished name identificava o objeto; o tipo da operação explicava a forma da mensagem. O ID ligava o PDU recebido ao registro correto que o cliente ainda mantinha aberto.

O escopo pequeno era parte da solução. Outra sessão podia usar o mesmo valor, e a própria sessão podia reutilizá-lo depois de um encerramento seguro. Bastava impedir ambiguidade no conjunto que o receptor conseguia comparar: os trabalhos simultaneamente em curso.

A ordem do transporte deixou de governar a aplicação

O RFC 1777, de 1995, dispensou comportamento síncrono. Pedidos e respostas de várias operações podiam circular em qualquer ordem.

Uma entrada da busca 8 podia chegar, o compare 9 podia terminar e, depois, outras entradas e o fechamento da busca 8. O TCP ordenava bytes, mas não atribuía cada mensagem a um trabalho da aplicação. O Message ID dividia um fluxo físico em fluxos lógicos.

O RFC 2251 preservou o mecanismo no LDAPv3 em 1997, definiu o limite de 2^31−1 e proibiu reutilização antes da resposta final. Clientes em geral incrementavam um contador; a garantia, porém, não era crescimento monotônico, e sim ausência de colisão entre pedidos pendentes.

As respostas de busca passaram a distinguir SearchResultEntry, SearchResultReference e SearchResultDone. Entradas e referências podiam vir misturadas; um único Done encerrava a operação. Receber dados válidos não significava que a busca havia terminado com sucesso. O resultado final dizia como ela acabou e normalmente liberava a vida útil do ID.

Zero ficou para a fala espontânea do servidor

Em 2006, a especificação foi reorganizada. O RFC 4510 registra a relação com o conjunto anterior, e o RFC 4511 traz a regra revisada.

Um request passou a exigir messageID não zero. O valor zero foi reservado à unsolicited notification do servidor, como a Notice of Disconnection. Ela não responde a pedido do cliente e não deve parecer parte de uma operação zero inexistente.

Essa reserva não autentica o emissor. Apenas cria uma classe localmente reconhecível fora dos trabalhos iniciados pelo cliente. O tipo da mensagem e o OID da notificação continuam dando o sentido; autenticação e proteção pertencem a outros mecanismos.

Reutilizar também depende do estado, não do tempo decorrido. O cliente precisa determinar que o servidor não atende mais a solicitação antiga—por exemplo, após a resposta final ou um Bind posterior concluído. Timeout local pode exigir fechar e reconciliar, mas não apaga sozinho a tabela remota.

Abandon apontava com precisão e terminava em silêncio

Abandon é uma nova solicitação LDAP. Seu envelope recebe MessageID próprio; o conteúdo carrega outro MessageID, correspondente à operação anterior que se quer abandonar. O desenho preserva a diferença entre correlacionar o novo ato e escolher seu alvo.

Não existe resposta de Abandon. Pelo RFC 4511, o servidor pode abandonar o alvo. Se for uma busca já transmitindo entradas, ele deve interromper novas entradas e não enviar SearchResultDone. Mesmo assim, resultados já em trânsito podem chegar, e certas operações não admitem abandono.

O silêncio economiza uma troca quando o cliente já não quer o conteúdo. Também impede uma conclusão indevida: não se distingue abandono bem-sucedido de trabalho ainda incompleto. O ID pode estar certo sem fornecer prova do efeito.

O RFC 2251, por isso, adiava a reutilização tanto do ID de Abandon quanto do alvo até chegar resposta de uma solicitação posterior. Essa resposta não confirmava o abandono; mostrava apenas avanço suficiente na sessão para reduzir uma colisão imediata.

Cancel introduziu o resultado que faltava

O RFC 3909, de 2004, definiu a operação estendida Cancel para quem precisa de um desfecho. Não fingiu que Abandon sempre tivera esse poder.

Cancel leva seu próprio ID de envelope e um cancelID para o alvo pendente. Quando dá certo, o servidor responde success ao Cancel e encerra o alvo com canceled. Outros códigos distinguem uma operação desconhecida, uma que não pode ser cancelada ou uma tentativa tardia.

O exemplo de tooLate é uma alteração já gravada no armazenamento subjacente. Correlação perfeita não cria capacidade de reversão. O protocolo pode localizar exatamente o update e, ainda assim, reconhecer que seu efeito atravessou uma fronteira irreversível.

Bind, StartTLS, Unbind, Abandon e o próprio Cancel não podem ser cancelados. Eles estabelecem, alteram ou desmontam a associação e a segurança nas quais os demais IDs fazem sentido. Uma chave de correlação não ganha autoridade ilimitada sobre o próprio contexto.

A página seguinte precisava de outra operação

O RFC 2696 oferece a prova negativa mais clara. Em SearchResultDone, o servidor entrega um cookie opaco. Para obter a próxima página, o cliente repete a busca, troca o messageID, envia o cookie mais recente e pode ajustar o tamanho.

Cada página é uma nova operação LDAP. O cookie transporta o estado de continuação entre elas. Um cookie antigo pode deixar de servir; um vazio encerra a sequência. Abandon pode interromper uma página em andamento e invalidar o cookie. Para fechar a série corretamente, envia-se nova busca com tamanho zero e o último cookie.

O ID responde qual operação ativa da sessão produziu a mensagem. O cookie responde qual posição do conjunto o servidor permite retomar. Distinguished name, autorização e veracidade do atributo continuam sendo questões independentes.

Limite das fontes

O registro histórico fechado reúne RFC 1487, RFC 1777, RFC 2251, RFC 2696, RFC 3909, RFC 4510 e RFC 4511. Eles provam regras e revisões, não adoção atual, conformidade de produto ou o resultado real de uma operação capturada.

O inteiro permaneceu útil porque sua autoridade ficou estreita. Ele ligava mensagem a estado observável. Conclusão, cancelamento, continuação, autenticação e autorização exigiam evidência própria.