Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 A Programming model for failure- prone, Collaborative robots Nels Eric Beckman Jonathan Aldrich School of Computer Science Carnegie Mellon University.

Published by Modified over 9 years ago

Similar presentations

Presentation on theme: "1 A Programming model for failure- prone, Collaborative robots Nels Eric Beckman Jonathan Aldrich School of Computer Science Carnegie Mellon University."— Presentation transcript:

1 1 A Programming model for failure- prone, Collaborative robots Nels Eric Beckman Jonathan Aldrich School of Computer Science Carnegie Mellon University SDIR 2007 April 14 th, 2007

2 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 2 Failure Blocks: Increasing Application Liveness In the Claytronics domain, failure will be commonplace. Certain Applications: Failure of one catom causes others to be useless. Our model: An extension to remote procedure calls. Helps developers preserve liveness. Developers Signify where liveness is a concern. Specify liveness preserving actions. When failure is automatically detected, those actions are taken.

3 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 3 Outline In our domain, the rate of failure will be high ‘Hole Motion’ (An example failure scenario) Existing RPC systems do not help us to preserve liveness Our model has two key pieces The failure block The compensating action

4 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 4 Rate of Failure in Catoms will be High Due to the large numbers involved: Per-unit cost must be low, which implies A lack of hardware error detection features. Rate of mechanical imperfections will be high. Probability of some catom failing becomes high. Interaction with the physical world: Dust particles? Other unintended interactions?

5 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 5 Outline In our domain, the rate of failure will be high ‘Hole Motion’ (An example failure scenario) Existing RPC systems do not help us to preserve liveness Our model has two key pieces The failure block The compensating action

6 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 6 The Hole Motion* Algorithm A Motion-Planning Technique The Idea: Randomly send holes through the mass of catoms. Holes ‘stick’ to areas that should shrink. They are more likely to be created from areas that should grow. *De Rosa, Goldstein, Lee, Campbell, Pillai. Scalable Shape Sculpting Via Hole Motion: Motion Planning in Lattice-Constrained Modular Robots. IEEE ICRA 2006. May 2006.

7 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 7 In Detail... At each ‘hole time- step,’ catoms around the hole have a leader. They only accept commands from this leader. This protects the hole’s integrity. L

8 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 8 In Detail... In order to become the ‘leader,’ this catom calls ‘setLeader’ on its neighbors. The same method is called recursively on other would-be group members. L nextCatom->setLeader(me);

9 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 9 In Detail... Catom on the stack fails: Catoms i and j may have already set L as their leader! But the only communication path to L is gone. Lg i j nextCatom->setLeader(me);

10 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 10 In Detail... Instead, suppose operation returned normally... L

11 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 11 In Detail... Instead, suppose operation returned normally... L

12 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 12 In Detail... Instead, suppose operation returned normally... L

13 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 13 In Detail... Instead, suppose operation returned normally... L

14 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 14 In Detail... Instead, suppose operation returned normally... L

15 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 15 In Detail... Now L fails: Catoms g-j (and all the rest) expect commands from L! For all practical purposes, 12 catoms have failed. Lgh i j

16 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 16 Outline In our domain, the rate of failure will be high ‘Hole Motion’ (An example failure scenario) Existing RPC systems do not help us to preserve liveness Our model has two key pieces The failure block The compensating action

17 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 17 Existing RPC Systems, Not a Perfect Fit Weak Failure Detection Usually a timeout mechanism. Our model uses active failure detection. No Callee-Side Failure Handling Caller can catch timeout exception; not callee. But the callee could be left in an invalid state. Our model provides callee with compensating actions.

18 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 18 Existing RPC Systems, Not a Perfect Fit Only detect failure on the stack of RPC calls. Our model designates catoms as being a part of the group for a lexical ‘amount of time.’ They are still a part of this group when the thread moves to a different location. Failures on the stack and off are dealt with in the same manner.

19 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 19 Outline In our domain, the rate of failure will be high ‘Hole Motion’ (An example failure scenario) Existing RPC systems do not help us to preserve liveness Our model has two key pieces The failure block The compensating action

20 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 20 The Model: Two Key Pieces fail_block, which specifies The logical ‘time period’ during which live- ness concerns exist The members of the group (implicitly) Where control should return in the event of a failure push_comp, which allows The specification of code to be executed in the event of catom failure

