Rust Peering Accounts - Defining Peer Actions

Implementations and SDKs
1

&rust.clonetheworld() :star_struck:

Ok so I am now at the point where I have multiple ILP nodes running in the same subnet. I can make as many as I want :sunglasses: .

My next step is to make them aware of each other. I would take this moment to opt in my perspective that I vote to programatically hit admin api endpoints to configure such peers / add them vs auto-discovery or discovery service by default. Still needed, but not default.

To make them aware of each other I will attempt to add a peer account to the /accounts endpoint on one of the nodes. That account information will be of class peer relationship and point to the other node we want to ‘peer’ with.

So , I did try to drop in a peer account and saw some ILP action immediately being attempted in the logs - could this be “peering”. This led me to contemplate “What does is mean to PEER?” :grinning:.

The spec really defines a peer as one that has made an ILP connection. I need to look deeper into what is transmitted but it looks like routes. The spec also states that the resulting connection will end up bilateral so that means a btp websocket to me and thus the direction of the peering is irrelevant to a degree because the goal is to share routes.

Ok stepping back does that mean one must simply have an account with the other? and decide amongst the trusted parties who will configure what, is that correct? Really peering is a client connecting to a server and sharing route data from what I understand.

Putting it into practice.

On to my setup, I have two nodes, on the same subnet both listening on 7770 and 7768 :
ilp-node-1_1 - 192.168.176.4 hostname ilpnode1.local
ilp-node-2_1 - 192.168.176.2 hostname ilpnode2.local

My attempt to make them peer is to first POST a peer account to ilpnode1.local. You can see the POST below.

27%20PM
Screen Shot 2019-07-10 at 10.26.27 PM.png832×895 94.3 KB

As soon as I POST that account creation on ilpnode1 you can see “Sending Route Updates” to that new peer account in the log. It also states outgoing ILP packet over http to ilpnode2 - proof that it is trying.

42%20PM
Screen Shot 2019-07-10 at 10.20.42 PM.png1245×534 399 KB

I ended up with a 404 you can see, but I am not complete. On that ilpnode2 that I am trying to peer with, do I need to create a regular account and pass a btp_outgoing_token as the token of the new target peer node account? That part I left out because I am at that step and thought it would be good to ask the gurus here.

Thanks!

2

Yes. I’m not sure on the specifics of the Rust impl but both peers need to be configured as we don’t have an auto-peering protocol yet.

There is a plugin(s) for the Javascript connector which allows unsolicited connections but these are automatically configured as “child” peers (see: mini-accounts).

3
  1. Establishing a bilateral communication link for sending ILP packets (right now that means either a BTP or HTTPS connection)
  2. Agreeing on a settlement asset, asset scale, and settlement method to use
  3. Potentially sending routing information to one another using the Connector to Connector Protocol (CCP – this PR has the best write-up of it)

Kind of. The “Account” is the Rust implementation’s approach to encapsulate all of the details the peers negotiate as mentioned above.

You’re seeing a 404 because you’re passing the same http_endpoint to both nodes, instead of the http_endpoint of the other node, and because you also need to include the /ilp path in that value (that could be made clearer). Note that if you have HTTP details configured, the node will send the packet over HTTP and not BTP. You will also want to include http_outgoing_token and http_incoming_token for both accounts.

As a side note, it might be better to discuss technical problems related to one of the implementations in the Issues for that particular repository and use the forum more for questions like “what does peering mean”.

4

Is the second node configuration of type account child or peer? I am guessing ‘child’ as peer would yield an extra bilateral connection.

Given that it does auto connection for peers now, the directional element could have some importance. Creating a peer account reference pointing back to originating peer could be useful for connection resilience.

5

If you have two nodes connected to one another, they should either both be “peers” or one should be a “parent” and the other a “child”. That said, that property isn’t heavily used in the code right now so it doesn’t make a big difference either way. The only details that determine whether a bilateral connection is made are the http_ fields and the btp_ fields.

6

Is it assumed that only ONE of the fields are to be used?

7

Yes, the assumption is that you either use HTTPS or BTP