Stop using deprecated selectors
ChronoSync contains usage of Exclude selector that has been deprecated in Packet03Transition. The protocol and implementation must be updated to stop using this selector.
Updated by price clark about 2 years ago
Hey, I've been combing through the gerrit reviews and it looks like some work for this ticket has already been performed, e.g. https://gerrit.named-data.net/#/c/ChronoSync/+/4547/. I'm at a theoretical impasse. With selectors being deprecated and now removed from this codebase, how does this implementation of ChronoSync handle issues with simultaneous data generation? When two chronochat instances start responding to the same sync interests with the different sync data? The "Let's Chronosync..." paper suggests using "Exclude filters" to allow the ChronoSync client to specify suffixes for sync data packets that should not be used to satisfy a given sync interest. Without functionality like that, it seems like partitions are impossible to avoid and would be created constantly on an active network. Is the plan to let the recovery procedures utilized during actual network partitions handle these situations? The protocol in this situation uses recovery interests to find the data from unrecognized sync digests, and in this case are virtually guaranteed to find the data they are looking for, but I fail to see how they could discover all unrecognized sync data with which to start discovery. Am I wrong in asserting that without exclude filters ChronoSync can make zero guarantees as to whether or not an unknown sync digest would ever reach all chronosync clients who aren't aware; since those clients could in theory always have their sync interests answered with known sync digests from perfectly valid sync data. I can't find any discussion about this topic in light of the API changes in the literature or elsewhere in the *.named-data.net space.