21 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 21 The fail_block Primitive fail_block b Evaluates the code in block b. In the event of a detected failure The entire block throws an exception. Execution continues from the catom where the failure block is evaluated.

22 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 22 The fail_block Primitive At runtime, the entire operation is given a unique ‘operation ID.’ When a RPC is called from within block Callee becomes ‘part’ of the operation. Callee and caller add one another as collaborators. They ‘ping’ each other regularly to detect failure. Applies recursively. In the event a failure is detected, they share the information about the demise of that operation.

23 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 23 The fail_block Primitive If b is successfully executed An ‘end’ message is sent out. Collaborators stop detecting failure for that OID.

24 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 24 ‘Demo’ fail_block { // catom 1 lnode->setBoss(this); rnode->setBoss(this); }... setBoss(Catom h) myLeader = h; } Group Members: {} Op ID: Failure Detect 1 2 4 3

25 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 25 ‘Demo’ fail_block { // catom 1 lnode->setBoss(this); rnode->setBoss(this); }... setBoss(catom h) { myLeader = h; } Group Members: {1} Op ID: 23423123 1 2 4 3 Failure Detect

26 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 26 ‘Demo’ fail_block { // catom 1 lnode->setBoss(this); rnode->setBoss(this); }... setBoss(catom h) { myLeader = h; } Group Members: {1,2} Op ID: 23423123 1 2 4 3 Failure Detect

27 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 27 ‘Demo’ fail_block { // catom 1 lnode->setBoss(this); rnode->setBoss(this); }... setBoss(catom h) { myLeader = h; } Group Members: {1,2,4} Op ID: 23423123 1 2 4 3 Failure Detect

28 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 28 ‘Demo’ fail_block { // catom 1 lnode->setBoss(this); rnode->setBoss(this); }... setBoss(catom h) { myLeader = h; } Group Members: {1,2,4} Op ID: 23423123 1 2 4 3 end 23423123 Failure Detect

29 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 29 The push_comp Primitive push_comp b On whichever catom it is called: Suspend code in block b. This code will be evaluated (purely for its side- effects) in the event that a failure is detected. Called ‘compensating actions*’ or ‘compensations.’ *Westley Weimer and George C. Necula. Finding and preventing runtime error handling mistakes. In OOPSLA ’04: Proceedings of the 19 th annual ACM SIGPLAN conference on Object- oriented programming, systems, languages, and applications, pages 419–431, New York, NY, USA, 2004. ACM Press.

30 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 30 The push_comp Primitive Each catom has several stacks of compensations, one for each OID, and compensating actions are executed from top to bottom. OID: i OID: jOID: n......

31 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 31 The push_comp Primitive OID: i OID: jOID: n...... e_1 push_comp e_1 Each catom has several stacks of compensations, one for each OID, and compensating actions are executed from top to bottom.

32 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 32 The push_comp Primitive OID: i OID: jOID: n...... e_1 push_comp e_2 e_2 Each catom has several stacks of compensations, one for each OID, and compensating actions are executed from top to bottom.

33 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 33 The push_comp Primitive OID: i OID: jOID: n...... e_1 push_comp e_3 e_2 e_3 Each catom has several stacks of compensations, one for each OID, and compensating actions are executed from top to bottom.

34 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 34 The push_comp Primitive OID: i OID: jOID: n...... e_1 FAILURE OID i!! e_2 e_3 Each catom has several stacks of compensations, one for each OID, and compensating actions are executed from top to bottom.

35 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 35 The push_comp Primitive OID: i OID: jOID: n...... e_1 e_2 e_3.run() Each catom has several stacks of compensations, one for each OID, and compensating actions are executed from top to bottom.

36 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 36 The push_comp Primitive OID: i OID: jOID: n...... e_1 e_2.run() Each catom has several stacks of compensations, one for each OID, and compensating actions are executed from top to bottom.

37 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 37 The push_comp Primitive OID: i OID: jOID: n...... e_1.run() Each catom has several stacks of compensations, one for each OID, and compensating actions are executed from top to bottom.

38 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 38 ‘Demo,’ Continued fail_block { // catom 1 lnode->recurse(this,LEFT); rnode->recurse(this,RIGH); } recurse(catom ldr,Dir d){ myLeader = ldr; push_comp( myLeader = -1);... nnode->recurse(lead); } 1 2 4 3

39 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 39 ‘Demo,’ Continued fail_block { // catom 1 lnode->recurse(this,LEFT); rnode->recurse(this,RIGH); } recurse(catom ldr,Dir d){ myLeader = ldr; push_comp( myLeader = -1);... nnode->recurse(lead); } 1 2 4 3

40 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 40 ‘Demo,’ Continued fail_block { // catom 1 lnode->recurse(this,LEFT); rnode->recurse(this,RIGH); } recurse(catom ldr,Dir d){ myLeader = ldr; push_comp( myLeader = -1);... nnode->recurse(lead); } 1 2 4 3 FAI L

41 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 41 ‘Demo,’ Continued fail_block { // catom 1 lnode->recurse(this,LEFT); rnode->recurse(this,RIGH); } recurse(catom ldr,Dir d){ myLeader = ldr; push_comp( myLeader = -1);... nnode->recurse(lead); } 1 2 4 3 FAI L

42 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 42 ‘Demo,’ Continued fail_block { // catom 1 lnode->recurse(this,LEFT); rnode->recurse(this,RIGH); } recurse(catom ldr,Dir d){ myLeader = ldr; push_comp( myLeader = -1);... nnode->recurse(lead); } 1 2 4 3 FAI L

43 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 43 try { fail_block { // catom 1 lnode->recurse(this,LEFT); rnode->recurse(this,RIGH); } } catch(OpFailure) {...} recurse(catom ldr,Dir d){ myLeader = ldr; push_comp( myLeader = -1);... nnode->recurse(lead); } ‘Demo,’ Continued 1 2 4 3

44 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 44 Conclusion Failure Blocks An extension to RPC for recovering from node failures. Within a failure block RPC calls add the callee to the current operation. Callee and caller detect failure in one another. Compensating actions can be stored, executed in the event of failure. Targeted at modular robotic systems where failure is high but availability is important.

45 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 45 References N. Beckman and J. Aldrich. A Programming Model for Failure-Prone, Collaborative Robots. To appear in the 2nd International Workshop on Software Development and Integration in Robotics (SDIR). Rome, Italy. April 14, 2007. De Rosa, Goldstein, Lee, Campbell, Pillai. Scalable Shape Sculpting Via Hole Motion: Motion Planning in Lattice-Constrained Modular Robots. IEEE ICRA 2006. May 2006. Achour Mostefaoui, Eric Mourgaya, and Michel Raynal. Asynchronous implementation of failure detectors. In 2003 International Conference on Dependable Systems and Networks (DSN’03), page 351, 2003. Westley Weimer and George C. Necula. Finding and preventing runtime error handling mistakes. In OOPSLA ’04: Proceedings of the 19 th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, pages 419–431, New York, NY, USA, 2004. ACM Press. Michel Reynal. A short introduction to failure detectors for asynchronous distributed systems. SIGACT News, 36(1):53–70, 2005.

46 46 The end

47 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 47 Scenario One 123

48 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 48 Scenario One 123 host2->foo()

49 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 49 Scenario One 123

50 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 50 Scenario One 123 host3->bar()

51 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 51 Scenario One 123

52 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 52 ‘Demo’ fail_block { (* host 1 *) host2->foo(); host4->bar(); }... foo() { host3->doWork(h1); } 1 4 23 Group Members: {} Op ID: Regular Ping

53 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 53 ‘Demo’ fail_block { (* host 1 *) host2->foo(); host4->bar(); }... foo() { host3->doWork(h1); } 1 4 23 Group Members: {1} Op ID: 3435435 Regular Ping

54 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 54 ‘Demo’ fail_block { (* host 1 *) host2->foo(); host4->bar(); }... foo() { host3->doWork(h1); } 1 4 23 Group Members: {1,2} Op ID: 3435435 Regular Ping

55 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 55 ‘Demo’ fail_block { (* host 1 *) host2->foo(); host4->bar(); }... foo() { host3->doWork(h1); } 1 4 23 Group Members: {1,2,3} Op ID: 3435435 Regular Ping

56 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 56 ‘Demo’ fail_block { (* host 1 *) host2->foo(); host4->bar(); }... foo() { host3->doWork(h1); } 1 4 23 Group Members: {1,2,3,4} Op ID: 3435435 Regular Ping

57 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 57 ‘Demo’ fail_block { (* host 1 *) host2->foo(); host4->bar(); }... foo() { host3->doWork(h1); } Group Members: {} Op ID: Regular Ping 1 4 23 end 3435435!

58 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 58 At a Macroscopic Level... (Video)

59 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 59 ‘Demo,’ Continued... doWork(HostAddr a) { myLeader = a; push_comp { if(myLeader == a) myLeader = null; }... 1 4 23 Failure!

60 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 60 ‘Demo,’ Continued... doWork(HostAddr a) { myLeader = a; push_comp { if(myLeader == a) myLeader = null; }... 1 4 23 myLeade r = null;...

61 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 61 Outline The Rate of Failure Will be High Two Failure Scenarios We Would Like to Handle Existing RPC Systems Do Not Meet Our Needs Our Model Has Two Key Pieces fail_block push_comp Our Model Does Not Require Consistency

62 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 62 Our System Does Not Require Consistency Our model has a nice feature: We do not require consistency in failure detection! This has been proven to be impossible in ‘time-free’ systems.

63 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 63 What is Consistency? fail_block { (* host 1 *) host2->foo(); host4->bar(); }... foo() { host3->doWork(h1); } 1 4 23

64 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 64 What is Consistency? fail_block { (* host 1 *) host2->foo(); host4->bar(); }... foo() { host3- >doWork(h1); } OID: 9, failure! OID: 9, end! 1 4 23

65 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 65 Our System Does Not Require Consistency Domain Assumption: The ultimate goal of any application is to perform actuator movements. Additionally, The thread of control must migrate to a catom in order to issue an actuator command. If a thread migrates to a catom that has detected or knows about a failure, that thread will not continue normally.

66 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 66 Our System Does Not Require Consistency Therefore, if inconsistency occurs, we know: In between detection and fail_block completion, no actuator movements were necessary on any hosts that knew about the failure. In the sense that actuator movements are the ultimate goal in the domain, their work was already done.

67 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 67 Our System Does Not Require Consistency What if we won’t make an actuator movement on a host, but we need to know it performed its duty? E.g., structural catoms This is a question of live-ness versus other goals. fail_block should be used precisely when live-ness is a chief concern.

68 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 68 Assumptions Movement: When a movement occurs, you are required to talk with these surrounding hosts and they will be able to figure out the new location to ping. Goals: Actuator movements are the ultimate goal of most applications in this domain.

69 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 69 What about Transactions? Semantics of roll-back suggest a transactional model. Similarly, it seems that Two-Phase commit could give us consistency. But 2PC has one or two extra rounds of communication Application doesn’t make progress! Our model has no extra blocking rounds. 2PC can block indefinitely if the coordinator fails In non-blocking protocols the number of failures is bounded. It is not clear how error detection and 2PC could be combined.

70 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 70 In Detail... But, after this field has been set, failure of the leader leaves the catoms in a dead state. L

71 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 71 The push_comp Primitive We call this suspended code ‘compensating actions.’ Borrowed terminology from Weimar and Necula. Originally used to ensure proper clean-up for file handlers, etc. in exceptional circumstances. (However, our compensating actions are only executed when a failure is detected.)

72 SDIR07: A Programming Model for Failure-Prone Collaborative Robots 72 Why Server-Side Failure Handling? The client may think the server has failed, when it hasn’t. Allow server to return to a stable state. Failure detectors unreliable in ‘time-free’ systems. The client may have failed. An catom on the return route may have failed.

Download ppt "1 A Programming model for failure- prone, Collaborative robots Nels Eric Beckman Jonathan Aldrich School of Computer Science Carnegie Mellon University."

Similar presentations

Dr. Kalpakis CMSC 621, Advanced Operating Systems. Fall 2003 URL: Distributed System Architectures.

Dr. Kalpakis CMSC 621, Advanced Operating Systems. Fall 2003 URL: Distributed System Architectures.
Replication. Topics r Why Replication? r System Model r Consistency Models r One approach to consistency management and dealing with failures.

Replication. Topics r Why Replication? r System Model r Consistency Models r One approach to consistency management and dealing with failures.
RPC Robert Grimm New York University Remote Procedure Calls.

RPC Robert Grimm New York University Remote Procedure Calls.
Department of Computer Science and Engineering University of Washington Brian N. Bershad, Stefan Savage, Przemyslaw Pardyak, Emin Gun Sirer, Marc E. Fiuczynski,

Department of Computer Science and Engineering University of Washington Brian N. Bershad, Stefan Savage, Przemyslaw Pardyak, Emin Gun Sirer, Marc E. Fiuczynski,
Distributed System Structures Network Operating Systems –provide an environment where users can access remote resources through remote login or file transfer.

Distributed System Structures Network Operating Systems –provide an environment where users can access remote resources through remote login or file transfer.
Remote Procedure Call Design issues Implementation RPC programming

Remote Procedure Call Design issues Implementation RPC programming
1 Fault-Tolerance Techniques for Mobile Agent Systems Prepared by: Wong Tsz Yeung Date: 11/5/2001.

1 Fault-Tolerance Techniques for Mobile Agent Systems Prepared by: Wong Tsz Yeung Date: 11/5/2001.
Ivan Lanese Computer Science Department University of Bologna/INRIA Italy Fault in the Future Joint work with Gianluigi Zavattaro and Einar Broch Johnsen.

Ivan Lanese Computer Science Department University of Bologna/INRIA Italy Fault in the Future Joint work with Gianluigi Zavattaro and Einar Broch Johnsen.
COS 461 Fall 1997 Where We Are u so far: networking u rest of semester: distributed computing –how to use networks to do interesting things –connection.

COS 461 Fall 1997 Where We Are u so far: networking u rest of semester: distributed computing –how to use networks to do interesting things –connection.
Consensus Algorithms Willem Visser RW334. Why do we need consensus? Distributed Databases – Need to know others committed/aborted a transaction to avoid.

Consensus Algorithms Willem Visser RW334. Why do we need consensus? Distributed Databases – Need to know others committed/aborted a transaction to avoid.
Tutorials 2 A programmer can use two approaches when designing a distributed application. Describe what are they? Communication-Oriented Design Begin with.

Tutorials 2 A programmer can use two approaches when designing a distributed application. Describe what are they? Communication-Oriented Design Begin with.
1 Failure Handling in a modal Language Nels Eric Beckman Research Talk Institute for Software Research October 30, 2006.

1 Failure Handling in a modal Language Nels Eric Beckman Research Talk Institute for Software Research October 30, 2006.
Active Messages: a Mechanism for Integrated Communication and Computation von Eicken et. al. Brian Kazian CS258 Spring 2008.

Active Messages: a Mechanism for Integrated Communication and Computation von Eicken et. al. Brian Kazian CS258 Spring 2008.
USER LEVEL INTERPROCESS COMMUNICATION FOR SHARED MEMORY MULTIPROCESSORS Presented by Elakkiya Pandian CS 533 OPERATING SYSTEMS – SPRING 2011 Brian N. Bershad.

USER LEVEL INTERPROCESS COMMUNICATION FOR SHARED MEMORY MULTIPROCESSORS Presented by Elakkiya Pandian CS 533 OPERATING SYSTEMS – SPRING 2011 Brian N. Bershad.
Research at Intel Distributed Localization of Modular Robot Ensembles Robotics: Science and Systems 25 June 2008 Stanislav Funiak, Michael Ashley-Rollman.

Research at Intel Distributed Localization of Modular Robot Ensembles Robotics: Science and Systems 25 June 2008 Stanislav Funiak, Michael Ashley-Rollman.
Communication in Distributed Systems –Part 2

Communication in Distributed Systems –Part 2
Implementing Remote Procedure Calls an introduction to the fundamentals of RPCs, made during the advent of the technology. what is an RPC? what different.

Implementing Remote Procedure Calls an introduction to the fundamentals of RPCs, made during the advent of the technology. what is an RPC? what different.
Ivan Lanese Computer Science Department University of Bologna/INRIA Italy Fault in the Future Joint work with Gianluigi Zavattaro and Einar Broch Johnsen.

Ivan Lanese Computer Science Department University of Bologna/INRIA Italy Fault in the Future Joint work with Gianluigi Zavattaro and Einar Broch Johnsen.
16: Distributed Systems1 DISTRIBUTED SYSTEM STRUCTURES NETWORK OPERATING SYSTEMS The users are aware of the physical structure of the network. Each site.

16: Distributed Systems1 DISTRIBUTED SYSTEM STRUCTURES NETWORK OPERATING SYSTEMS The users are aware of the physical structure of the network. Each site.
Remote Procedure Calls. 2 Client/Server Paradigm Common model for structuring distributed computations A server is a program (or collection of programs)

Remote Procedure Calls. 2 Client/Server Paradigm Common model for structuring distributed computations A server is a program (or collection of programs)

Similar presentations

Ads by Google