Proficient in IPFS: IPFS boot preStart function

1. Execute the first function, call the get method of the repository configuration object, and get the configuration system configuration. The specific code is as follows:

    (cb) => self._repo.config.get(cb) 

   We know that the configuration object of the repository is generated in the constructor of the repository and is set in the initialization method init . Now let's take a closer look at the configuration object. This object is created with the root of the repository object as its parameters. All its operations are ultimately called by the object, which is saved in the configuration file of the file system. Then the contents of the configuration file are written. The answer is the init method of the repository. In this method, the configuration method of the same name is called to save all configurations. There is still a problem here is where the specific configuration is defined. This problem is also relatively simple. In the previous system initialization, ie the IPFS init method, the mergeOptions method was called to merge the default configuration and the configuration specified by the user through config . This method can find all the default configuration definitions in the core/runtime/config-node.js file, from this file you can find the default configuration is as follows:

    {  Addresses: {    Swarm: [      '/ip4/0.0.0.0/tcp/4002',      '/ip4/127.0.0.1/tcp/4003/ws'    ],    API: '/ip4/127.0.0.1/tcp/5002',    Gateway: '/ip4/127.0.0.1/tcp/9090'  },  Discovery: {    MDNS: {      Enabled: true,      Interval: 10    },    webRTCStar: {      Enabled: true    }  },  Bootstrap: [    '/ip4/104.236.176.52/tcp/4001/ipfs/QmSoLnSGccFuZQJzRadHn95W2CrSFmZuTdDWP8HXaHca9z',    '/ip4/104.131.131.82/tcp/4001/ipfs/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ',    '/ip4/104.236.179.241/tcp/4001/ipfs/QmSoLPppuBtQSGwKDZT2M73ULpjvfd3aZ6ha4oFGL1KrGM',    '/ip4/162.243.248.213/tcp/4001/ipfs/QmSoLueR4xBeUbY9WZ9xGUUxunbKWcrNFTDAadQJmocnWm',    '/ip4/128.199.219.111/tcp/4001/ipfs/QmSoLSafTMBsPKadTEgaXctDQVcqN88CNLHXMkTNwMKPnu',    '/ip4/104.236.76.40/tcp/4001/ipfs/QmSoLV4Bbm51jM9C4gDYZQ9Cy3U6aXMJDAbzgu2fzaDs64',    '/ip4/178.62.158.247/tcp/4001/ipfs/QmSoLer265NRgSp2LA3dPaeykiS1J6DifTC88f5uVQKNAd',    '/ip4/178.62.61.185/tcp/4001/ipfs/QmSoLMeWqB7YGVLJN3pNLQpmmEk35v6wYtsMGLzSr5QBU3',    '/ip4/104.236.151.122/tcp/4001/ipfs/QmSoLju6m7xTh3DuokvT3886QRYqxAzb1kShaanJgW36yx',    '/ip6/2604:a880:1:20::1f9:9001/tcp/4001/ipfs/QmSoLnSGccFuZQJzRadHn95W2CrSFmZuTdDWP8HXaHca9z',    '/ip6/2604:a880:1:20::203:d001/tcp/4001/ipfs/QmSoLPppuBtQSGwKDZT2M73ULpjvfd3aZ6ha4oFGL1KrGM',    '/ip6/2604:a880:0:1010::23:d001/tcp/4001/ipfs/QmSoLueR4xBeUbY9WZ9xGUUxunbKWcrNFTDAadQJmocnWm',    '/ip6/2400:6180:0:d0::151:6001/tcp/4001/ipfs/QmSoLSafTMBsPKadTEgaXctDQVcqN88CNLHXMkTNwMKPnu',    '/ip6/2604:a880:800:10::4a:5001/tcp/4001/ipfs/QmSoLV4Bbm51jM9C4gDYZQ9Cy3U6aXMJDAbzgu2fzaDs64',    '/ip6/2a03:b0c0:0:1010::23:1001/tcp/4001/ipfs/QmSoLer265NRgSp2LA3dPaeykiS1J6DifTC88f5uVQKNAd',    '/ip6/2a03:b0c0:1:d0::e7:1/tcp/4001/ipfs/QmSoLMeWqB7YGVLJN3pNLQpmmEk35v6wYtsMGLzSr5QBU3',    '/ip6/2604:a880:1:20::1d9:6001/tcp/4001/ipfs/QmSoLju6m7xTh3DuokvT3886QRYqxAzb1kShaanJgW36yx',    '/dns4/node0.preload.ipfs.io/tcp/443/wss/ipfs/QmZMxNdpMkewiVZLMRxaNxUeZpDUb34pWjZ1kZvsd16Zic',    '/dns4/node1.preload.ipfs.io/tcp/443/wss/ipfs/Qmbut9Ywz9YEDrz8ySBSgWyJk41Uvm2QJPhwDJzJyGFsD6'  ],  Swarm: {    ConnMgr: {      LowWater: 200,      HighWater: 500    }  } } 

   In addition to the system-defined default configuration and user-specified configuration, the node-related information, such as the node ID and node private key, is also saved in the Identity property of the configuration object when creating the node. In addition to the above configurations, In the initialization method of the warehouse, the user-specified datastore and the system default data storage configuration are merged by the buildConfig method. The default data storage configuration in the default-datastore.js file of the ipfs-repo project is as follows:

    {  Spec: {    type: 'mount',    mounts: [      {        mountpoint: '/blocks',        type: 'measure',        prefix: 'flatfs.datastore',        child: {          type: 'flatfs',          path: 'blocks',          sync: true,          shardFunc: '/repo/flatfs/shard/v1/next-to-last/2'        }      },      {        mountpoint: '/',        type: 'measure',        prefix: 'leveldb.datastore',        child: {          type: 'levelds',          path: 'datastore',          compression: 'none'        }      }    ]  } } 

   In summary, the configuration of the system comes from the previous places. These configurations are finally saved to the configuration file by the set method of the init method of the repository. Then the get method that calls the configuration object here reads these configurations.

