You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 1, 2022. It is now read-only.
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:
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.
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.
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.
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]>
* 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]>
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:
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.
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.
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.
The text was updated successfully, but these errors were encountered: