Rust SPSP payment through CLI

Implementations and SDKs
1

Hi , I am unable to make a simple payment transfer across two running local nodes, please advise the the proper command syntax with respect to addressing in the rust implementation.

Imagine you have two nodes, each node has an account, one has bob the other has alice. The connector that alice lives on also has an SPSP server running.

spsp-payment
spsp-payment.png1901Ă—608 73.5 KB

On bobs connector I try the CLI for SPSP.

/usr/local/bin # ./interledger spsp pay -a 500 -r $http://172.25.0.4:7770/pay/local.alice
[2019-07-19T20:59:56Z ERROR interledger_btp::client] Error connecting to WebSocket server for account: 0 Io(Os { code: 99, kind: AddrNotAvailable, message: "Address not available" })
Error connecting to BTP server: ()
(Hint: is moneyd running?)

How do I address alice? especially if the SPSP server is running ILP over HTTP on port 3000 with only a local loopback binding.

Also it mentions btp client , it is such that the CLI for http spsp does not work?

2

You will need to pass the btp_server or http_server as CLI args (see here) so that the CLI knows where to send the ILP packets. It should point to the sender’s node. For BTP, the default port is 7768 and no path is needed. For HTTP, the default port is 7770 and you’ll want to direct it to /ilp. Also don’t forget to include Alice’s authorization token in the URI so that the node knows which account holder the packets are coming from.

Also, the receiver endpoint should be /spsp/<numeric account ID>. The /pay API is meant to be called by the sender.

3

Ok that moves me a long . I am not sure what you mean by alices token, how or why would bob know that? Also where do I encode that.

I tried two commands:

Below is the output. I added /ilp for the http_server arg. and the 404 went away. :slight_smile: mentioned above.

16%20PM
Screen Shot 2019-07-19 at 4.11.16 PM.png1644Ă—495 260 KB

4

Try running ./interledger spsp pay -a 500 --http_server http://:token@localhost:7770/ilp -r http://172.25.0.4:7770/spsp/0

But replace token with the http_incoming_token configured on the sender’s account (on whichever node is listening on localhost:7770)

5

OK just tried the following and it sent the server into an infinite loop :
./interledger spsp pay -a 500 --http_server http://:bobtoken@localhost:7770/ilp -r http://172.25.0.4:7770/spsp/0

10%20PM
10%20PM1479Ă—855 634 KB

6

That looks like the two nodes aren’t connected to one another. Are there accounts configured on each node for the other one? (They should have http_endpoint, http_outgoing_token, http_incoming_token set so that the first node can send packets to the other and the other will accept the incoming request)

Could you post the results of calling GET /accounts on both nodes?

7

OK - As my picture illustrates, no peer connection, only one account in each node.

**ilpnode1  GET/accounts**
{
"amount_per_minute_limit": null,
"asset_code": "ABC",
"asset_scale": 9,
"btp_outgoing_token": null,
"btp_uri": null,
"http_endpoint": null,
"http_outgoing_token": null,
"id": 0,
"ilp_address": "local.bob",
"max_packet_amount": 18446744073709551615,
"min_balance": -10000,
"packets_per_minute_limit": null,
"receive_routes": false,
"round_trip_time": 500,
"routing_relation": "Child",
"send_routes": false,
"settle_threshold": 100000,
"settle_to": 0,
"settlement_engine_asset_scale": null,
"settlement_engine_ilp_address": null,
"settlement_engine_url": null
}

and the other node…

**ilpnode2  GET /accounts**

{
"amount_per_minute_limit": null,
"asset_code": "ABC",
"asset_scale": 9,
"btp_outgoing_token": null,
"btp_uri": null,
"http_endpoint": null,
"http_outgoing_token": null,
"id": 0,
"ilp_address": "local.alice",
"max_packet_amount": 18446744073709551615,
"min_balance": -10000,
"packets_per_minute_limit": null,
"receive_routes": false,
"round_trip_time": 500,
"routing_relation": "Child",
"send_routes": false,
"settle_threshold": 100000,
"settle_to": 0,
"settlement_engine_asset_scale": null,
"settlement_engine_ilp_address": null,
"settlement_engine_url": null
}
8