2. Execute the second function to handle the system configuration. Read all the settings set during system initialization in the first function. If the user does not specify any configuration in the options, then use the default configuration directly; otherwise, call the mergeOptions method to merge the default configuration with the user-specified configuration, then Call the replace method of the config component of the IPFS object to save the merged configuration to the configuration object of the repository object. The code for the above logic is as follows:

      (config, cb) => {    if (!self._options.config) {      return cb(null, config)    }    config = mergeOptions(config, self._options.config)    self.config.replace(config, (err) => {      if (err) {        return cb(err)      }      cb(null, config)    })  } 

3. Execute the third function to check if there is a Keychain configuration. If there is already a Keychain in the configuration, the fourth function is executed, otherwise it is generated and saved in the configuration object. The code for the above logic is as follows:

      (config, cb) => {    if (config.Keychain) {      return cb(null, config)    }    config.Keychain = Keychain.generateOptions()    self.config.set('Keychain', config.Keychain, (err) => {      self.log('using default keychain options')      cb(err, config)    })  } 

4. Execute the fourth function to check if the IPFS object has a Keychain . The specific code is relatively simple, the code is as follows:

      (config, cb) => {    if (self._keychain) {    } else if (pass) {      const keychainOptions = Object.assign({ passPhrase: pass }, config.Keychain)      self._keychain = new Keychain(self._repo.keys, keychainOptions)    } else {      self._keychain = new NoKeychain()    }    cb(null, config)  } 

5. The fifth function is executed to generate a node ID according to the node information in the configuration information. The same is relatively simple, the code is as follows:

      (config, cb) => {    const privKey = config.Identity.PrivKey 

    peerId.createFromPrivKey(privKey, (err, id) => {  cb(err, config, id) }) 

      } 

6. Executing the sixth function, the code to import the private key is also relatively simple, as follows:

      (config, id, cb) => {    if (!pass) {      return cb(null, config, id)    }    self._keychain.findKeyByName('self', (err) => {      if (err) {        return self._keychain.importPeer('self', id, (err) => cb(err, config, id))      }      cb(null, config, id)    })  } 

7. Execute the seventh function to populate the node's multiaddr information. The code is as follows, I will understand it at a glance, not to elaborate:

      (config, id, cb) => {    self.log('peer created')    self._peerInfo = new PeerInfo(id)    if (config.Addresses && config.Addresses.Swarm) {      config.Addresses.Swarm.forEach((addr) => {        let ma = multiaddr(addr)        if (ma.getPeerId()) {          ma = ma.encapsulate('/ipfs/' + self._peerInfo.id.toB58String())        }        self._peerInfo.multiaddrs.add(ma)      })    }    cb()  } 

8. Execute the last function to load the files and directories that have been pinned. The code is as follows, and I will talk about the pin later.

    (cb) => self.pin._load(cb) 

At this point, when the preStart function is executed, the start function is executed. The contents of this function are left for analysis next time.