This repository has been archived by the owner on Aug 2, 2021. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
P2p validate accounting #2051
P2p validate accounting #2051
Changes from all commits
4e226df
143a586
22b4f59
90ebd7e
3a62941
b4f7bd0
369cd81
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
conceptually, i don't understand the difference between this function and
Check
, can you please elaborate on this?this one isn't mentioned in the PR description but it seems to be new
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well
Validate
is the interface we need to call it from thep2p/protocols
package, and does some common work like evaluating the cost for the local node and get the message price.Check
is then implemented by theswap
package, and only really does the actual check to see if the operation would incur in some problems in the swap package.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a warning, a potential conflict with #2018, but ti should be easy to resolve, whichever PR gets merged first. @pradovic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem, thanks for the heads-up!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the heads up
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know you did not introduce this line, but it seems to me that here, we would need to test whether
balance + amount < s.params.DisconnectTreshold
. If not, the following situation would be allowed:balance = 499, disconnectThreshold = 500, amount = 1000
But I think we should, in this case, we should disconnect whenever we receive a single message with a positive amount.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be sure, it would be great to see where and by whom this line was introduced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change was introduced by @mortelli with the idea to always allow debt-reducing messages. Let him comment on this; in any case, if this would have to change, it is an important change and then it should be done in a separate PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I vaguely remember this... This comment is not a blocker for me, but would like to get reassurance from @mortelli :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indeed, i introduced this change through PR #1922.
the only difference in checking
amount
instead ofbalance + amount
is one message.in the first case, one message will go over the threshold and then stop the flow; in the second, the threshold will never be reached or surpassed, but there might be a bigger difference between the threshold and the final balance before subsequent messages are stopped.
while correct, the situation you mentioned is unlikely to come up: if a message is priced at
1000
, we should never have set a threshold at500
.assuming then, that
amount
is comparatively small in regards to the threshold, the impact of having this little bit of extra slack should be minimal.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You do
s.getPeer(peer.ID())
here and you also do it in the functioncheckBalance
(swap:319
)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's because
getPeer
is under a lock.getBalance
is called from different places (also fromAdd
) and thus needs to be called independentlyThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand then why you would call it at this place at all. Seemingly all you are doing is verifying whether the peer is a swapPeer, but this is also the first thing you are doing in
checkBalance
.I think that this function can be improved by not doing a call to
getPeer
at all, or by modifyingcheckBalance
to only accept aswapPeer
and then pass theswapPeer
tocheckBalance
.Let me know if I see it correctly!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to explain before but I'll try again, a bit more explicit.
There are two things here:
Check
is called from thep2p/protocols
package, which does not know the notion of a Swap peer, thus,Check
needs to have aprotocols.Peer
in its signature - hence, we need a conversioncheckBalance
is also called fromAdd
, which also for the same reason has aprotocols.Peer
in its signature, thus also needs a conversionswapPeer
is also used elsewhere in theAdd
functioncheckBalance
is called independently, from two places.The other thing is that we are locking the
swapPeer
during these operations. The lock is on theswapPeer
, that is why we need it,Your optimization suggestions would be more stringent if we can remove the lock from
swapPeer
in this case as we are already locking theprotocols.Peer
in theprotocols
package, as @mortelli also noted. However, I am not 100% sure we can omit that lock, it is the same network remote peer but two different objects (protocols
vsswap
). I don't feel safe doing this at the moment, which is why I suggest keeping it as-is, but it is a valid suggestion to revisit this part and analyze if the lock can be omitted, in which case we could probably optimize those methods.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However your second suggestion is good, I changed
checkBalance
to only accept a swapPeer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why? With the peer under lock the balance couldn't have changed since the call to
Check
, right?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is correct. However, just the nature of the two being separate functions could lead to the situation that
Add
be called in a different workflow. For example, I do not recall if all tests now do thisValidate-Apply
workflow - some tests might be calling directlyAdd
(I would actually assume so).Even if the probability is very low, it is correct to check again. However, I am fine removing the check if a majority thinks it is superfluous.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. I don't really like this double-check approach. From just looking at it, it looks as if you are doing something redundantly and it is probably also not water-tight.
A different solution could be that the Check function would leave a trace in Swap that a certain amount has been checked and Add only executes on a validated amount. For example, we could create a mapping where each amount maps to a bool (Checked)), to be set to true during the function
Check
and toggled again afterAdd
has executed.Might be too much engineering though. Let me know your thoughts!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing the additional check, and adding a comment that it is the responsibility of the calling function to check the balance would be more than enough, I think though!