KarmaCoverage Posted January 23, 2019 Share Posted January 23, 2019 https://link.medium.com/aZuMXj7lIT Interesting Dario_o, jn_r, Lamberth and 5 others 5 3 Link to comment Share on other sites More sharing options...
Lamberth Posted January 23, 2019 Share Posted January 23, 2019 Great article as always from Evan Link to comment Share on other sites More sharing options...
Silenos Posted January 23, 2019 Share Posted January 23, 2019 More discussion regarding this topic in the Interledger mailing list: https://lists.w3.org/Archives/Public/public-interledger/2019Jan/0003.html KarmaCoverage 1 Link to comment Share on other sites More sharing options...
KarmaCoverage Posted January 23, 2019 Author Share Posted January 23, 2019 (edited) 1 hour ago, Silenos said: More discussion regarding this topic in the Interledger mailing list: https://lists.w3.org/Archives/Public/public-interledger/2019Jan/0003.html If anyone can share thoughts on this, that would be great... Quote The one aspect of WebSockets that may be hurting performance is the masking which means that payloads need to be pre-processed before being sent. That said, it's a very efficient algorithm so we'd need to test it to be sure it's an issue. A concern I have with the cluster of stateless connectors is the latency you'll introduce if the connector must do a balance check against a DB for each packet. This can be optimised to a point but in reality the most efficient way to do this will be to ensure the stickiness at the load balancer routes packets from the same peer to the same connector. Not sure this will be useful in a scenario where both peers are routing high volumes of packets It is interesting to see where various functions are falling. Quote That said, I think decoupling the messaging from the clearing and settlement (FYI: forwarding ILP packets isn't clearing, clearing involves reconciliation and netting, but that's a different issue) will be a huge improvement to the architecture. I'm guessing (may be totally wrong?) that a Connector/ILSP can "clear or net" flows internally (just like an exchange can do for client trade which they can match) and then only send the non-netted payment flows on down the payment path. Edited January 23, 2019 by KarmaCoverage Link to comment Share on other sites More sharing options...
jn_r Posted January 23, 2019 Share Posted January 23, 2019 Here are some thoughts / 2 cts: 3 hours ago, KarmaCoverage said: a Connector/ILSP can "clear or net" flows internally (just like an exchange can do for client trade which they can match) and then only send the non-netted payment flows on down the payment path A connector serves its clients (which can be original ILP senders or other ILP connectors) by accepting their payment and forward the payment (route) to the next connector. All the clients have a relationship with the connector, i.e. an 'account'. If for example the relationship is based on an XRP payment channel, then the account can be pseudonymous, but at least it is known and kept for as long as the relationship lasts. The accounts can also be implemented in other ways, e.g. as some sort of debit/credit system. ILP example flow: Coil browser -> Coil connector -> Strata connector -> xrptipbot 'moneyd' connector -> xrptipbot-ledger account (payment pointer) The Coil connection from your browser to a coil ILP connector is not based on XRP payment channel, but on the credit you have at the connector - as you are a known client from Coil (with 5$ monthly subscription). The next ILP hops in a coil payment are from Coil to Strata and from Strata to xrptipbot, his 'moneyd' node. Both hops based on XRP payment channels Then a final ILP delivery (not XRP payment channel) is made to your account at xrptipbot-ledger. (you receive an IOU, not XRP .. you can withdraw to XRPledger if you want) I am imagining the process of accepting/validating one or more XRP payment channel packages to be called the 'clearing/netting' of that particular payment and when you want to make it definitive in the payment-channel or on-ledger, you 'settle'. The clearing/settlement for the payment from coil-browser to coil-ILP-connector is very different. As is the clearing/settlement from xrptipbot moneyd to your xrptipbot-ledger-account. Maybe interesting to read more on XRP payment channel setup and so called 'mini-accounts' here: https://github.com/interledgerjs/ilp-plugin-xrp-asym-server 3 hours ago, KarmaCoverage said: WebSockets The connection between ILP client and ILP connector. The client communicates the intended ILP package (the 'prepare') to connector and waits for the 'fullfill' answer. If received, then the payment is processed (clearing/settlement) and at his turn the client sends the 'fullfill' back to its own client (if any), etc. This repeated for many micro-payment packages. In a websocket connection, the connection is kept alive for processing multiple messages The point being made is that keeping every connection alive (stateful) for its duration in a bi-directional websocket is apparently a more heavy load than compared to an architecture using stateless http sessions: stateless sessions can be scaled horizontally with existing (cloud) techniques. The ILP communication without the 'non ILP'-clearing/settlement can be done stateless; clearing and settlement (everything that is not ILP) can be done separate and maybe at more convenient intervals. Passing the clearing/settlement to a separate engine, the managing of account balances to a database system, the whole process would become more lean and scalable. KarmaCoverage and King34Maine 2 Link to comment Share on other sites More sharing options...
KarmaCoverage Posted January 24, 2019 Author Share Posted January 24, 2019 @jn_r thank you! I'm going to have to read that a few times, but I think I followed, and it is sort of what I thought I was understanding. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now