Ok so I added those new account fields when creating the accounts as you suggested.

Test 1 :

  • ilpnode1 has bob AND alice.
  • ilpnode2 has alice AND bob

Result:

/usr/local/bin # ./interledger spsp pay -a 300 --http_server http://:bobtoken@localhost:7770/ilp -r http://172.25.0.4:7770/spsp/0
Sent: 300, delivered: 300 (in the receiver’s units)

Even though this looks successful the balances only change locally on ilpnode1 , I am expecting to see alice on her home connector of ilpnode2 to receive money there.

If I remove alice from ilpnode1, you get the infinite loop.

Neil

9

Okay, making progress.

What do you see when you query /accounts/:accountId/balance for each of the accounts on both nodes?

(Side note: I find it somewhat confusing that you’re sending from Bob to Alice because most examples use Alice as the sender)

10 
/usr/local/bin # ./interledger spsp pay -a 300 --http_server http://:bobtoken@localhost:7770/ilp -r http://172.25.0.4:7770/spsp/0
Sent: 300, delivered: 300 (in the receiver's units)

Ok I had a look in redis on the node the spsp pay command was run :

Bob : -300
Alice: +300

On node 2 - which is the receiver target I see
Alice: 0
Bob: 0

11

The issue might be that you’re using the same account on node 2 for handling the incoming ILP packets as is acting as the SPSP receiver.

My guess is that if you set up the nodes as follows with the fields listed in parens, the balances would look correct afterwards:

Node A

  1. Alice (http_incoming_token)
  2. NodeB (http_endpoint, http_outgoing_token)

Node B

  1. NodeA (http_incoming_token)
  2. Bob

The NodeB account on Node 1 should be configured with the HTTP details for its account on Node B.

The command for this should be:
/usr/local/bin # ./interledger spsp pay -a 300 --http_server http://:alicetoken@localhost:7770/ilp -r http://172.25.0.4:7770/spsp/1
(assuming Bob is account 1 on Node B)

I believe the problem is that if the same account receives the packet from the other node and fulfills it (because it’s the SPSP server), the net result will be 0. The balance will be decreased when the Prepare comes in and increased when the Fulfill is given.

12

I wrote up this issue to discuss the proper behavior in the case that I believe this example highlights: What should happen if you send a payment to your own account on another node?

13

Ok, so I set up the node deployments exactly like you suggested and it results in an infinite loop of packet processing when the command is run.

Here is a snippet of that output:

37%20PM
Screen Shot 2019-07-25 at 11.04.37 PM.png1167Ă—657 459 KB

14

For anyone else reading this @emschwartz has switched our context to alice paying bob :sweat_smile:

The infinite loop is tied somewhat to the fact there is no route entry for bob on nodeA , this it why it throws the “no route found for request”.

ilp-node-1_1     | [2019-07-26T05:30:28Z TRACE interledger_http::server] Got incoming ILP over HTTP packet from account: 0
ilp-node-1_1     | [2019-07-26T05:30:28Z TRACE interledger_router::router] Checking route: "local.alice" -> 0
ilp-node-1_1     | [2019-07-26T05:30:28Z TRACE interledger_router::router] Checking route: "local.nodeb" -> 1
ilp-node-1_1     | [2019-07-26T05:30:28Z ERROR interledger_router::router] No route found for request: IncomingRequest

The looping aspect itself, where a packet is being dispatched and processed repeatedly is also a point of interest. I wouldn’t expect us to fall into this processing loop.

I guess in terms of routing logic, maybe ILP nodes need a default gateway for packets to route outside their knowledge or awareness? @emschwartz @sappenin

I was kind of thinking that is a bit of what may have existed due to peer links, gateways are established.

However, CCP seems to be about sharing entire route tables with everyone having the same authority on the routes.

Nonetheless, if Node A knew to try sending the packet to Node B (even by matching URI parts) then I think it might have resolved to find Bob sitting there on Node B.

I have not dug into the code to confirm what actually happens.

1 Like