Skip to content
This repository has been archived by the owner on Jun 1, 2022. It is now read-only.

STREAM Sender: Compute Sender Address Properly #445

Closed
sappenin opened this issue Apr 8, 2020 · 0 comments
Closed

STREAM Sender: Compute Sender Address Properly #445

sappenin opened this issue Apr 8, 2020 · 0 comments
Assignees
Labels

Comments

@sappenin
Copy link
Contributor

sappenin commented Apr 8, 2020

Today the Java STREAM sender encountered issues with Rafiki while sending from XRP (scale=9) to USD (scale=6). The payments would work until the amount of units exceeded 11,000 (XRP, scale=9) in which case the JS receiver would send F99's until the Java sender timed out.

Oddly, this behavior was not found when using the JS sender. In the process of debugging this issue, it seems there are a few bugs in both the JS and Java code bases:

From Kincaid:

  1. The async operations in after .on('connection', ...) prevented registering the event handler for incoming streams before the first stream event was emitted, so setReceiveMax was never called for that stream (and it defaults to 0). So, the JS STREAM server would reject all packets where it received > 0. I attribute this largely to the JS server exposing a complex/unintuitive API.

  2. Separately from this, when the JS STREAM server gets a new connection, it initiates a rate probe back to the client. If it can't determine the exchange rate, is closes the connection. This needs to be fixed so servers that are only receiving money don't initiate this probe.

  3. Lastly, that rate probe failed due to an "R00 packet expired" error on the Java side. I'm guessing (?) this is because there was nothing to handle the packets sent back to the source address, test.xpring-dev.jc.test. Even if it can't receive incoming money, it seems weird to advertise a source address that can't receive packets. For the Java sender, it might be nice to respond to these incoming packets with an F99 or more descriptive error message. (Even better, if it returned an F99 with a STREAM response packet including the amount it received, the rate probe may have succeeded).

This last point, in the Java code-base, should be addressed. Technically the StreamSender should either not advertise a source address, or it should compute it properly in the same manner that the SPSP server would, except using the Stream shared-secret.

The offending code is here.

@sappenin sappenin added the bug label Apr 8, 2020
@sappenin sappenin self-assigned this Apr 8, 2020
sappenin added a commit that referenced this issue Apr 25, 2020
Send a non-routable address, based upon the operator address and username (for logging) when the sender address is not specified in a SendMoney STREAM call.

Signed-off-by: David Fuelling <[email protected]>
sappenin added a commit that referenced this issue May 5, 2020
* Allow sender’s source address to be empty (in order to indicate the client-sender is not routable, and thus cannot receive payments).
* Fixes #445

Signed-off-by: David Fuelling <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

No branches or pull requests

1 participant