Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Highly Available and Secure Fault-tolerant Mobile Computing Sanjay K. Madria Department of Computer Science University of Missouri-Rolla

Similar presentations


Presentation on theme: "1 Highly Available and Secure Fault-tolerant Mobile Computing Sanjay K. Madria Department of Computer Science University of Missouri-Rolla"— Presentation transcript:

1 1 Highly Available and Secure Fault-tolerant Mobile Computing Sanjay K. Madria Department of Computer Science University of Missouri-Rolla

2 2 Mobile Constraints Low bandwidth. Low bandwidth. Frequent disconnections but predictable. Frequent disconnections but predictable. High bandwidth variability. High bandwidth variability. Monetarily Expensive. Monetarily Expensive. Broadcast is physically supported in a cell. Broadcast is physically supported in a cell. Limited battery power and storage. Limited battery power and storage. Fast changing locations. Fast changing locations.

3 3 MSS Fixed Host MSS Fixed Network Mbps to Gbps MH MH MH MH MH MH Cell MSS – Mobile Support Station Trusted Part MH – Mobile Host Cell Wireless connection (unreliable) Fixed and dedicated connection (reliable) Mobile Architecture.

4 4 Objectives To Improve Data Availability in Mobile Computing To Improve Data Availability in Mobile Computing - Transaction models for mobile computing - Transaction models for mobile computing (Journal Paper appeared in DPDB01) To provide Secure Fault-tolerant Mobile systems To provide Secure Fault-tolerant Mobile systems – To provide uninterrupted secure service to the mobile hosts when base station moves or fails. (Paper in IC Internet Computing00 and Research Grants of 80K)

5 5 How Mobile Transactions are different ? Long-lived transactions due to the mobility and frequent disconnection. Long-lived transactions due to the mobility and frequent disconnection. To split computations, some of which execute on mobile host while others on MSS. To split computations, some of which execute on mobile host while others on MSS. To share partial results with others. To share partial results with others. Computations and communications supported by MSS. Computations and communications supported by MSS. Mobile hosts move from one cell to another, but the execution must continue Mobile hosts move from one cell to another, but the execution must continue To maintain mutual consistency of data objects To maintain mutual consistency of data objects

6 6 Prewrite Mobile Transaction Model Introduce a prewrite operation before a write operation; makes visible (the exact or abstract) the value that data object will have after the commit of the transaction. Introduce a prewrite operation before a write operation; makes visible (the exact or abstract) the value that data object will have after the commit of the transaction. pre-committed – MT has announced all the prewrites values and read all the required data objects, but has not been finally committed (updates on database are not performed). pre-committed – MT has announced all the prewrites values and read all the required data objects, but has not been finally committed (updates on database are not performed). A pre-committed MTs results are made visible at MH and MSSs before the final commit A pre-committed MTs results are made visible at MH and MSSs before the final commit.

7 7 Shifts the resource consuming part of the MTs execution (updates of the database on disk) to the MSS. Shifts the resource consuming part of the MTs execution (updates of the database on disk) to the MSS. Pre-committed avoids costly undo or compensating action. Pre-committed avoids costly undo or compensating action. Pre-read returns a prewrite value whereas a read returns a write value. Pre-read returns a prewrite value whereas a read returns a write value. MTs are serialized based on their pre-commit order. MTs are serialized based on their pre-commit order.

8 8 Example 1: Long-duration Transaction Application House-construction and House-buying Transactions House-construction and House-buying Transactions – Model House as prewrite Example 2: Data Structure Application Record Delete Operation in Hashing Record Delete Operation in Hashing Storage allocator and deallocator to work concurrently Storage allocator and deallocator to work concurrently

9 9 Mobile Transaction Processing with Prewrites MH has limited server capability MH has limited server capability Start ________ Reads/Prewrite ________ Pre-commit ________ Writes _________ Commit Part of transaction executed at MH Part of transaction executed at MSS Example – News-reporter Transaction Example – News-reporter Transaction MH has very slow CPU and small memory; I/O device only. MH has very slow CPU and small memory; I/O device only. Example – Image Retrieval Transaction Example – Image Retrieval Transaction

10 10 Concurrent Operations Case 1: Suppose a pre-read is currently being executed at MH and at the same time, the transaction that has announced the prewrite values finally commits at MSS T1 __________ r(x),pw(x) _______ pc _______ w(x) _______ c At MSS T2 ____ pr(x) __________ c At MH T2 ____ pr(x) __________ c At MH Time Time

