The reintegrator, which is a user-level thread within Venus, manages update propagation. It periodically selects several records from the head of the CML and ships them to the servers. For records with no user-operation information attached, the reintegrator uses value shipping and makes a ViceReintegrate remote procedure call (RPC) to the server. The server, when processing the RPC, back-fetches the related container files from the client. If the reply of the RPC indicates success, the reintegrator will locally commit the updates. Local commitment of updates is the final step of successful update propagation, and includes updating the states of relevant objects, such as version vectors and dirty bits, and truncating the CML.
If user-operation information is available for a record, the reintegrator will attempt operation shipping first. All the records associated with the same user operation will be operation shipped altogether. The reintegrator selects the records, packs the operation log, and makes a UserOpPropagate RPC to the surrogate. If the reply indicates success, the reintegrator will locally commit the updates. However, if the reply indicates failure, the reintegrator will set a flag in each of the records indicating that it has tried and failed propagation by operation shipping. These records will then be value shipped.
The current version of our prototype attempts operation shipping for a record whenever there is user-operation information available. This static approach implicitly assumes that the connectivity between a mobile client and its servers is always weak. In real life, a mobile client may have strong connectivity occasionally. During that time, as explained in the following paragraphs, value shipping is more efficient than operation shipping. We plan to enhance our prototype so that mobile clients dynamically decide whether they should use operation shipping or value shipping.
Our cost model compares the costs of value shipping with that of operation shipping. For each case, there are two different costs involved: network traffic and elapsed time.
For value shipping, assuming the overhead is negligible, the network traffic is the total length L of the updated files, and the elapsed time is Tv = L/Bc, where Bc is the bandwidth of the network connecting the client to the server.
For operation shipping, the network traffic is the length of the
operation log, Lop, and the elapsed time is Top. The latter
is composed of four components: (1) the time needed to ship the
operation log (
Lop/Bc), (2) the time needed for re-executing the
operation (E), (3) the time needed for additional computational
overhead (Hop) such as computing checksum information and
encoding and decoding of forward-error-correction codes, and (4) the
time needed to ship the updated files to the servers. There are two
cases for the last component. If the re-execution passes the
validation (accepted), the updated files will be shipped from the
surrogate (the time cost will be L/Bs, where Bs is the bandwidth
of the network connecting the surrogate to the server); if the
re-execution fails the validation, the updated file will be shipped
from the client (the time cost will be L/Bc). The following
equation summarizes the time costs involved: