Patching A Patch - Software Updates Using Horizontal Patching

Patching A Patch - Software Updates Using Horizontal Patching Milosh Stolikj, Pieter J. L. Cuijpers, and Johan J. Lukkien, Member, IEEE Dept. of Mathematics and Computer Science, Eindhoven University of Technology, P.O. Box 513, 5600 MB, Eindhoven, The Netherlands Abstract—This paper presents a method for optimizing incremental updates of consumer electronic devices running multiple applications, called horizontal patching. Instead of using separate deltas for patching different applications, the method generates one delta from the other. Due to the large similarities between the deltas, this horizontal delta is small in size. In all test cases horizontal patching produced smaller deltas, with compression ratios between 8.02% and 43.38%.

I. I NTRODUCTION Today’s consumer applications, such as a DLNA based media system [1], are running on multiple, networked devices. A more pervasive upcoming system is an adaptive ambient lighting system [2], that employs a network of low capacity nodes with different roles. For instance, while some nodes measure luminance, others are responsible for switching the light actuators. Update server Old version DIFF

Delta (δ)

Compress

Compressed delta c(δ)

New version Distribution Old version New version

Patch

Delta (δ)

Decompress

Compressed delta c(δ)

Updated node

Fig. 1.

Overview of an incremental update.

Updating software is an essential feature of modern CE devices, for the purpose of bringing new functionality, or correcting discovered bugs. Since the number of nodes to be updated can be large, the communication medium has limitations and the update should be swift, a software update is a non-trivial task. This is especially true for sensor networks where the lifecycle of nodes depends on small batteries. Update A Node type A

Update A Update B

Node type B

Update A Update B

Node type A Update B

Fig. 2.

Node type A

Node type B

Updating two different node types in a sensor network.

Software is most effectively updated in an incremental fashion [3] (Figure 1). Incremental updates use small scripts called deltas (δ), which contain instructions and data to produce an updated version from a previous one. In networks running multiple applications, incremental updates foresee separate deltas for each application. Since nodes of each type might be distributed throughout the entire network, in all update

schemes that use multicasting as a basis, all deltas will be transmitted to almost every node (Figure 2). In this paper, we present a new method for handling code differences in systems running multiple applications. Instead of distributing separate deltas for each application, one delta is generated from the other one, and both deltas are distributed together. The combined delta is smaller in size, hence less data needs to be transmitted, saving work, bandwidth and energy. Related work on multiple deltas mainly focuses on incremental updates of a single application. In [4], multiple consecutive deltas for one application are merged to decrease the delta’s size. Our work is complementary, focusing on situations where multiple applications need to be updated. In [5], an epidemic propagation protocol is described to handle the distribution of multiple deltas of applications for the Android system. The protocol assumes that one application can evolve into multiple orthogonal versions, hence multiple deltas exist for it. Their approach optimizes the gathering of deltas in an opportunistic fashion. In [6], updates of multiple applications are planned off-line by examining which combination of deltas has the smallest size. The method we present broadens the scope of the two works, by allowing one delta to be the source of another delta, essentially expanding that search space. Old data:

ABBBBACBBBAABBABBBBCBBBAABABBA

New data:

ABBBBCCBBBAABABBBBBCBBBAABACCFA

Control block:

ADD 27, INSERT 4, SEEK 3

Diff block:

0000020000000-1100000000000

Extra block:

CCFA

BSDIFF delta

Fig. 3. Example of a BSDIFF delta. ADD specifies that the first 27 bytes from the old data and from the Diff block are summed. Zeroes in the Diff block mean that the corresponding byte from the old data is unchanged. INSERT adds four bytes from the Extra block to the output. SEEK moves the pointer in the old data three places forward, to the end of the stream.

II. BSDIFF D ELTA ENCODING We use the BSDIFF [3] format for delta encoding. An update with BSDIFF is created in two steps (Figure 1). First, a delta (δ) between the two versions is constructed. Then, the delta is compressed using Bzip2 (c(δ)) and sent to the node for update. There, after decompression, the delta is applied to the old version to reconstruct the new version. BSDIFF has a two-pass algorithm to construct optimized deltas. In the first pass, completely identical blocks are found