11 11 Case 2: Consider a case where a read transaction commits at MH after the transaction that announced the prewrite operation, has been pre-committed. T1 __________ r(x),pw(x) _______ pc _______ w(x) ________ c At MSS T2 __________ r(x) __________ c At MH T2 __________ r(x) __________ c At MH Time Time

12 12 Operation Compatibility Matrix Pre-read Read Pre-write Write Pre-read Yes No Yes Read Yes No Pre-write No Yes No Yes Write Yes No Yes No

13 13 Performance (Simulation Parameters) System Parameters DescriptionValue DB-size Average size of the database 500 Num-MH Number of MHs Simulation parameter Num-MSS Number of MSSs 2 Trans-size Average no. of objects per transaction 6 objects Pre-value-size Average size of pre-write values 1/40 of write value Max-Size Maximum number of objects per transaction 10 objects Min-Size Minimum number of objects per transaction 2 objects Local-object-MH Ratio of objects found in cache at MH 0.4 CPU-time Time taken by CPU per request 12 msec

14 14 Simulation Parameters (Table continued) I/O Time Time taken by I/O per request both at MSS and MH 30 msec Num-transactions- MSS Transactions at each MSS Simulation parameter Wireless-bandwidth Data transfer rate from MH to MSS 0.5 Mbps Write-prob Probability that object read will be written also Simulation parameter Trans-delay Inter-arrival delay time 500 msecs Prewrite-to-write Delay in write 0.2 msecs

15 15 Throughput v/s MPL

16 16 Throughput v/s MPL

17 17 Transaction-Abort-ratio v/s MPL

18 18 Transaction-Abort-ratio v/s MPL

19 19 Serializable Schedules in Mobile Transaction Model Case 1: In case of simple data objects, a history with a prewrite is same as the history without a prewrite. Case 2: Once a transactions prewrite-lock is updated to the write-lock, it can not acquire any other lock. Case 3: A prewrite-lock can not be updated to a write-lock if some other transaction is holding a conflicting lock. Case 4: A transaction, which returns an old value, can be serialized in the history

20 20 Multi-version Model to Exploit Availability in Mobile Computing Start State, Commit, Termination Start State, Commit, Termination MH process ops, but Terminate at MSS MH process ops, but Terminate at MSS One Terminated version, but many committed version One Terminated version, but many committed version MSS terminates them in–order of commitment MSS terminates them in–order of commitment

21 21 Read-write Availability MH MSS X i 0 X j ts(j) X i 0 Z k ts(k) --- Z i 0 Z k ts(k) Z k ts(k) --- Z i 0 Z k ts(k) Transaction T j Transaction T k terminate commit

22 22 Write-Write Availability MH MSS X k ts(k) X j ts(j) X i 0 X k ts(k) Z k ts(k) --- Z i 0 Z k ts(k) Z k ts(k) --- Z i 0 Z k ts(k) Transaction T j Transaction T k Two committed versions

23 23 Fault Tolerant Authentication in Mobile Computing

24 24 Objective To provide uninterrupted secure service to the mobile hosts when base station moves or fails. To provide uninterrupted secure service to the mobile hosts when base station moves or fails. – Example – Battle Field

25 25 Mobile IP Entities Mobile Host (MH) - Changes its point of attachment to the internet from one link to another. Mobile Host (MH) - Changes its point of attachment to the internet from one link to another. Home Agent (HA) - Router on MHs home network which tunnels datagrams (packets of data) to MH when it is away from home. Home Agent (HA) - Router on MHs home network which tunnels datagrams (packets of data) to MH when it is away from home. Foreign Agent (FA) - Router on MHs visited network which provides routing services to the MH while registered. Foreign Agent (FA) - Router on MHs visited network which provides routing services to the MH while registered.

26 26 To ensure security and theft of resources (like bandwidth), all the packets originating inside the network should be authenticated. To ensure security and theft of resources (like bandwidth), all the packets originating inside the network should be authenticated. MH sends a packet to its HA along with the authentication information. MH sends a packet to its HA along with the authentication information. Authentication is successful-> HA forwards the packet. Otherwise, dropped. Authentication is successful-> HA forwards the packet. Otherwise, dropped. Arbitrary Topology Mobile Node Internet Home Agent Authentication and Forwarding Services

