Subsections

• 4.1 Provider Id
• 4.2 MAC Address
• 4.3 Member list
• 4.4 Agreement Manager

---

4 Required Elements

Basic bootstrapping requires the presence of a few mandatory elements in the prefs file. These are documented below:

4.1 Provider Id

There are two ways to specify the provider id:

1. Hardwire a GUID directly (all our products like CVS Replicator use this form):

    <ProviderDescriptor>
        <DefaultProviderId>3bfbf219-2918-11d7-80c5-00065be02953</DefaultProviderId>
      </ProviderDescriptor>
   

2. Use Programmatic API:

     <ProviderDescriptor>
       <DefaultProviderIdHookClass>A.Class.For.ProviderIdHook</DefaultProviderIdHookClass>
     </ProviderDescriptor>
   

   This class needs to implement the interface org.nirala.util.DefaultProviderIdHook that specifies:

   public interface DefaultProviderIdHook {
     public String getIdString();
     public IGUID  getID();
   }
   

4.2 MAC Address

The built-in GUID generator needs to bootstrap itself using an Ethernet MAC address. This enhances the uniqueness of the GUIDs and reduces the odds of the same GUID being generated by two different machines. Most of our sample prefs files ship with a default MAC Address. Please change it as soon as possible. The syntax is:

 <org>
    <nirala>
      <util>
        <guid>
          <MACAddress>00:06:5B:E0:29:53</MACAddress>
        </guid>
      </util>
    </nirala>
 </org>

You can easily determine your MAC address by running ifconfig -a on UNIX or ipconfig /all on Win32.

4.3 Member list

Since DCone is used in a distributed setting, to do anything useful, one needs to specify an initial membership. This is the initial set of members that are part of the distributed system. For example in case of CVS Replicator this is the list of all the replicas. Using our group evolution feature it is possible to dynamically adjust this initial membership.

Here is an XML snippet:

  <MemberList>
    <Member name="3bfbf219-2918-11d7-80c5-00065be02953">
      <Profiles>
        <TransportPolicy>AlwaysDConeNet`w</TransportPolicy>
        <Transport>
          <DConeNet>
            <ListenerIP>sanfranciso-replicator</ListenerIP>
            <ListenerPort>6020</ListenerPort>
          </DConeNet>
        </Transport>
      </Profiles>
    </Member>

    <Member name="c9bcec19-4301-11d9-b12d-080020b0d8b8">
      <Profiles>
        <TransportPolicy>AlwaysDConeNet</TransportPolicy>
        <Transport>
          <DConeNet>
            <ListenerIP>bangalore-replicator</ListenerIP>
            <ListenerPort>6020</ListenerPort>
          </DConeNet>
        </Transport>
      </Profiles>
    </Member>

  </MemberList>

For each member (including the self node) we have specified:

• Member name using a GUID.
• For each member, the associated Profiles.
  • The TransportPolciy profile specifies the default transport this member prefers when a node needs to communicate with it.
  • Transport Endpoints for communication. In the above example, we have specified DConeNet binary protocol for communication as well as the listener IP address and port. Multiple transports can be specified, as we will see in the transport prefs.

Please specify the Member element for each initial member of the distributed system.

4.4 Agreement Manager

A Distributed Agreement Manager accepts proposals from the application, and inserts them into a global sequence. This is the fundamental concept behind our SDK. For further information please read our Introduction to DCone guide.

Some applications, such as CVS Replicator, only use a single agreement manager. In general, applications can use as many agreement managers as they require. DCone is designed to scale to multiple agreement managers. For example a Distributed File System application may choose to use one agreement manager per directory.

All the members that are part of a distributed system, must specify common agreement managers in their individual prefs file. It is also possible to specify agreement managers using our programmatic API.

Each agreement manager essentially represents a replicated state machine. Submitted proposals are turned into globally sequenced agreements by the agreement manager.

Syntax:

 <AgreementManagerList>
    <AgreementManager name="6e49ad70-10d9-11d9-af41-00065be02953">
      <DisplayName>DFS-Dir1</DisplayName>
    </AgreementManager>
    ....
    <AgreementManager name="3e40ad70-10d9-a1d9-ef45-00065be02953">
      <DisplayName>DFS-Dir2</DisplayName>
    </AgreementManager>

  </AgreementManagerList>

The AgreementManagerList is the root element of this tree. It contains multiple AgreementManager instances, each identified using a GUID. An optional DisplayName can be associated for documentation.

Some products, like CVS Replicator, already have an agreement manager specified in the shipped prefs.xml file. There is typically no need to change that, unless you start deploying multiple instances of the CVS Replicator product.