in the two versions. Next, these blocks are extended in both directions, such that every prefix/suffix of the extension matches in at least half of its bytes. These extended blocks correspond to the modified code. The BSDIFF delta is built of three parts (Figure 3): a control block of commands; a diff block of bytewise differences between approximate matches and an extra block of new data. When the old and new version are similar, the diff block consists of large series of zeroes, which are easy to compress. III. H ORIZONTAL PATCHING Consider a network with two node types (A and B) as in Figure 2. Currently, when the operating system needs to be updated, two separate deltas are created, one for each node type. Both deltas are distributed independently. In horizontal patching, one delta is used as a basis, and the other delta is an update of the first one (Figure 4). The motivation is that the operating system is the largest part of the software in both cases, and that is the part that is changed. Both deltas hold the same modifications, thus the horizontal patch between them is smaller in size than the vertical one. The combined delta then consists of the basis and the horizontal delta, compressed together (c(δ0 +δ2 ), or c(δ1 +δ3 )). E.g., when δ0 and δ2 are used, only δ0 needs to be executed for updating node type A. On node type B, first δ2 is executed on δ0 , producing δ1 ; finally, δ1 is executed (Figure 5). The savings in space by using the combined delta in the multihop part of the network overweighs the loss in using it in the last-hop part. Node type A Operating system v1 Application A

Node type B Operating system v1 Application B

δ2 δ3

δ0 Node type A Operating system v2 Application A

Fig. 4.

δ1 Node type B Operating system v2 Application B

Possibilities for horizontal patching. c(δ0,δ2)

Node c(δ0,δ2) type A

Node c(δ0,δ2) type B

Node type A

c(δ0,δ2)

Fig. 5.

Node type A Node type B

Horizontal patching in practice.

IV. E VALUATION We tested on a sample set of seven applications for the Contiki operating system [7]1 , and two consecutive operating system updates (Table I). We considered all combinations of 2 applications, and for each combination we computed the size of all deltas in Figure 4. The first application (node type A) was always larger than the second one (node type B). We used the compression ratio, i.e., the percentage of data saved from transmission from the original data, as a metric: 1 The operating system and applications were compiled as one firmware image for commercially available sensor nodes.

delta size )100. The results in Table II indicate cr = (1 − c(δ 0 )+c(δ1 ) that largest reductions in size are achieved by using horizontal patching from larger to smaller applications (δ0 +δ2 ). Improvements differ depending on the type and size of applications. The gain is the smallest when both applications are larger than the operating system. When both applications are of similar size, horizontal patching gives up to 43% smaller deltas.

TABLE I S IZE OF SAMPLE DATA IN BYTES . Application 1 2 3 4 5 6 7

Contiki 2.3 42,000 39,396 29,780 28,872 23,432 23,000 22,944

Contiki 2.4 41,904 37,356 27,524 26,616 21,124 20,700 20,644

Contiki 2.5 41,504 39,448 29,776 28,868 23,484 23,060 23,000

TABLE II C OMPRESSION RATIO OF COMPRESSED HORIZONTAL PATCHES RELATIVE TO VERTICAL PATCHES (c(δ0 ) + c(δ1 ). Delta type c(δ0 + δ1 ) c(δ0 + δ2 ) c(δ1 + δ3 )

Minimum 7.73% 8.02% 5.78%

Maximum 29.67% 43.38% 43.00%

Average 17.17% 25.82% 23.28%

STDDEV 5.67% 10.13% 11.20%

V. C ONCLUSION In this paper we presented horizontal patching, a method for optimizing the size of incremental updates in a multiapplication environment. Horizontal patching reduces the size of updates by constructing one delta from another. We validated our hypothesis with experiments for two applications. As future work, we foresee the analysis of impact of the additional processing in horizontal patching on the total delay of an update. Furthermore, when the number of applications increases, interesting combinatorics come into play for choosing the set of possible and optimal updates. Additional analysis would define which delta should be taken as a basis, and how the update should be formed. Although the method was demonstrated in a sensor network, it can be used for updating CE devices which share the same code base. We showed that updating the firmware of several CE devices, as television sets or smart phones, can be done by a flooding scheme using smaller updates. R EFERENCES [1] Digital Living Network Alliance, DLNA home networked device interoperability guidelines version 1.0. 2004. [2] S. Bhardwaj, A.A. Syed, T. Ozcelebi and J. J. Lukkien, Power-managed smart lighting using a semantic interoperability architecture. Conf. Consumer Electronics (ICCE), 2011, pp.759-760. [3] C. Percival, Matching with mismatches and assorted applications. Ph. D. Thesis, University of Oxford, 2006. [4] R. Kiyohara, K. Tanaka, Y. Terashima, S/W upgrade for on-vehicle information devices. Conf. Consumer Electronics (ICCE), 2012, pp.19-20. [5] T. F. Bissyand´e, L. R´eveill`ere, J.-R. Falleri, and Y. Bromberg, Typhoon: a middleware for epidemic propagation of software updates. Middleware for Pervasive Mobile and Embedded Computing (M-MPAC), 2011. [6] A. Shamsaie, and J. Habibi, Planning updates in multi-application wireless sensor networks. Symp. Computers and Communications (ISCC), 2011, pp.802-808. [7] A. Dunkels, B. Grnvall and T. Voigt, Contiki - a Lightweight and Flexible Operating System for Tiny Networked Sensors. Work. Embedded Networked Sensors (Emnets-I), 2004, pp.455-462.