Yes, strange title lol - I am rebuilding AOL.com! j/k
My question has to do with a scenario where you have only ONE CONNECTOR and multiple accounts.
It is my understanding that once that connector receives a PreparePacket it will look to its routes and determine if it needs to forward. Because it is local it will adjust the store balance.
To illustrate further, you have two accounts on that single connector backend:
Account-B
Account-A
Then from a client application you craft a PreparePacket to fire at the Connector. The packet contains the auth token for Account-B and the to: as Account-A.
Technically this seems to be allowed as the routing checks resolve local - no forward.
Please confirm I should see a local transfer take place.
Yeah, the connector should be able to forward the packet. Although I donât know what you mean by âlocal transferâ exactly. If youâre referring to settlement then it is unlikely that a single ILP packet will trigger settlement but it depends on configuration. Hope this answers your question
This is more a test bed hacker type thing. There is only one connector.
In a command line app I simply connect raw socket to the /ilp route and send a packet crafted with the auth token of one user and the rest of the PrepareBuilder details to the other local connector account.
Once that connector receives the packet, there is no where to forward since the addresses are local to that single connector.
Yes I would expect the balance to change in the underlying store. I would not call this true settlement but I suppose it could be termed that even without a ledger.
The part I am trying to discover is if I can make the local transfer by crafting an authorized packet.
It sounds like you might be talking about the rust connector, which Iâm not very familiar with the abstractions of.
You can have multiple addresses under a single connector, for instance a connector which accepts connections on two âchildâ accounts, but I donât know if thatâs the topology youâre running.
Running moneyd local
is an example of a single-connector topology, and you can still run SPSP sender/receivers or anything else that runs on ILP.
yes you are correct - I am in the rust connector, I recall seeing this occur in moneyd local in nodejs but I suspect now it was using SPSP.
I donât know the details of the rust connector, maybe @emschwartzcan help here but generically, what you want to do is possible.
When you connect to the connector as Account-A or Account-B the first thing you will need to do is:
a) get an address which is a sub-address of that connectorâs address, or
b) make the connector aware of your address
The most likely scenario is a) so imagine the connector has the address test.connector
, you connect using the credentials of Account-A and perform an IL-DCP query to get your own address. This is returned as something like: test.connector.account-a
.
You would repeat the same process for Account-B and likely have an address like: test.connector.account-b
.
Now if you are connected as Account-A and send packets addressed to test.connector.account-b
they will be routed to the entity connected as Account-B.
Note that the internal routing table of the connector should track the lifecycle of peer connections. If a connection to a peer is down then the connector should remove routes to that peer (and possibly replace them with routes via another peer if it is aware of these).
The only time a connector routes a packet to itself is if it able to fulfil that packet (not a scenario Iâve seen implemented in any connectors) or if the packet is being used for a protocol like the Echo protocol for network analysis.
@fractal-synapse in order to have the receiving account fulfill the packet, youâll probably want to use higher level protocols like STREAM and SPSP.
To send a local payment on the Rust implementation, you would send an HTTP request to /pay
with the receiver
field set to the SPSP URL of the other account (something like http://localhost:7770/spsp/2
where 2
is the AccountId
of the receiving account.
Note: the Rust implementationâs HTTP API is not yet stable so the exact API calls and paths may change in the future.
Agreed, I am in a research phase to grok ILP packets at the lower layers, then I will layer in the goodness of higher level abstractions after I understand the foundations of the protocol.
I am however getting a bit further in this test now by firing manually crafted packets into the /ilp endpoint. Iâll continue these experiments and posts into the rust topic area since things are getting ârustyâ.
To close off this thread, it seems to be possible what I am suggesting but I see now in the code that at the very least the routing is looking for an outgoing btp address which would imply wanting at least two connectors in this idea. I may try to formulate a local btp address for the destination and see if it routes to the btp port.
Thanks for the insights.
Instead of having a second connector, you could also use a script that connects via BTP (as a client) to 2 accounts on the same node. If you send a packet with the destination
set to the second accountâs ILP address, the node will forward it over the open BTP/Websocket connection to the second node. To fulfill the packet, youâll need to have the script send back a Fulfill
packet with the preimage of the execution_condition
.
1 Like