27 27 Disadvantages of Typical Setup Home Agent becomes a single point of failure. Home Agent becomes an attractive spot for attackers. Not scalable – large number of hosts overload the Home Agent.

28 28 Research Goals Eliminate the single point of failure. Distribute the load and enhance scalability and survivability of the system. Failures -- transparent to applications Easy to implement

29 29 Traditional Approaches Using a Proxy Server that takes up the responsibilities of the Base Station Using a Proxy Server that takes up the responsibilities of the Base Station Using a Second Base Station that forwards the packets to the actual Home Agent, using Mobile IP, which is now at a Foreign Network. Using a Second Base Station that forwards the packets to the actual Home Agent, using Mobile IP, which is now at a Foreign Network.

30 30 Proxy-based solution BS1 BS Source Network Arbitrary Network Foreign Network Arbitrary Network Destination Network

31 31 Traditional Approaches Disadvantages: Disadvantages: Manual updating of the routing tables Manual updating of the routing tables Not transparent to applications Not transparent to applications Communication Delays Communication Delays Additional security threats as the packets now traverse long paths through Internet. Additional security threats as the packets now traverse long paths through Internet.

32 32 Proposed Schemes We propose two schemes: – Virtual Home Agent – Hierarchical Authentication They differ in the architecture and the responsibilities that the Mobile Hosts and Base Stations hold.

33 33 Authentication Using Virtual Home Agent Entities in the proposed scheme Virtual Home Agent(VHA) is an abstract entity identified by a network address. Master Home Agent(MHA) is the physical entity that carries out the responsibilities of the VHA.

34 34 Authentication Using Virtual Home Agent Backup Home Agent(BHA) is the entity that backs-up a VHA. When MHA fails, BHA having the highest priority becomes MHA. Shared Secrets Database Server is the entity that manages and processes the queries on the secret database.

35 35 Virtual Home Agent Set up Shared Secrets Database Database Server Master Home Agent(MHA) Backup Home Agents VHA ID = IP ADDR1 Other hosts in the network

36 36 Protocol Description All the MHAs and BHAs join a pre- configured multicast group. All the MHAs and BHAs join a pre- configured multicast group. MHA and each BHA is assigned a priority that indicates its preference to become a MHA, when the current MHA fails. MHA and each BHA is assigned a priority that indicates its preference to become a MHA, when the current MHA fails. MHA has the highest priority at any given point of time. MHA has the highest priority at any given point of time.

37 37 Protocol Description Periodically, MHA sends an advertisement packet to the configured multicast group. Periodically, MHA sends an advertisement packet to the configured multicast group. Purpose of this advertisement packet is to let the BHAs know that MHA is still alive Purpose of this advertisement packet is to let the BHAs know that MHA is still alive Time-to-live is set to 1 in each advertisement as they never have to be transmitted outside the network. Time-to-live is set to 1 in each advertisement as they never have to be transmitted outside the network.

38 38 Protocol Description Advertisement Packet Format Advertisement Packet Format VHAs ID indicates the VHA that this Agent is the Master. VHAs ID indicates the VHA that this Agent is the Master. MHAs priority is the priority of this MHA. MHAs priority is the priority of this MHA. Authentication Information is necessary to void the masquerading attacks (i.e. anybody posing as a Master after compromising it). Authentication Information is necessary to void the masquerading attacks (i.e. anybody posing as a Master after compromising it). VHAs ID MHAs priority Authentication Information

39 39 Protocol Description BHAs only listen for advertisements, they do not send the advertisements. BHAs only listen for advertisements, they do not send the advertisements. If a BHA did not receive any advertisement for some period, starts the Down Interval Timer, computed as follows If a BHA did not receive any advertisement for some period, starts the Down Interval Timer, computed as follows Down Time Interval = 5*Advertisement Interval + ((MHAs priority-BHAs priority)/MHAs priority) Down Time Interval = 5*Advertisement Interval + ((MHAs priority-BHAs priority)/MHAs priority)

40 40 Protocol Description Down Interval Time takes care of packet losses (as it is atleast 5 advertisement intervals) Down Interval Time takes care of packet losses (as it is atleast 5 advertisement intervals) Down Interval Time is a function of BHAs configured priority (if the priority is more, Down Interval Time is less). Down Interval Time is a function of BHAs configured priority (if the priority is more, Down Interval Time is less).

