In order to maintain the properties of the service that is replaced during DPU, it may be necessary to transfer some data from the protocol that gets replaced to the new protocol. For instance, consider the DPU of a protocol P by a protocol newP such that both P and newP provide a dynamic atomic broadcast service [Sch06]. This service is similar to the atomic broadcast defined in Section 2.2.6, but is dedicated to primary-partition model. Roughly speaking, dynamic atomic broadcast ensures that messages are delivered in a total order among a set of processes, called a view, while allowing dynamic changes of the view (initiated externally to the protocols that provide the service). Thus, DPU of protocol P by protocol newP requires to transfer the current view of P to newP . Otherwise, protocol newP will not deliver messages to the correct view, and thus, the properties of dynamic atomic broadcast will not be maintained through DPU. We now discuss both theoretical and practical studies about state transfer.
Theoretical Work. In [BKvRC01, LvRB+01], the authors formally characterize the distributed protocols that do not require state transfer upon DPU. Informally, the characterization states the following. Consider a protocol P that provides a ser- vice p. Protocol P does not require state transfer if interactions with a protocol Q that requires p are not influenced by past interactions with this protocol Q.
Practical Work. In [SPW03], the authors define an approach for state transfer that requires every module to implement two methods: the first one externalizes the meaningful state of the module while the second one internalizes a given state in the module. For instance, in the case of dynamic atomic broadcast module, these methods respectively returns and sets the current view of a module. Similar solutions are described in [BBI+00, KRL+00, CHS01, HLA03]. In [LC05], the authors describe a method for state transfer that uses JAVA serialization [Sun04]. Unfortunately, none of these papers formally describe the properties that are en- sured by the state transfer. This makes it difficult to reason about the correctness of DPU with such solutions.
Chapter 4
Structural Issues of Dynamic
Protocol Update
This chapter focusses on the structural dimension of DPU (see Section 3.2). More specifically, we discuss here the three following issues that are all related to the changes of the stack structure induced by DPU:
• Integration of a DPU Manager. We show in Section 4.2 that existing so- lutions do not satisfactorily integrate a DPU manager in a system. For in- stance, in [vRBH+98, CHS01], the DPU manager explicitly interacts with the updateable protocols, which leads to poor modularity. We propose a new solution and show that it has several advantages over existing solutions. • Protocol Addition. Before updating a given protocol with a new proto-
col newP , the modules of newP must be added in all stacks. This task is precisely what we call protocol addition. We define in Section 4.3 correct- ness properties for protocol addition in distributed systems. Based on these properties, we provide a simple algorithm for protocol addition.
• Protocol Removal. After having unbound the modules of the protocol P that gets replaced, modules of P may be removed from all stacks. We call this operation protocol removal. In Section 4.4, we introduce safety proper- ties which a protocol must ensure in order to be removed from the system. We then discuss the implementation of protocol removal.
4.1
Protocol Module Interactions
We consider two kinds of protocol module interactions in our theoretical work about DPU that is presented in Chapters 4 to 6: service calls and service responses (see Figure 4.1). Informally, service calls allow a module to perform requests to the services it requires. On the other hand, service responses denote interactions that correspond to replies resulting from service calls.
24 CHAPTER4. STRUCTURAL ISSUES OFDPU
Service calls. When a service q is called, the module Qi that is bound to q is
executed. If no module is bound to q, the service call is blocked until some module is bound to q.
Service responses. Consider a call to service q issued by some module Pi on
stack i. Assume that the module that is bound to q on stack i is module Qi(i.e., Qi
executes the call). We define the responses to this call to be any invocations of a module Pj by Qjin some stack j (j = i or j 6= i) that result from the initial call.1
Note that a call may result in several service responses (on the same stack or/and on different stacks).
If module Pj is not currently in stack j upon a service response, then the re-
sponse issued by Qj is delayed until Pj is added to stack j. However, we assume
that the module Qj that issues the response is not blocked while the response is
delayed. Finally, note that a module Qi can respond to a service call even if Qi is
not bound to service q at the time of the response (see module Q3in Figure 4.1).
Q2 Q3
Q1
q q
r
response response response Protocol Q 1 P P2 P3 p p q Protocol P p q q q r r call
Figure 4.1: Service calls and responses.
Figure 4.1 illustrates service calls and responses. The call of a service q made by module P1 is shown with a solid arrow. Responses to this call are represented
with dashed arrows. Note that a call to service q can be seen as an interaction within a stack that occurs between the module P1 that calls q and the module Q1
that executes the call. On the other hand, the responses to that call represents an interaction within a protocol, e.g., interaction of P1with P2and P3.