Closed dtwitty closed 1 year ago
Good point! I think we can enable this simply by adding sender visibility to the BroadcastHandler trait (guessing we'd need visibility for when Invalidates
comes in to play too); Then when you detect this you simply foca.add_broadcast
and let the periodic probing/gossiping take care of the dissemination for you.
I think adding a variant of broadcast to send it to a specific member could help too.
It won't be able to accommodate a use-case where you want to send the missing data only to node B since (in foca) broadcasting relies on the same mechanisms that we use to disseminate cluster updates (repeated transmissions to random targets), but I think this particular case is way better served externally where you can get a bi-directional stream between members and do a full sync without caring for packet size and whatnot.
Thoughts?
I've released v0.14.0 which contains a change that allows broadcast handlers to know who sent the data they're dealing with:
https://docs.rs/foca/0.14.0/foca/trait.BroadcastHandler.html#tymethod.receive_item
Feel free to reopen with more details if that's not enough for your usecase.
I really like Foca's broadcasting feature for disseminating information. However, as far as I can tell, it is missing the ability to respond to broadcasts.
As I understand it, acknowledgements are a core part of the SWIM protocol, and can be used to send information back to the requesting node. It would be nice if users could piggy-back on this to send their own information back in response to broadcasts.
The main use case I am thinking of is Anti-Entropy. For example, node
A
might broadcast that it has versionx
of the metadata. NodeB
knows that versionx
is out-of-date (from vector clocks or some other way), so it responds back toA
with the up-to-date metadata.