41 41 Protocol Description Down Interval Timer of the BHA having the highest priority will expire first and that guarantee BHA transitions from BHA to MHA. Down Interval Timer of the BHA having the highest priority will expire first and that guarantee BHA transitions from BHA to MHA. New MHA sends advertisements from now onwards. New MHA sends advertisements from now onwards.

42 42 Protocol Description Advantages of this Election Protocol No communication between the BHAs is required. No communication between the BHAs is required. There is no confusion about which BHA becomes MHA (only the one whose timer expires first) There is no confusion about which BHA becomes MHA (only the one whose timer expires first) No additional security threats (like manipulating priorities of BHAs) No additional security threats (like manipulating priorities of BHAs)

43 43 Protocol Description Start State Backup State Master State State Transitions

44 44 Advantages of the proposed scheme Has only 3 states and hence the overhead of state maintenance is negligible. Has only 3 states and hence the overhead of state maintenance is negligible. Very few tasks need to be performed in each state Very few tasks need to be performed in each state Flexible – there could be multiple VHAs in the same LAN and a MHA could be a BHA for another VHA, a BHA could be a BHA for more than one VHA at the same time. Flexible – there could be multiple VHAs in the same LAN and a MHA could be a BHA for another VHA, a BHA could be a BHA for more than one VHA at the same time.

45 45 Hierarchical Authentication Scheme Multiple Home Agents in a LAN are organized in a hierarchy (like a tree data structure). Multiple Home Agents in a LAN are organized in a hierarchy (like a tree data structure). A Mobile Host shares a key with each of the Agents above it in the tree (Multiple Keys). A Mobile Host shares a key with each of the Agents above it in the tree (Multiple Keys). At any time, highest priority key is used for sending packets or obtaining any other kind of service. At any time, highest priority key is used for sending packets or obtaining any other kind of service.

46 46 Hierarchical Authentication Scheme A BC DEFG K1 K2 Database (K1, P1) (K2, P2)

47 47 Hierarchical Authentication Scheme Key Priority depends on several factors and computed as cumulative sum of weighted priorities of each factor. Example factors: Communication Delays Communication Delays Processing Speed of the Agents Processing Speed of the Agents Secret Key Usage Secret Key Usage Life Time of the Key Life Time of the Key Configurable Priorities Configurable Priorities Availability of secret key information to an Agent Availability of secret key information to an Agent

48 48 Hierarchical Authentication Scheme Hosts detect the Home Agents failure or mobility when the Home Agent does not send an acknowledgement for a request. Hosts detect the Home Agents failure or mobility when the Home Agent does not send an acknowledgement for a request. When the failure is detected, host reduces the priority of the current key and picks up highest priority key to be used now onwards. When the failure is detected, host reduces the priority of the current key and picks up highest priority key to be used now onwards.

49 49 VHA Scheme Flat structure Host has only one key Failure is transparent to the user Hierarchical Scheme Tree structure number of keys depend on height of the tree. Hosts should be aware of the failure of BS as which key to be used depends on the base station serving it. No Priority is assigned to the keys Each key has priority, the key with the highest priority is used for authentication.

50 50 Cluster for scalability Front End Back-end Clients Requests Request Distribution One IP Add.

51 51 Locality-Aware Request Distribution R1,R1,R1,R2,R3,R2,R1,R1,R2,R3 Front-end node Back-end nodes R1,R1,R1,R1,R1 R2,R3,R2,R2,R3 R1 Cache R2, R3 Cache

52 52 Back-end Forwarding HostFront-end Back-end nodes Forwarded Request

53 53 Request Redirection 1. Request Front End 2. Redirect to Back End Back-end 3. Redirected Request

54 54 Conclusions Discuss Transactions design to Increase Data Availability (Application Oriented) Flat-model and tree based schemes for fault-tolerant authentication in mobile environment (System Oriented)

55 55 Future work Quantifying the priorities for each factor and computing the overall key priority as a weighted function of all these factors. Quantifying the priorities for each factor and computing the overall key priority as a weighted function of all these factors. Designing a adaptable replication and partitioning scheme for secret keys that increases the system performance. Designing a adaptable replication and partitioning scheme for secret keys that increases the system performance. Simulation of these approaches and obtaining performance statistics. Simulation of these approaches and obtaining performance statistics.

