directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Directory Wiki] Update of "LdapCodec" by EmmanuelLecharny
Date Wed, 03 Aug 2005 23:22:32 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Directory Wiki" for change notification.

The following page has been changed by EmmanuelLecharny:

  == Decoding an LDAP message ==
  Each LDAP message starts with a first automate :
- attachment:LdapMessage
+ attachment:LdapMessage.png
  The next part (''protocol``Op'') will contains all the different type of possible messages.
- attachment:protocolOp
+ attachment:protocolOp.png
  Each message is described in the next chapters.
  It can be followed by an optionnal control part, which automaton state is  shown below :
- attachment:Controls
+ attachment:Controls.png
  Those two states automaton will be implemented as a Grammar instance, which will be processed
for each LdapMessage we will receive. When we will know which kind of Message we have to deal
with, a new Grammar will be loaded and processed (a Bind``Request grammar, or a Bind``Response...).
If the specific message is correctly decoded, we may have to load the Controls grammar. So
the engine switch from grammar to grammar depending on which part it is decoding. This is
implemented by a Grammar stack which is stored in the decoder Container.
@@ -292, +292 @@

  Many Ldap``Message while return a result. A specific sub-diagram is dedicated to this Ldap``Result
- attachment:LdapResult
+ attachment:LdapResult.png
  We have a specific Grammar to process this LdapResult.
@@ -300, +300 @@

  The Bind``Request Ldap Message state diagram is shown below :
- attachment:BindRequest
+ attachment:BindRequest.png
  The decoding of a Bind``Request message is simple, as we just need to build an engine that
walks through the state automaton, checking at each state that the next transition is valid,
and execute the associated action. In the real world, it's a little bit more complicated,
because states are not those that we have in the pictures. We have to split each 'state' to
sub-states : one sub-state for the '''Type''', one sub-state for the '''Length''' and another
one for the '''Value''', if necessary. 
@@ -314, +314 @@

  The Ldap Bind``Response message is also made up of four elements : a ''Ldap``Message'',
the ''Bind``Response'', a ''Ldap``Result'' element and optionnaly a final ''Controls''. Here
is the inner ''Bind``Response'' element :
- attachment:BindResponse
+ attachment:BindResponse.png
  === UnBindRequest ===
  This is the simplest automate! It is fully described in the protocol``OP schema.
- attachment:UnBindRequest
+ attachment:UnBindRequest.png
  === AbandonRequest  ===
@@ -328, +328 @@

  This request just send the Message id which has to be stopped.
- attachment:AbandonRequest
+ attachment:AbandonRequest.png
  === SearchRequest ===
  The heart of LDAP. Search request are quite complicated, as LDAP is mainly used to search
information. We will use four different automatons to express this part of the LDAP grammar
- attachment:SearchRequest
+ attachment:SearchRequest.png
- attachment:Filter
+ attachment:Filter.png
- attachment:SubstringFilter
+ attachment:SubstringFilter.png
- attachment:MatchingRuleAssertion
+ attachment:MatchingRuleAssertion.png
  === Search responses ===
  We may have three different kind of responses to a ldap Search. The first two are entries
or references, and the last one is returned when all teh entries or references have been sent.
- attachment:SearchResultEntry
+ attachment:SearchResultEntry.png
- attachment:SerachResultReference
+ attachment:SearchResultReference.png
- attachment:SearchResultDone
+ attachment:SearchResultDone.png
  === Add ===
  We can add an entry. Here is the message to send, and the response you get :
- attachment:AddRequest
+ attachment:AddRequest.png
- attachment:AddResponse
+ attachment:AddResponse.png
  === Del ===
  We can delete an entry. Here is the message to send, and the response you get :
- attachment:DelRequest
+ attachment:DelRequest.png
- attachment:DelResponse
+ attachment:DelResponse.png
  === Modify ===
  We can modify an entry. Here is the message to send, and the response you get :
- attachment:ModifyRequest
+ attachment:ModifyRequest.png
- attachment:ModifyResponse
+ attachment:ModifyResponse.png
  === Modify DN ===
  We can modify a DN. Here is the message to send, and the response you get :
- attachment:ModifyDNRequest
+ attachment:ModifyDNRequest.png
- attachment:ModifyDNResponse
+ attachment:ModifyDNResponse.png
  === Extended message ===
  Otherwise, as LDAP accepts extension, it does through those two messages :
- attachment:ExtendedRequest
+ attachment:ExtendedRequest.png
- attachment:ExtendedResponse
+ attachment:ExtendedResponse.png

View raw message