2016-11-22 18:10:50 +00:00
.. _log4j2: http://logging.apache.org/log4j/2.x/
2016-11-21 16:39:46 +00:00
2017-06-05 12:37:23 +00:00
Creating a Corda network
2017-01-06 11:05:37 +00:00
========================
2016-11-21 16:39:46 +00:00
2017-11-01 14:25:48 +00:00
A Corda network consists of a number of machines running nodes. These nodes communicate using persistent protocols in order to create and validate transactions.
2016-11-21 16:39:46 +00:00
2016-11-29 11:36:42 +00:00
There are four broader categories of functionality one such node may have. These pieces of functionality are provided as
services, and one node may run several of them.
2016-11-21 16:39:46 +00:00
2016-11-22 18:10:50 +00:00
* Network map: The node running the network map provides a way to resolve identities to physical node addresses and associated public keys.
2016-11-21 16:39:46 +00:00
* Notary: Nodes running a notary service witness state spends and have the final say in whether a transaction is a double-spend or not.
2016-11-22 18:10:50 +00:00
* Oracle: Network services that link the ledger to the outside world by providing facts that affect the validity of transactions.
2016-11-21 16:39:46 +00:00
* Regular node: All nodes have a vault and may start protocols communicating with other nodes, notaries and oracles and evolve their private ledger.
Setting up your own network
2017-01-06 11:05:37 +00:00
---------------------------
2016-11-21 16:39:46 +00:00
Certificates
2017-01-06 11:05:37 +00:00
~~~~~~~~~~~~
2016-11-21 16:39:46 +00:00
2016-11-07 14:30:40 +00:00
All nodes belonging to the same Corda network must have the same root CA. For testing purposes you can
use `` certSigningRequestUtility.jar `` to generate a node certificate with a fixed test root:
2016-11-21 16:39:46 +00:00
.. sourcecode :: bash
# Build the jars
./gradlew buildCordaJAR
# Generate certificate
java -jar build/libs/certSigningRequestUtility.jar --base-dir NODE_DIRECTORY/
Configuration
2017-01-06 11:05:37 +00:00
~~~~~~~~~~~~~
2016-11-21 16:39:46 +00:00
2016-11-29 11:36:42 +00:00
A node can be configured by adding/editing `` node.conf `` in the node's directory. For details see :doc: `corda-configuration-file` .
2016-11-21 16:39:46 +00:00
An example configuration:
.. literalinclude :: example-code/src/main/resources/example-node.conf
:language: cfg
The most important fields regarding network configuration are:
2017-03-17 10:32:14 +00:00
* `` p2pAddress `` : This specifies a host and port to which Artemis will bind for messaging with other nodes. Note that the
address bound will **NOT** be `` my-corda-node `` , but rather `` :: `` (all addresses on all network interfaces). The hostname specified
is the hostname *that must be externally resolvable by other nodes in the network* . In the above configuration this is the
resolvable name of a machine in a VPN.
* `` rpcAddress `` : The address to which Artemis will bind for RPC calls.
2017-03-21 13:45:18 +00:00
* `` webAddress `` : The address the webserver should bind. Note that the port must be distinct from that of `` p2pAddress `` and `` rpcAddress `` if they are on the same machine.
2016-12-22 14:48:27 +00:00
* `` networkMapService `` : Details of the node running the network map service. If it's this node that's running the service
then this field must not be specified.
2016-11-21 16:39:46 +00:00
Starting the nodes
2017-01-06 11:05:37 +00:00
~~~~~~~~~~~~~~~~~~
2016-11-21 16:39:46 +00:00
2016-11-22 18:10:50 +00:00
You may now start the nodes in any order. Note that the node is not fully started until it has successfully registered with the network map!
You should see a banner, some log lines and eventually `` Node started up and registered `` , indicating that the node is fully started.
2016-11-29 11:36:42 +00:00
.. TODO: Add a better way of polling for startup. A programmatic way of determining whether a node is up is to check whether it's ``webAddress`` is bound.
2016-11-22 18:10:50 +00:00
2017-01-30 11:15:23 +00:00
In terms of process management there is no prescribed method. You may start the jars by hand or perhaps use systemd and friends.
2016-11-22 18:10:50 +00:00
Logging
2017-01-06 11:05:37 +00:00
~~~~~~~
2016-11-22 18:10:50 +00:00
Only a handful of important lines are printed to the console. For
details/diagnosing problems check the logs.
2016-11-21 16:39:46 +00:00
2016-11-22 18:10:50 +00:00
Logging is standard log4j2_ and may be configured accordingly. Logs
are by default redirected to files in `` NODE_DIRECTORY/logs/ `` .
2016-11-21 16:39:46 +00:00
Connecting to the nodes
2017-01-06 11:05:37 +00:00
~~~~~~~~~~~~~~~~~~~~~~~
2016-11-21 16:39:46 +00:00
2016-11-29 11:36:42 +00:00
Once a node has started up successfully you may connect to it as a client to initiate protocols/query state etc.
Depending on your network setup you may need to tunnel to do this remotely.
2016-11-21 16:39:46 +00:00
2016-11-22 18:10:50 +00:00
See the :doc: `tutorial-clientrpc-api` on how to establish an RPC link.
2016-11-21 16:39:46 +00:00
Sidenote: A client is always associated with a single node with a single identity, which only sees their part of the ledger.