git.sur5r.net Git - openldap/blob - servers/slurpd/DESIGN

   1 Design Notes: slurpd
   2
   3 This new version differs significantly from previous versions:
   4
   5 - It uses a multithreaded, single-process model.  Previous versions forked
   6   a separate process for each replica.  This new design should facilitate
   7   porting to NT, and is more straightforward.
   8
   9 - Only one copy of the replication log is made.  Previous versions made
  10 one copy of the replication log for each replica
  11
  12 - This newer version is more object-oriented.  Although still written in
  13   ANSI C (and compilable on k&r compilers), it encapsulates within the
  14   major data structures the methods used to access "private" data.
  15
  16 General design overview:
  17
  18 The main data structure in slurpd is a replication queue (struct rq).
  19 The rq data structure is currently implemented as a linked list of
  20 replication entries (struct re).  The rq structure contains member functions
  21 used to initialize, add to, remove, and return the next re struct.
  22
  23 In addition to the rq structure, there is one ri (replication information)
  24 struct for each replica.  The ri struct encapsulates all information
  25 about a particular replica, e.g. hostname, port, bind dn.  The single
  26 public member function, ri_process, is called to begin processing
  27 the replication entries in the queue.
  28
  29 There is also a status structure (struct st) which contains the timestamp
  30 of the last successful replication operation for each replica.  The
  31 contents of the st struct are flushed to disk after every successful
  32 operation.  This disk file is read upon startup, and is used to allow
  33 slapd to "pick up where it left off".
  34
  35 Threading notes:
  36
  37 The LDAP liblthread quasi-pthreads interface is used for threading.  At
  38 this point, machines which do not support pthreads, sun threads or lwp
  39 will probably not be able to run slurpd.  Given the current threading
  40 method, discussed in the next paragraph, it will probably be necessary to
  41 have a separate hunk of code which handles non-threaded architectures
  42 (or we might just not worry about it).  This needs further discussion.
  43
  44 Upon startup, command-line arguments and the slapd configuration file
  45 are processed.  One thread is started for each replica.  Thread replicas,
  46 when no more work exists, wait on a condition variable, and the main
  47 thread's file manager routine broadcasts on this condition variable
  48 when new work is added to the queue.
  49
  50 Additional notes:
  51         See doc/devel/replication-notes.txt