56 56 Current Projects WAP and WML for Web Engineering on Mobile Platforms – Different Approach to Content Management and caching – Developing Device dependent Software for web Access (minimum number of clicks, textual input, reduce latency) – Requirement Engineering (capturing, structuring, and accurately representing users requirements) Data, operational, functional constraints – Performance and Design constraints

57 57 References IP Mobility Support - RFC Group Key Management Protocol (GKMP) Architecture - RFC Key Management for multicast : Issues and Architectures - RFC Secure Group Communications using Key Graphs, Chung Kei Wong, Md. Gouda

58 58 Concurrency Control and Locking Pre-Read-Lock(X): Grant the requested pre-read-lock to a transaction T on X if no other transaction holds a prewrite- lock on X. Read-Lock(X): Grant the requested read-lock to a transaction T on X if no other transaction holds a write-lock on X. Prewrite-Lock(X): Grant the prewrite-lock to a transaction T on X if no other transaction holds are Prewrite- or pre-read-lock on X. (continued……….)

59 59 Write-Lock(X): Update a prewrite-lock on X held by a transaction T to write-lock if Begin If the write-lock-wait queue for X is empty then Begin Begin If the transaction T is pre-committed and no other transaction holds a read-or write-lock on X then convert prewrite-lock to write-lock; If the transaction T is pre-committed and no other transaction holds a read-or write-lock on X then convert prewrite-lock to write-lock; End; End; else else Begin Begin put the transaction T in a write-lock-wait queue for X; put the transaction T in a write-lock-wait queue for X; End; End;End.

60 60 Serializable Schedules in Mobile Transaction Model 1. T i { pr i (x), r i (x), pw i (x), w i (x) x is a design object} {pc i, c i, a i } 2. If a i T i if and only if pc i T i and c i T i 3. If it is c i or a i then for any other operation p T i, p < i t and if t is pc i, then pc i < i c i. 4. If pr i (x), r i (x), pw i (x), w i (x) T then either pr i (x) < i w i (x), or w i (x) < i r i (x), or r i (x) < i w i (x), pw i (x) < i pr i (x) or pw i (x) < i w i (x), or pr i (x) < i r i (x). Consider a set of transactions in T=(T 1, T 2 …… T n ) which are modeled by a structure called a history. Formally [BHG], a history H over T is a partial order (, < n ) where i) H = n U i=1 T i ; i) H = n U i=1 T i ; ii) < H n U i=1 < i ; and ii) < H n U i=1 < i ; and iii) for any two conflicting operations p and q either p < H q or q < H p. iii) for any two conflicting operations p and q either p < H q or q < H p.

61 61 Case 1: In this case we consider simple data objects and see that a history with a prewrite is same as the history without a prewrite. Consider the following history H: pwl 1 (x)pw 1 (x)rl 2 (x)r 1 (x)rul 1 (x)c 2 pc 1 (pwl 1 (x) wl 1 (x))prl 3 (x)pr 3 (x) prul 3 (x)c 3 w 1 (x)wul 1 (x)c 1 After taking into account these commutative operations, the above history will be Equivalent to: rl 2 (x)r 2 (x)rul 2 (x)c 2 pwl 1 (x)pw 1 (x)pc 1 (pwl 1 (x) wl 1 (x)) prl 3 (x) pr 3 (x) prul 3 (x)c 3 w 1 (x) wul 1 (x)c 1 Consider another history H: pwl 1 (x)pw 1 (x)rl 2 (x)r 2 (x)rul 2 (x)c 2 pc 1 (pwl 1 (x) wl 1 (x))pwl 3 (x)pw 3 (x) pc 3 w 1 (x)wul 1 (x)c 1 (pwl 3 (x) wl 3 (x))wl 3 (x)wul 3 (x)c 3

