akvize / reconcile-rs Goto Github PK

Pro: this would allow providing old_v to the hook
Con: this requires cloning the key and values when passing them to HRTree::insert (or we could redesign insert to return references for these)

Currently, all reconciliation is done in a single thread. In certain circumstances, allowing deserialization, reconciliation and serialization to be performed in separate threads could be useful.

Currently, tombstone care-taking is done in Service::{insert,remove}{,_bulk}, which are not called when doing reconciliation with another instance. The list of known tombstones should be updated in before_insert.

However, before_insert is currently only called during reconciliation. The first step is thus to unify this by having before_insert be called by InternalService::insert{,_bulk}. Thus, this issue is blocked by #57.

The name HTree is already reserved on crates.io.
HRTree, or HashRangeTree, better fits the inner working of our tree, which can be queried on hash ranges.

Using the map in pre_insert would currently leave to a deadlock, since the guard is taken before calling the hook. This can be easily solved in just_insert, but not in just_insert_bulk.

They should encapsulate the iteration over the underlying map without exposing tombstones.

This could be provided with CIDR syntax:

cargo run -- 192.168.1.0/24

cidr_utils looks like it is the most convenient crate to sample random IPs from a given range. We could also implement our own parser, based on, e.g., std::net::IpAddr.

Look for timer wheel structure

Enable users to manipulate the Service's inner map transparently.

Following the merging of #34, the CI on master has failed three times in a row:

• https://github.com/Akvize/reconcile-rs/actions/runs/6827671254/job/18570273103#step:7:126
• https://github.com/Akvize/reconcile-rs/actions/runs/6827671254/job/18572262948#step:7:127
• https://github.com/Akvize/reconcile-rs/actions/runs/6827671254/job/18575291635#step:7:133

Although it points to tests/remove_service.rs, the actual issue is with one of the services failing with Operation not permitted when calling std::net::UdpSocket::send_to in Service::start_diff_protocol.

As a nice-to-have we could give the user the choice between sending to 1, k or none.

Originally posted by @adriendellagaspera in #42 (comment)

HRTree is an implementation detail to the reconciliation Service
and could be used independently from the reconcile crate.

Dependent on #22

Once #12 is resolved, insert() will immediately send the value in a datagram. This can be inefficient when inserting many values at once. Instead, we should also offer an insert_bulk() method, which will try to group as many values as possible in a datagram.

Since we need to update the last time we've seen a peer, we'll also need a timer wheel structure

We want:

-assert_eq!(service1.read().get(&key).unwrap().1, None);
+assert_eq!(service1.get(&key), None);

Currently, the integration test in tests/service.rs must wait until the reconciliation protocol starts. This happens after up to 100 ms (the timeout for recv_from).

This will also happen in real conditions.

This can be improved by having Service::insert() broadcast the change immediately to the peers.

Pour le moment le code expose deux comportements différents pour la réconciliation :

• reconciliate pour réconcilier deux HTrees localement. Il ne sera jamais vraiment utile, sauf à choisir de partager entièrement le HTree par UDP avec une autre instance et de le récupérer "à jour" ensuite.
• answer_queries pour acter le processus de réconciliation entre un HTree local et un remote, par le biais de ccommunication UDP. Il agit comme une surcouche de communication réseau au-dessus de la couche de stockage (le HTree). Mais pour le moment, cette couche de communication est encore trop couplée avec la couche de stockage. Notamment, c'est à ce niveau que sont gérés les conflits.

Je propose de mieux établir la spec pour chaque couche pour mieux s'y retrouver notamment dans la définition des comportements associés.

This function or method should not require the user to instantiate HRTree themselves.

Options:

• QUIC
• TCP
• custom logic over UDP