corda/docs/source/setting-up-a-corda-network.rst

84 lines
3.9 KiB
ReStructuredText
Raw Normal View History

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
========================
2016-11-21 16:39:46 +00:00
2016-11-29 11:36:42 +00:00
A Corda network consists of a number of machines running nodes, including a single node operating as the network map
service. 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
---------------------------
2016-11-21 16:39:46 +00:00
Certificates
~~~~~~~~~~~~
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
~~~~~~~~~~~~~
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:
* ``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.
* ``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.
* ``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
~~~~~~~~~~~~~~~~~~
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
~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~
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.