rename vars in mnsync to make more sense#2308
Conversation
There was a problem hiding this comment.
On first sight, it sounds like "peers currently in progress" or something like that. Maybe nTriedPeerCount is better?
There was a problem hiding this comment.
Agree, nPeerCount is confusing imo. Smth like nTriedPeerCount or simply nTriedPeers would be better I think.
There was a problem hiding this comment.
I probably don't understand the code well enough then, but nTriedPeers would seem misleading, right? As I understand it, it's the count of peers with which we are trying to sync a particular asset at the given moment, right? So "nTryingPeers" would seem more appropriate, but I have a feeling my understanding might be off.
@UdjinM6 Can you explain to me (since I seem to be confused) what exactly this variable is keeping count of? Is my understanding in the previous paragraph not correct?
There was a problem hiding this comment.
As I understand it -tried as we already asked this many peers for this asset while trying is like we are (still) asking this many peers for this asset. The funny thing is that the former is true for mnb/mnw because we ask for the whole set at once and the later is true for gobject/gobjvotes because we ask for a partial info in many steps. So any option is good for me, I wouldn't argue one over the other too much :) (EDIT: but tried sounds a bit more general and fits better imo 😄 )
nRequestedMasternodeAssets -> nCurrentAsset nRequestedMasternodeAttempt -> nPeerCount
18e42fd to
fd6373e
Compare
|
Rebased onto latest |
UdjinM6
left a comment
There was a problem hiding this comment.
utACK
Should probably update PR description ;)
|
👍 Updated description |
* rename vars in mnsync to make more sense nRequestedMasternodeAssets -> nCurrentAsset nRequestedMasternodeAttempt -> nPeerCount * rename var to nTriedPeerCount
nRequestedMasternodeAssets->nCurrentAssetnRequestedMasternodeAttempt->nTriedPeerCount