62 62 Case 2: In this case we see that once a transactions prewrite-lock is updated to the write-lock, it can not acquire any other lock. Consider the following history: pwl 1 (x)pw 1 (x)pc 1 (pwl 1 (x) wl 1 (x))prl 2 (x)pr 2 (x)pwl 2 (y)pw 2 (y)pc 2 (pwl 2 (y) wl 2 (y))w 2 (y)prul 2 (x) wul 2 (x)c 2 w 1 (x) rl 1 (y)r 1 (y)rul 1 (y)wul 1 (x)c 1 Case 3: In this case, we see that a prewrite-lock can not be updated to a write-lock if some other transaction is holding a conflicting lock. Consider a partial history: rl 1 (x)r 1 (x) pwl 1 (x) pw 1 (x)rl 2 (x)r 2 (x) pc 1 (pwl 1 (x) wl 1 (x)) rl 1 (x)r 1 (x) pwl 1 (x) pw 1 (x)rl 2 (x)r 2 (x) pc 1 (pwl 1 (x) wl 1 (x)) Consider another partial history: pwl 1 (x) pw 1 (x) pc 1 (pwl 1 (x) wl 1 (x)) plw 2 (x) pw 2 (x)w 1 (x) pc 2 (pwl 2 (x) w 2 (x)) Case 4: In this case, we see that a transaction, which returns an old value, can be serialized in the history. Consider a history: rl 1 (x)r 1 (x)pwl 1 (x) pw 1 (x)rl 2 (x)r 2 (x)pc 1 rul 2 (x)c 2 (pwl 1 (x) wl 1 (x))

63 63 Proof of Correctness Property 1: If o is an operation then ol(x) < o(x) < ou(x). Property 2: If p i (x) and q i (y) are two operations under T i then pl i (x) < qul i (y), i.e., for all lock operations l i T i and un-lock operations ul i T i, l i < ul i Property 3: If (pwl i (x) wl i (x)) T i then 1) For any operational ol i T i, ol i < i (pwl i (x) wl i (x)). That is, once a prewrite-lock is converted to a write-lock, no other operation can lock any data object. 2) For any operational pul i T i, (pwl i (x) wl i (x)) < pul i (x). That is, a prewrite-lock is converted to a write-lock before any lock is released. That is, a prewrite-lock is converted to a write-lock before any lock is released.

64 64 Property 4: If p i (x) and q j (x) are two conflicting operations then either 1) pul i (x) < H ql j (x). If p i (x) is a prewrite operation then (pwl i (x) wl i (x)) < H ql j (x). If p i (x) is a read operation then pul j (x) < H (pwl j (x) wl j (x)). or If p i (x) is a read operation then pul j (x) < H (pwl j (x) wl j (x)). or 2) qul j (x) < H pl i (x). If q j (x) is a prewrite operation then (pwl j (x) wl j (x)) < H pl i (x). If q j (x) is a read operation then qul j (x) < H (pwl i (x) wl i (x)). If q j (x) is a read operation then qul j (x) < H (pwl i (x) wl i (x)). Property 5: If pc i and c i are pre-commit and commit then pc i < i c i in T i and for any pc j, if pc i < pc i then c i < c i. However, if the transaction T j is a read-only transaction and pc i < pr j then c j < c i or c i < c j. Property 6: If pc i T i then no a i T i. Property 7: If pw i (x), w i (x) T i and pw j (x), w j (x) T j and if T i T j then 1) If pwl i (x) < pwl j (x) then wl i (x) < wl j (x). 2) If wl i (x) < pwl j (x) then pwl j (x) < w i (x) < wl j (x) or wl i (x) < pw j (x) < w j (x).

65 65 Lemma 1: If T 1 T 2 in SG(H) then there exists an unlock operation pul 1 T 1 or a lock convert operation (pwl 1 wl 1 ) T 1 such that for all lock operations ql 2 T 2 or a lock convert operation (pwl 2 wl 2 ) T 2, pul 1 (x) < ql 2 (x) or (pwl 1 (x) wl 1 (x))< ql 2 (x) or pul 1 (x) < (pwl 2 (x) wl 2 (x)). Lemma 2: Let T 1 T 2 …. T n be a path in SG(H) where n>1. Then for data objects x and y and some operations p 1 (x) and q n (y) in H, pu 1 (x) 1. Then for data objects x and y and some operations p 1 (x) and q n (y) in H, pu 1 (x)< ql n (y) or (pwl 1 (x) wl 1 (x))< ql n (y) or pul 1 (x) < (pwl n (y) wl n (y)). Theorem : Every history H obtained by the locking protocols given before is serializable.


Download ppt "1 Highly Available and Secure Fault-tolerant Mobile Computing Sanjay K. Madria Department of Computer Science University of Missouri-Rolla"

Similar presentations


Ads by Google