mirror of
https://github.com/corda/corda.git
synced 2024-12-22 22:32:26 +00:00
403 lines
21 KiB
HTML
403 lines
21 KiB
HTML
<!-- If you edit this, then please make the same changes to layout_for_doc_website.html, as that is used for the web
|
|
doc site generation which we put analytics tracking on to identify any potential problem pages -->
|
|
|
|
|
|
|
|
|
|
<!DOCTYPE html>
|
|
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
|
|
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
|
|
<head>
|
|
<meta charset="utf-8">
|
|
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
|
|
|
<title>Networking and messaging — R3 Corda latest documentation</title>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<link rel="stylesheet" href="_static/css/custom.css" type="text/css" />
|
|
|
|
|
|
|
|
|
|
|
|
<link rel="top" title="R3 Corda latest documentation" href="index.html"/>
|
|
<link rel="next" title="Persistence" href="persistence.html"/>
|
|
<link rel="prev" title="Client RPC" href="clientrpc.html"/>
|
|
|
|
|
|
<script src="_static/js/modernizr.min.js"></script>
|
|
|
|
</head>
|
|
|
|
<body class="wy-body-for-nav" role="document">
|
|
|
|
<div class="wy-grid-for-nav">
|
|
|
|
|
|
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
|
|
<div class="wy-side-scroll">
|
|
<div class="wy-side-nav-search">
|
|
|
|
|
|
|
|
|
|
<a href="index.html" class="icon icon-home"> R3 Corda
|
|
|
|
|
|
|
|
</a>
|
|
|
|
|
|
|
|
|
|
<div class="version">
|
|
latest
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<div role="search">
|
|
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
|
|
<input type="text" name="q" placeholder="Search docs" />
|
|
<input type="hidden" name="check_keywords" value="yes" />
|
|
<input type="hidden" name="area" value="default" />
|
|
</form>
|
|
</div>
|
|
|
|
|
|
<br>
|
|
API reference: <a href="api/kotlin/corda/index.html">Kotlin</a>/ <a href="api/javadoc/index.html">JavaDoc</a>
|
|
<br>
|
|
<a href="https://discourse.corda.net">Discourse Forums</a>
|
|
<br>
|
|
<a href="http://slack.corda.net">Slack</a>
|
|
<br>
|
|
|
|
</div>
|
|
|
|
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
|
|
|
|
|
|
|
|
<p class="caption"><span class="caption-text">Getting started</span></p>
|
|
<ul>
|
|
<li class="toctree-l1"><a class="reference internal" href="inthebox.html">What’s included?</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="getting-set-up.html">Getting set up</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="getting-set-up-fault-finding.html">Troubleshooting</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="running-the-demos.html">Running the demos</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="CLI-vs-IDE.html">CLI vs IDE</a></li>
|
|
</ul>
|
|
<p class="caption"><span class="caption-text">Key concepts</span></p>
|
|
<ul>
|
|
<li class="toctree-l1"><a class="reference internal" href="data-model.html">Data model</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="transaction-data-types.html">Data types</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="merkle-trees.html">Transaction tear-offs</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="consensus.html">Consensus model</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="clauses.html">Clauses</a></li>
|
|
</ul>
|
|
<p class="caption"><span class="caption-text">CorDapps</span></p>
|
|
<ul>
|
|
<li class="toctree-l1"><a class="reference internal" href="creating-a-cordapp.html">CorDapp basics</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="tutorial-cordapp.html">The CorDapp template</a></li>
|
|
</ul>
|
|
<p class="caption"><span class="caption-text">The Corda node</span></p>
|
|
<ul class="current">
|
|
<li class="toctree-l1"><a class="reference internal" href="clientrpc.html">Client RPC</a></li>
|
|
<li class="toctree-l1 current"><a class="current reference internal" href="#">Networking and messaging</a><ul>
|
|
<li class="toctree-l2"><a class="reference internal" href="#network-map-service">Network Map Service</a></li>
|
|
<li class="toctree-l2"><a class="reference internal" href="#message-queues">Message queues</a></li>
|
|
<li class="toctree-l2"><a class="reference internal" href="#security">Security</a></li>
|
|
<li class="toctree-l2"><a class="reference internal" href="#messaging-types">Messaging types</a></li>
|
|
</ul>
|
|
</li>
|
|
<li class="toctree-l1"><a class="reference internal" href="persistence.html">Persistence</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="node-administration.html">Node administration</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="corda-configuration-file.html">Node configuration</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="corda-plugins.html">The Corda plugin framework</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="node-services.html">Brief introduction to the node services</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="node-explorer.html">Node Explorer</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="permissioning.html">Network permissioning</a></li>
|
|
</ul>
|
|
<p class="caption"><span class="caption-text">Tutorials</span></p>
|
|
<ul>
|
|
<li class="toctree-l1"><a class="reference internal" href="tutorial-contract.html">Writing a contract</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="tutorial-contract-clauses.html">Writing a contract using clauses</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="tutorial-test-dsl.html">Writing a contract test</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="tutorial-integration-testing.html">Integration testing</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="tutorial-clientrpc-api.html">Client RPC API tutorial</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="tutorial-building-transactions.html">Building transactions</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="flow-state-machines.html">Writing flows</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="flow-testing.html">Writing flow tests</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="running-a-notary.html">Running a notary service</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="using-a-notary.html">Using a notary service</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="oracles.html">Writing oracle services</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="tutorial-attachments.html">Using attachments</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="event-scheduling.html">Event scheduling</a></li>
|
|
</ul>
|
|
<p class="caption"><span class="caption-text">Other</span></p>
|
|
<ul>
|
|
<li class="toctree-l1"><a class="reference internal" href="network-simulator.html">Network Simulator</a></li>
|
|
</ul>
|
|
<p class="caption"><span class="caption-text">Component library</span></p>
|
|
<ul>
|
|
<li class="toctree-l1"><a class="reference internal" href="contract-catalogue.html">Contract catalogue</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="contract-irs.html">Interest rate swaps</a></li>
|
|
</ul>
|
|
<p class="caption"><span class="caption-text">Appendix</span></p>
|
|
<ul>
|
|
<li class="toctree-l1"><a class="reference internal" href="loadtesting.html">Load testing</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="setting-up-a-corda-network.html">What is a corda network?</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="secure-coding-guidelines.html">Secure coding guidelines</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="release-process.html">Release process</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="release-notes.html">Release notes</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="codestyle.html">Code style guide</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="building-the-docs.html">Building the documentation</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="publishing-corda.html">Publishing Corda</a></li>
|
|
<li class="toctree-l1"><a class="reference internal" href="azure-vm.html">Working with the Corda Demo on Azure Marketplace</a></li>
|
|
</ul>
|
|
<p class="caption"><span class="caption-text">Glossary</span></p>
|
|
<ul>
|
|
<li class="toctree-l1"><a class="reference internal" href="glossary.html">Glossary</a></li>
|
|
</ul>
|
|
|
|
|
|
|
|
</div>
|
|
</div>
|
|
</nav>
|
|
|
|
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
|
|
|
|
|
|
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
|
|
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
|
|
<a href="index.html">R3 Corda</a>
|
|
</nav>
|
|
|
|
|
|
|
|
<div class="wy-nav-content">
|
|
<div class="rst-content">
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<div role="navigation" aria-label="breadcrumbs navigation">
|
|
<ul class="wy-breadcrumbs">
|
|
<li><a href="index.html">Docs</a> »</li>
|
|
|
|
<li>Networking and messaging</li>
|
|
<li class="wy-breadcrumbs-aside">
|
|
|
|
|
|
<a href="_sources/messaging.txt" rel="nofollow"> View page source</a>
|
|
|
|
|
|
</li>
|
|
</ul>
|
|
<hr/>
|
|
</div>
|
|
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
|
|
<div itemprop="articleBody">
|
|
|
|
<div class="section" id="networking-and-messaging">
|
|
<h1>Networking and messaging<a class="headerlink" href="#networking-and-messaging" title="Permalink to this headline">¶</a></h1>
|
|
<p>Corda uses AMQP/1.0 over TLS between nodes which is currently implemented using Apache Artemis, an embeddable message
|
|
queue broker. Building on established MQ protocols gives us features like persistence to disk, automatic delivery
|
|
retries with backoff and dead-letter routing, security, large message streaming and so on.</p>
|
|
<p>Artemis is hidden behind a thin interface that also has an in-memory only implementation suitable for use in
|
|
unit tests and visualisation tools.</p>
|
|
<div class="admonition note">
|
|
<p class="first admonition-title">Note</p>
|
|
<p class="last">A future version of Corda will allow the MQ broker to be split out of the main node and run as a
|
|
separate server. We may also support non-Artemis implementations via JMS, allowing the broker to be swapped
|
|
out for alternative implementations.</p>
|
|
</div>
|
|
<p>There are multiple ways of interacting with the network. When writing an application you typically won’t use the
|
|
messaging subsystem directly. Instead you will build on top of the <a class="reference internal" href="flow-state-machines.html"><span class="doc">flow framework</span></a>,
|
|
which adds a layer on top of raw messaging to manage multi-step flows and let you think in terms of identities
|
|
rather than specific network endpoints.</p>
|
|
<div class="section" id="network-map-service">
|
|
<span id="id1"></span><h2>Network Map Service<a class="headerlink" href="#network-map-service" title="Permalink to this headline">¶</a></h2>
|
|
<p>Supporting the messaging layer is a network map service, which is responsible for tracking public nodes on the network.</p>
|
|
<p>Nodes have an internal component, the network map cache, which contains a copy of the network map (which is just a
|
|
document). When a node starts up its cache fetches a copy of the full network map, and requests to be notified of
|
|
changes. The node then registers itself with the network map service, and the service notifies subscribers that a new
|
|
node has joined the network. Nodes do not automatically deregister themselves, so (for example) nodes going offline
|
|
briefly for maintenance are retained in the network map, and messages for them will be queued, minimising disruption.</p>
|
|
<p>Nodes submit signed changes to the map service, which then forwards update notifications on to nodes which have
|
|
requested to be notified of changes.</p>
|
|
<p>The network map currently supports:</p>
|
|
<ul class="simple">
|
|
<li>Looking up nodes by service</li>
|
|
<li>Looking up node for a party</li>
|
|
<li>Suggesting a node providing a specific service, based on suitability for a contract and parties, for example suggesting
|
|
an appropriate interest rates oracle for an interest rate swap contract. Currently no recommendation logic is in place.</li>
|
|
</ul>
|
|
</div>
|
|
<div class="section" id="message-queues">
|
|
<h2>Message queues<a class="headerlink" href="#message-queues" title="Permalink to this headline">¶</a></h2>
|
|
<p>The node makes use of various queues for its operation. The more important ones are described below. Others are used
|
|
for maintenance and other minor purposes.</p>
|
|
<table class="docutils field-list" frame="void" rules="none">
|
|
<col class="field-name" />
|
|
<col class="field-body" />
|
|
<tbody valign="top">
|
|
<tr class="field-odd field"><th class="field-name"><code class="docutils literal"><span class="pre">p2p.inbound</span></code>:</th><td class="field-body">The node listens for messages sent from other peer nodes on this queue. Only clients who are authenticated to be
|
|
nodes on the same network are given permission to send. Messages which are routed internally are also sent to this
|
|
queue (e.g. two flows on the same node communicating with each other).</td>
|
|
</tr>
|
|
<tr class="field-even field"><th class="field-name" colspan="2"><code class="docutils literal"><span class="pre">internal.peers.$identity</span></code>:</th></tr>
|
|
<tr class="field-even field"><td> </td><td class="field-body">These are a set of private queues only available to the node which it uses to route messages destined to other peers.
|
|
The queue name ends in the base 58 encoding of the peer’s identity key. There is at most one queue per peer. The broker
|
|
creates a bridge from this queue to the peer’s <code class="docutils literal"><span class="pre">p2p.inbound</span></code> queue, using the network map service to lookup the
|
|
peer’s network address.</td>
|
|
</tr>
|
|
<tr class="field-odd field"><th class="field-name" colspan="2"><code class="docutils literal"><span class="pre">internal.services.$identity</span></code>:</th></tr>
|
|
<tr class="field-odd field"><td> </td><td class="field-body">These are private queues the node may use to route messages to services. The queue name ends in the base 58 encoding
|
|
of the service’s owning identity key. There is at most one queue per service identity (but note that any one service
|
|
may have several identities). The broker creates bridges to all nodes in the network advertising the service in
|
|
question. When a session is initiated with a service counterparty the handshake is pushed onto this queue, and a
|
|
corresponding bridge is used to forward the message to an advertising peer’s p2p queue. Once a peer is picked the
|
|
session continues on as normal.</td>
|
|
</tr>
|
|
<tr class="field-even field"><th class="field-name" colspan="2"><code class="docutils literal"><span class="pre">internal.networkmap</span></code>:</th></tr>
|
|
<tr class="field-even field"><td> </td><td class="field-body">This is another private queue just for the node which functions in a similar manner to the <code class="docutils literal"><span class="pre">internal.peers.*</span></code> queues
|
|
except this is used to form a connection to the network map node. The node running the network map service is treated
|
|
differently as it provides information about the rest of the network.</td>
|
|
</tr>
|
|
<tr class="field-odd field"><th class="field-name"><code class="docutils literal"><span class="pre">rpc.requests</span></code>:</th><td class="field-body">RPC clients send their requests here, and it’s only open for sending by clients authenticated as RPC users.</td>
|
|
</tr>
|
|
<tr class="field-even field"><th class="field-name" colspan="2"><code class="docutils literal"><span class="pre">clients.$user.rpc.$random</span></code>:</th></tr>
|
|
<tr class="field-even field"><td> </td><td class="field-body">RPC clients are given permission to create a temporary queue incorporating their username (<code class="docutils literal"><span class="pre">$user</span></code>) and sole
|
|
permission to receive messages from it. RPC requests are required to include a random number (<code class="docutils literal"><span class="pre">$random</span></code>) from
|
|
which the node is able to construct the queue the user is listening on and send the response to that. This mechanism
|
|
prevents other users from being able listen in on the responses.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
<div class="section" id="security">
|
|
<h2>Security<a class="headerlink" href="#security" title="Permalink to this headline">¶</a></h2>
|
|
<p>Clients attempting to connect to the node’s broker fall in one of four groups:</p>
|
|
<ol class="arabic simple">
|
|
<li>Anyone connecting with the username <code class="docutils literal"><span class="pre">SystemUsers/Node</span></code> is treated as the node hosting the broker, or a logical
|
|
component of the node. The TLS certificate they provide must match the one broker has for the node. If that’s the case
|
|
they are given full access to all valid queues, otherwise they are rejected.</li>
|
|
<li>Anyone connecting with the username <code class="docutils literal"><span class="pre">SystemUsers/Peer</span></code> is treated as a peer on the same Corda network as the node. Their
|
|
TLS root CA must be the same as the node’s root CA - the root CA is the doorman of the network and having the same root CA
|
|
implies we’ve been let in by the same doorman. If they are part of the same network then they are only given permission
|
|
to send to our <code class="docutils literal"><span class="pre">p2p.inbound</span></code> queue, otherwise they are rejected.</li>
|
|
<li>Every other username is treated as a RPC user and authenticated against the node’s list of valid RPC users. If that
|
|
is successful then they are only given sufficient permission to perform RPC, otherwise they are rejected.</li>
|
|
<li>Clients connecting without a username and password are rejected.</li>
|
|
</ol>
|
|
<p>Artemis provides a feature of annotating each received message with the validated user. This allows the node’s messaging
|
|
service to provide authenticated messages to the rest of the system. For the first two client types described above the
|
|
validated user is the X.500 subject DN of the client TLS certificate and we assume the common name is the legal name of
|
|
the peer. This allows the flow framework to authentically determine the <code class="docutils literal"><span class="pre">Party</span></code> initiating a new flow. For RPC clients
|
|
the validated user is the username itself and the RPC framework uses this to determine what permissions the user has.</p>
|
|
<div class="admonition note">
|
|
<p class="first admonition-title">Note</p>
|
|
<p class="last"><code class="docutils literal"><span class="pre">Party</span></code> lookup is currently done by the legal name which isn’t guaranteed to be unique. A future version will
|
|
use the full X.500 name as it can provide additional structures for uniqueness.</p>
|
|
</div>
|
|
<p>The broker also does host verification when connecting to another peer. It checks that the TLS certificate common name
|
|
matches with the advertised legal name from the network map service.</p>
|
|
</div>
|
|
<div class="section" id="messaging-types">
|
|
<h2>Messaging types<a class="headerlink" href="#messaging-types" title="Permalink to this headline">¶</a></h2>
|
|
<p>Every <code class="docutils literal"><span class="pre">Message</span></code> object has an associated <em>topic</em> and may have a <em>session ID</em>. These are wrapped in a <code class="docutils literal"><span class="pre">TopicSession</span></code>.
|
|
An implementation of <code class="docutils literal"><span class="pre">MessagingService</span></code> can be used to create messages and send them. You can get access to the
|
|
messaging service via the <code class="docutils literal"><span class="pre">ServiceHub</span></code> object that is provided to your app. Endpoints on the network are
|
|
identified at the lowest level using <code class="docutils literal"><span class="pre">SingleMessageRecipient</span></code> which may be e.g. an IP address, or in future
|
|
versions perhaps a routing path through the network.</p>
|
|
</div>
|
|
</div>
|
|
|
|
|
|
</div>
|
|
</div>
|
|
<footer>
|
|
|
|
<div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
|
|
|
|
<a href="persistence.html" class="btn btn-neutral float-right" title="Persistence" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
|
|
|
|
|
|
<a href="clientrpc.html" class="btn btn-neutral" title="Client RPC" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
|
|
|
|
</div>
|
|
|
|
|
|
<hr/>
|
|
|
|
<div role="contentinfo">
|
|
<p>
|
|
© Copyright 2016, R3 Limited.
|
|
|
|
</p>
|
|
</div>
|
|
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
|
|
|
|
</footer>
|
|
|
|
</div>
|
|
</div>
|
|
|
|
</section>
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<script type="text/javascript">
|
|
var DOCUMENTATION_OPTIONS = {
|
|
URL_ROOT:'./',
|
|
VERSION:'latest',
|
|
COLLAPSE_INDEX:false,
|
|
FILE_SUFFIX:'.html',
|
|
HAS_SOURCE: true
|
|
};
|
|
</script>
|
|
<script type="text/javascript" src="_static/jquery.js"></script>
|
|
<script type="text/javascript" src="_static/underscore.js"></script>
|
|
<script type="text/javascript" src="_static/doctools.js"></script>
|
|
|
|
|
|
|
|
|
|
|
|
<script type="text/javascript" src="_static/js/theme.js"></script>
|
|
|
|
|
|
|
|
|
|
<script type="text/javascript">
|
|
jQuery(function () {
|
|
SphinxRtdTheme.StickyNav.enable();
|
|
});
|
|
</script>
|
|
|
|
|
|
</body>
|
|
</html> |