waggle: initial version - #732
Conversation
|
|
||
| To discover additional dissemination opportunities, a peer also selects a random subset of connected peers for which it has no current metadata view and advertises its current object metadata to them. These exchanges allow peers to progressively discover missing pieces and establish additional synchronization relationships throughout the network. |
There was a problem hiding this comment.
again, subset of subscribed peers.
Also, I am unsure if this should be codified here. At the very least, there should be a MAY somewhere in here IMO.
There was a problem hiding this comment.
updated to remove the random reference. Why MAY? this is part of the dissemination, the protocol should guarantee that applications are able to in the limit flood the network so that a full dissemination is achieved.
If applications set the gossip factor to 0 this step is skipped
| ## Object Cache | ||
|
|
||
| The lifetime of cached object and piece state SHOULD be configurable by implementations and tunable by applications according to their resource constraints and dissemination requirements. |
There was a problem hiding this comment.
There should not be a waggle maintained object cache. Waggle can not by itself utilize such a cache, as all fields are opaque, so the caching should just be responsibility of the application,
There was a problem hiding this comment.
the fields being opaque doesn't mean you can't store them as bytes as we do with partial messages cache, which compares and validate against new received pieces
There was a problem hiding this comment.
such a general purpose cache might be very inefficient, depending on the object being disseminated. I'd just let the application manage it.
In the end, maybe this boils down to being an API question: Either a highly configurable and modifiable cache that lives in the waggle implementation, or letting this be the responsibility of the application. I lean towards the latter.
There was a problem hiding this comment.
From the application's perspective, I think you can always set a TTL or a timestamp deadline for each of the message types or topics.
If this is configurable per topic, I don't see the problem of the cache being directly at waggle.
|
To build some intuition for the proposal, could we walk through the degenerate case of an object consisting of a single piece? As I read it, after the initial publication fanout, a peer does not forward the piece to another peer until it has metadata indicating that peer is missing it. Instead, it first disseminates its current object metadata in a FloodSub-like manner to progressively establish those views. Once such metadata exists, the piece can be selectively pushed to peers known to be missing it. |
4 participants
first draft to start the conversation, info is in the spec.