directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Directory Wiki] Update of "LdapCodec" by EmmanuelLecharny
Date Wed, 03 Aug 2005 23:23:30 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:
http://wiki.apache.org/directory/LdapCodec

------------------------------------------------------------------------------
  == Decoding an LDAP message ==
  Each LDAP message starts with a first automate :
  
+ 
+ ---- /!\ '''Edit conflict - other version:''' ----
  attachment:LdapMessage.png
+ 
+ ---- /!\ '''Edit conflict - your version:''' ----
+ attachment:LdapMessage.png
+ 
+ ---- /!\ '''End of edit conflict''' ----
  
  The next part (''protocol``Op'') will contains all the different type of possible messages.
:
  
+ 
+ ---- /!\ '''Edit conflict - other version:''' ----
  attachment:protocolOp.png
+ 
+ ---- /!\ '''Edit conflict - your version:''' ----
+ attachment:protocolOp.png
+ 
+ ---- /!\ '''End of edit conflict''' ----
  
  Each message is described in the next chapters.
  
  It can be followed by an optionnal control part, which automaton state is  shown below :
  
+ 
+ ---- /!\ '''Edit conflict - other version:''' ----
  attachment:Controls.png
+ 
+ ---- /!\ '''Edit conflict - your version:''' ----
+ attachment:Controls.png
+ 
+ ---- /!\ '''End of edit conflict''' ----
  
  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, +313 @@

  
  Many Ldap``Message while return a result. A specific sub-diagram is dedicated to this Ldap``Result
:
  
+ 
+ ---- /!\ '''Edit conflict - other version:''' ----
  attachment:LdapResult.png
+ 
+ ---- /!\ '''Edit conflict - your version:''' ----
+ attachment:LdapResult.png
+ 
+ ---- /!\ '''End of edit conflict''' ----
  
  We have a specific Grammar to process this LdapResult.
  
@@ -300, +328 @@

  
  The Bind``Request Ldap Message state diagram is shown below :
  
+ 
+ ---- /!\ '''Edit conflict - other version:''' ----
  attachment:BindRequest.png
+ 
+ ---- /!\ '''Edit conflict - your version:''' ----
+ attachment:BindRequest.png
+ 
+ ---- /!\ '''End of edit conflict''' ----
  
  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, +349 @@

  
  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 :
  
+ 
+ ---- /!\ '''Edit conflict - other version:''' ----
  attachment:BindResponse.png
+ 
+ ---- /!\ '''Edit conflict - your version:''' ----
+ attachment:BindResponse.png
+ 
+ ---- /!\ '''End of edit conflict''' ----
  
  === UnBindRequest ===
  
  This is the simplest automate! It is fully described in the protocol``OP schema.
  
+ 
+ ---- /!\ '''Edit conflict - other version:''' ----
  attachment:UnBindRequest.png
+ 
+ ---- /!\ '''Edit conflict - your version:''' ----
+ attachment:UnBindRequest.png
+ 
+ ---- /!\ '''End of edit conflict''' ----
  
  === AbandonRequest  ===
  
@@ -328, +377 @@

  
  This request just send the Message id which has to be stopped.
  
+ 
+ ---- /!\ '''Edit conflict - other version:''' ----
  attachment:AbandonRequest.png
+ 
+ ---- /!\ '''Edit conflict - your version:''' ----
+ attachment:AbandonRequest.png
+ 
+ ---- /!\ '''End of edit conflict''' ----
  
  === 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
:
  
+ 
+ ---- /!\ '''Edit conflict - other version:''' ----
  attachment:SearchRequest.png
  
  attachment:Filter.png
@@ -342, +400 @@

  
  attachment:MatchingRuleAssertion.png
  
+ ---- /!\ '''Edit conflict - your version:''' ----
+ attachment:SearchRequest.png
+ 
+ attachment:Filter.png
+ 
+ attachment:SubstringFilter.png
+ 
+ attachment:MatchingRuleAssertion.png
+ 
+ ---- /!\ '''End of edit conflict''' ----
+ 
  === 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.
  
+ 
+ ---- /!\ '''Edit conflict - other version:''' ----
  attachment:SearchResultEntry.png
  
  attachment:SearchResultReference.png
  
  attachment:SearchResultDone.png
  
+ ---- /!\ '''Edit conflict - your version:''' ----
+ attachment:SearchResultEntry.png
+ 
+ attachment:SearchResultReference.png
+ 
+ attachment:SearchResultDone.png
+ 
+ ---- /!\ '''End of edit conflict''' ----
+ 
  === Add ===
  
  We can add an entry. Here is the message to send, and the response you get :
  
+ 
+ ---- /!\ '''Edit conflict - other version:''' ----
  attachment:AddRequest.png
  
  attachment:AddResponse.png
+ 
+ ---- /!\ '''Edit conflict - your version:''' ----
+ attachment:AddRequest.png
+ 
+ attachment:AddResponse.png
+ 
+ ---- /!\ '''End of edit conflict''' ----
  
  === Del ===
  
  We can delete an entry. Here is the message to send, and the response you get :
  
+ 
+ ---- /!\ '''Edit conflict - other version:''' ----
  attachment:DelRequest.png
  
  attachment:DelResponse.png
+ 
+ ---- /!\ '''Edit conflict - your version:''' ----
+ attachment:DelRequest.png
+ 
+ attachment:DelResponse.png
+ 
+ ---- /!\ '''End of edit conflict''' ----
  
  === Modify ===
  
  We can modify an entry. Here is the message to send, and the response you get :
  
+ 
+ ---- /!\ '''Edit conflict - other version:''' ----
  attachment:ModifyRequest.png
  
  attachment:ModifyResponse.png
+ 
+ ---- /!\ '''Edit conflict - your version:''' ----
+ attachment:ModifyRequest.png
+ 
+ attachment:ModifyResponse.png
+ 
+ ---- /!\ '''End of edit conflict''' ----
  
  === Modify DN ===
  
  We can modify a DN. Here is the message to send, and the response you get :
  
+ 
+ ---- /!\ '''Edit conflict - other version:''' ----
  attachment:ModifyDNRequest.png
  
  attachment:ModifyDNResponse.png
+ 
+ ---- /!\ '''Edit conflict - your version:''' ----
+ attachment:ModifyDNRequest.png
+ 
+ attachment:ModifyDNResponse.png
+ 
+ ---- /!\ '''End of edit conflict''' ----
  
  === Extended message ===
  
  Otherwise, as LDAP accepts extension, it does through those two messages :
  
+ 
+ ---- /!\ '''Edit conflict - other version:''' ----
  attachment:ExtendedRequest.png
  
  attachment:ExtendedResponse.png
  
+ ---- /!\ '''Edit conflict - your version:''' ----
+ attachment:ExtendedRequest.png
+ 
+ attachment:ExtendedResponse.png
+ 
+ ---- /!\ '''End of edit conflict''' ----
+ 

Mime
View raw message