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

87 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
Introduction - What is a corda network?
2016-11-29 11:36:42 +00:00
=======================================
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
===========================
Certificates
------------
2016-11-22 18:10:50 +00:00
If two nodes are to communicate successfully then both need to have
each other's root certificate in their truststores. The simplest way
to achieve this is to have all nodes sign off of a single root.
Later R3 will provide this root for production use, but for testing 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-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:
2016-11-29 11:36:42 +00:00
* ``artemisAddress``: This specifies a host and port. Note that the address bound will **NOT** be ``my-corda-node``,
but rather ``::`` (all addresses on all 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.
2016-11-21 16:39:46 +00:00
* ``webAddress``: The address the webserver should bind. Note that the port should be distinct from that of ``artemisAddress``.
2016-11-29 11:36:42 +00:00
* ``networkMapAddress``: The resolvable name and artemis port of the network map node. Note that if this node itself
is to be the network map this field should not be specified.
2016-11-21 16:39:46 +00:00
Starting the nodes
------------------
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
In terms of process management there is no prescribed method. You may start the jars by hand or perhaps use systemd and friends.
Logging
-------
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-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.