R3 Corda: 网络和消息 Networking and m
Corda 在 TLS 之上使用 AMQP/1.0 实现节点间的通信，当前是使用 Apache Artemis，一个可嵌入的 message queue broker 来实现的。构建在创建好的 MQ 协议上给了我们诸如持久化到硬盘，带有 backoff 和 dead-letter routing 的自动重试发送，安全和大的消息流等功能。
Artemis 隐藏在一个轻接口（thin interface）后边，这个接口还具有一个只在内存中存储的实现，这个在单元测试（unit tests）和可视化工具（visualisation tools）可以使用。
未来版本的 Corda 将会允许 MQ broker 可以从主节点中分离出来并且像一个独立的 server 那样运行。我们可能也会支持通过 JMS 的 non-Arteis 实现，允许 broker 能够有其他的实现。
这有很多种方式跟网络进行互动。当编写一个应用的时候，你通常不会直接地使用一个消息子系统。你会将它构建在 flow 框架之上，这会在原始消息（raw messaging）之上添加一层来管理多步的 flows 并且让你思考关于身份（identities）而不是某个特定的网络 endpoints。
网络地图服务 Network Map Service
网络地图服务支持了消息层，它负责跟踪网络中的公共节点。
节点具有一个内部的组件，网络地图缓存，它包括了网络地图的一个副本（只是一个文件）。当一个节点启动的时候，它的缓存会获取整个网络地图的一个副本，并且会请求当网络地图有变化的时候被通知。然后节点会将自己注册到网络地图服务中，这个服务会通知所有订阅的节点有个新的节点加入到网络中来。节点不会自动地将自己从注册中移除，所以当节点由于维护等原因离线之后，他们仍旧会在网络地图中存在，发送给他们的消息会被放入队列中，以最小化造成的损坏。
节点会将签过名的变动发送给网络地图服务，然后会被通知给那些之前请求过要被通知的节点。
网络地图服务当前支持：
- 根据服务查询节点
- 查询一个指定的节点
- 基于对一个合约和节点的适合度来建议一个节点提供的指定的服务，比如为一个汇率交换的合约建议一个适当的汇率 Oracle
消息队列 Message Queues
节点运行的时候会使用不同的消息队列。比较重要的都在下边进行了描述。其他的队列会被用来在维护和其他比较小的一些活动中。
p2p.inbound.$identity：节点会在这个消息队列中监听由其他节点发送过来的消息。只有同一网络中已经授权的节点才会有权限发送消息。在内部路由的消息也会发送到这个队列中（比如一个节点中的两个 flows 互相联系）。
internal.peers.$identity：这些是一系列的私有队列，是节点用来向其他节点发送消息的。队列的名字是以 base 58 加密的目标节点的身份密钥的信息作为结尾。这里基本上是每个 peer 节点一个队列。Broker 会通过网络地图服务来查找 peer 节点的网络地址，然后跟对方节点的 p2p.inbound.$identity 队列建立一个桥连接（bridge）。
internal.services.$identity：这些是节点可能会用来向服务（services）发送消息的私有队列。队列的名字是以 base 58 加密的服务的身份密钥的信息作为结尾。这里每个服务标识（identity）最多是一个队列（但是要注意的是一个服务可能会有多个标识）。Broker 会跟所有的网络中提供服务的节点创建桥连接（bridges）。当跟服务合作方建立一个回话之后，handshake 会被发送到这个队列中来，并且一个对应的桥连接会被用来将消息转发给目标节点的 p2p 队列。当一个 peer 被选择之后，会话将会正常进行。
rpc.requests：RPC 客户端通过该队列发送请求，这个队列也仅仅对被授权为 RPC 用户的客户端才可以访问。
clients.$user.rpc.$random：RPC 客户端被授权使用他们的用户名（$user）来创建一个临时的队列，并有权利从这个都列中接收消息。RPC 请求必须要包含一个随机数（random），通过它节点可以构建用户可以监听并且可以向其发送反馈的队列。这个机制能够避免其他的用户能够监听反馈。
安全 Security
客户端尝试连接节点的 broker 会出自四个 groups 之一：
- 任何使用用户名
SystemUsers/Node连接的被认为是运行着 broker 的节点，或者是节点的一个逻辑组件（logical component）。他们所提供的 TLS 证书必须要跟 broker 对于该节点的证书匹配。如果匹配上的话，那么他们会被授权访问所有可用的队列，否则的话会被拒绝访问。 - 任何使用用户名
SystemUsers/Peer连接的被认为是在同一 Corda 网络中的 peer 节点。他们的 TLS root CA 必须同节点的 root CA 相同。Root CA 是网络的 doorman，并且具有相同的 root CA 意味着我们是被相同的 doorman 准入进入到此网络的。如果他们是同一网络的组成节点，那么他们仅仅被授权向我们的p2p.inbound.$identity队列发送消息，否则的话会被拒绝。 - 任何其他的用户名会被认为是一个 RPC 用户，会根据节点的有效的 RPC 用户列表来进行授权。如果授权成功，那么他们仅仅会给与有效的权力来执行 RPC，否则会被拒绝。
- 没有用户名和密码的客户端会被拒绝。
Artemis 提供了一个功能，为每一个收到的消息田间有效的用户的注解（annotating）。这个允许节点的消息服务为系统的其他部分提供被授权的消息。对于上边提到的前两种客户端类型，被验证的用户是客户端的 TLS 证书的 X.500 subject。这个允许 flow 框架来判断初始一个新 flow 的 Party 的权限。对于 RPC 客户端，被验证的用户是指用户名本身，RPC 框架用这个来决定这个用户应该有什么权限。
当连接其他 peer 的时候，broker 也会进行验证。他会检查 TLS 证书 subject 同网络地图服务中记录的 X.500 legal name 相匹配。
