what's the returning behaviour of Kademlia::get_record and can it be configured by Quorum

[maqi]

Looking at the code impl of Kademlia::get_record, when there is a local copy present, a GetRecordOk will be fired back immediately.
Meanwhile, closest peers to the target will be contacted as well.
Does it mean:
1, There will be a sequence of KademliaEvent::OutboundQueryProgressed got received via SwarmEvent channel ?
2, If there are multiple such events to be received, the number of them will be euqual to replication_factor configured?
Or shall be equal or greater to that, as there could be hopping happens when the target is far from the requester?
3, In case the record holder peers holding different copies (say some peers got a copy via put_record_to, and is different to others) for the same record_key, will these different copies all get fetched via multiple KademliaEvent::OutboundQueryProgressed containing GetRecordOk ?

As I understand, being a key-value network, the get_record shall only give one single result for a record_key, and that fetched copy shall be consensused by majority of closest holders at least. In the case of a split, get_record shall fail ?
I notice there is GetRecordError::QuorumFailed , but seems it only record peers not having the record, not including peers having in-consistent record. Neither do I find the place this error got thrown out during the query flow.

Further to that, Kademlia::put_record taking a Quorum parameter which defines how many peers to undertake the put_record correctly.
But get_record doesn't have such, neither there is any configure setup (correct me if I missed any) can affect the get_record behaviour.

In a word, I'd like to confirm and know :
1, get_record return with GetRecordOK for the first copy it got, or any copies can got, or only the copy that majority agreed
2, is there a way to use Quorum to affect the get_record behaviour, via configure setup or function parameter (like put_record)

Thank you very much in advance, and looking forward to any replies.

One more thing to add regarding get_record targeting non-existing entry .
It is noticed that the get_record only completes after fixed timeout duration, when targeting non-existing entry
Is it possible to define the behaviour via configure to make it complete sooner, say change the behaviour to :
return earlier once received majority NoRecord responses among closest to the target?

[mxinden]

1, There will be a sequence of KademliaEvent::OutboundQueryProgressed got received via SwarmEvent channel ?

Correct.

2, If there are multiple such events to be received, the number of them will be euqual to replication_factor configured?

The number is equal to the number of peers contacted, plus the optional local instance.

3, In case the record holder peers holding different copies (say some peers got a copy via put_record_to, and is different to others) for the same record_key, will these different copies all get fetched via multiple KademliaEvent::OutboundQueryProgressed containing GetRecordOk ?

Yes, you will get all the different ones and need to decide which one to use.

As I understand, being a key-value network, the get_record shall only give one single result for a record_key, and that fetched copy shall be consensused by majority of closest holders at least. In the case of a split, get_record shall fail ?

Kademlia is an eventual consistent network with no consistency guarantees. There is no consensus protocol.

But get_record doesn't have such, neither there is any configure setup (correct me if I missed any) can affect the get_record behaviour.

Correct. There is no quorum for get_record. A query ends when there are no more peers closer to the target to be contacted. In case you want to end early, e.g. based on some custom quorum, you can terminate the query prematurely. You can find some of the motivation behind this mechanism in #2712

return earlier once received majority NoRecord responses among closest to the target?

There is no such thing as a majority. I.e. at any point one of the currently closest 20 peers might give us even closer peers to contact. Thus we need to wait for responses from the closest 20 peers in order to eventually terminate. We could adjust the request timeouts though in case that is of some help.

@maqi let me know if the above is helpful.

[maqi]

Hi, @mxinden, thank you very much for the detailed reply,
Yes it is very useful and answered and clarified many of my doubts.
Really appreciate it.