ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2024-12-24 07:06:44 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merged in rnicoll-docs-nms-fix (pull request #77)

Browse Source 
Complete sentence on why nodes are not removed from network map automatically
This commit is contained in:
Ross Nicoll 2016-04-29 17:05:48 +01:00
commit 662d0f1494
3 changed files with 6 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
docs/build/html/_sources/messaging.txt vendored
View File

@ -101,7 +101,8 @@ Supporting the messaging layer is a network map service, which is responsible fo
Nodes have an internal component, the network map cache, which contains a copy of the network map. 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 far (for example) nodes going offline briefly for maintenance
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.
Nodes submit signed changes to the map service, which then forwards them on to nodes which have requested to be notified
of changes. This process achieves basic consensus of the overall network map, although currently it has no formal

3
docs/build/html/messaging.html vendored
View File

@ -245,7 +245,8 @@ nodes run in parallel, just as they would on a real network spread over multiple
Nodes have an internal component, the network map cache, which contains a copy of the network map. 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 far (for example) nodes going offline briefly for maintenance</p>
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 them on to nodes which have requested to be notified
of changes. This process achieves basic consensus of the overall network map, although currently it has no formal
process for identifying or recovering from issues such as network outages. Later versions are planned to address this.</p>

3
docs/source/messaging.rst
View File

@ -101,7 +101,8 @@ Supporting the messaging layer is a network map service, which is responsible fo
Nodes have an internal component, the network map cache, which contains a copy of the network map. 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 far (for example) nodes going offline briefly for maintenance
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.
Nodes submit signed changes to the map service, which then forwards them on to nodes which have requested to be notified
of changes. This process achieves basic consensus of the overall network map, although currently it has no formal