1. Network Objects Presenter: Dan Williams

2. Trends Network centric view of world Jini, Web Services Based on Object Oriented models Both papers contributed some ideas Seems to be future even if we’re not quite there yet!

3. Communication RPC Doesn’t always fit our intuition Would like to access named objects Look like local objects to programmer May not care who receiver/worker is

4. Communication RPC Doesn’t always fit our intuition Would like to access named objects Look like local objects to programmer May not care who receiver/worker is We want a simple model!

5. Linda New model for parallel programming Simple, Elegant Linda in Context. Carriero and Gelernter.

6. Motivation: Linda Message-passing Not simple, not flexible! Concurrent OO programming Instance of message passing! Concurrent logic languages Not simple! Functional programming languages Not always suited to problem!

7. Basic Idea: Linda Tuple Space (“a string”, 15.01, 17, “another string”) (0, 1) Process 1Process 2 in / rd out / eval

8. Linda Operations in = take a tuple (block until match) in(“a string”, ? F, ? I, “another string”) rd = same as in but leave tuple out = output a tuple out(“a string”, 15.01, 17, “another string”) eval = output a live tuple eval(“M”, i, j, compute(i, j)) New process to compute something Becomes data tuple upon completion

9. Linda vs. Concurrent Obj Concurrent objects use monitors Simplicity Monitors need process forking, shared state variables, condition queue/signal Synchronous communication not norm Flexibility All elements of distributed data structure must reside inside monitor (restrict access)

10. Linda vs. Concurrent Logic Parallel conjunction Guarded clauses Shared logical variables Merge Problem Multiple clients – explicit merge Dining philosophers Much simpler in Linda

11. Linda vs. Functional Prog Specification for parallel compiler Parallelism: compiler or programmer? “Interpretive abstraction” Don’t have every process send individual result Fill some distributed data structure (freedom) Recursion equations not always helpful in understanding distributed problems Search may lend to recursion equations Comparing searches does not

12. Conclusion Linda is wonderful Or is it?

13. Tuple Spaces: Location Where is it located: 3 rd party? Node with tuple space AB

14. Tuple Spaces: Location Where is it located: 3 rd party? Node with tuple space AB Large tuples?

15. Tuple Spaces: Location Can be lots of communication overhead Single point of failure What if machine with tuple space crashes? Large amounts of clients/buggy clients What if tuple space fills up? Solution Distributed tuple space? Linda doesn’t look so simple/elegant anymore

16. Tuple Spaces: Implementation How is the tuple space organized Efficiently locate tuples Large number of tuples in space? How is the tuple space managed? Send request to tuple space for tuple space manager to search? Will tuple space need to spawn tons of threads?

17. Other Tuple Space Issues Tuple space memory leaks Program outputs a tuple, forgets about it If intended receiver crashed, tuple could remain a long time How can tuple space manager know how to get rid of these old tuples? Leases?

18. Security/Debugging Sender does not need to know receiver Responsibility offloaded to receiver Malicious/Buggy receiver can take tuples not intended for it How do you debug a system if tuples are “disappearing” in this manner? Malicious/Buggy sender can introduce bogus tuples How do you debug a system if tuples are “unexpected”?

19. Conclusions Linda looks really simple and elegant Thinking about how to actually implement a system using Linda Hidden complexities Correct model of computation? Linda not in widespread use

20. Linda Today Jini/Javaspaces Figure 1. Processes use spaces and simple operations to coordinate activities Copyright Sun Microsystems, Inc.

21. Motivation: Network Objects Object Oriented model Clients access state through methods Intuitively fits with distributed computing Method calls = Communication Details addressed How to implement Network Objects. Birrell et al.

22. Which features do we want? Focus on features believed to be of value to all distributed applications Powerful marshaling Strong type-checking Garbage collection Streams

23. Local Obj vs. Remote Obj Client Server call Client Server call Transparent! method invocation on local object method invocation on remote object

24. Basic Idea: Network Objects Stub Marshals using Pickles General purpose (efficient and compact) Network objects passed by reference Other objects passed by copying Surrogate object Methods perform RPC to owner

25. Object Types T TSrgTImpl Pure object type (only declares methods) Subtype of T with overridden methods to perform RPC Subtype of T corresponding to the owner object (including data fields)

26. Overview Obj Ref Obj ClientOwner

27. Overview Stub Obj Ref Unmarshal Ref Select Transport Select Srg Type Obj ClientOwner

28. Overview Stub Surrogate Object call Obj Ref Unmarshal Ref Select Transport Select Srg Type Obj ClientOwner

29. Overview Stub Surrogate Object call Obj Ref Unmarshal Ref Select Transport Select Srg Type Obj Dispatcher ClientOwner

30. Overview Stub Surrogate Object call Obj Ref Unmarshal Ref Select Transport Select Srg Type Obj Dispatcher ClientOwner

31. Garbage Collection Exported Objects cannot be collected if surrogates exist somewhere Synchronously make dirty call upon creation Make clean calls when local garbage collector picks up surrogate If dirty set is empty, exported object can be collected What if dirty client disappears?

32. Transports Many protocols for communication TCP, UDP, shared mem, etc. Transports generate and manage connections Returns Location Creates new connections to an address space c.rd, c.wr

33. Marshaling / Unmarshaling Marshaling Object marked as exported Unmarshaling New Surrogate Locate owner Select transport that both share (RPC) Determine surrogate type Narrowest surrogate rule Get owner’s stub types during Dirty call

34. Efficiency

35. Reliability Issues Similar to RPC issues Failure semantics not well-defined Operation occur “exactly once” How can you make this guarantee How can you add reliability Inside network object abstraction Lose simplicity and similarity to local objects

36. Transparency/Scalability More exceptions to deal with Local calls don’t fail like remote calls Latency Issues Object granularity Should objects be large/small Large number of objects Lots of copying throughout network for surrogates Large number of clients Will owner get overloaded – replicate object? What about consistent state among replicas?

37. Other Issues Semantics still not powerful enough Multicast not primitive

38. Network Objects Today Web services Take solution from middleware and deploy on internet Are Web services really distributed objects? More centered on documents than objects CORBA Heavyweight to deal with all the issues Address fault-tolerance, scalability

39. Conclusions Some models are very pretty Linda Simple – few primitives Hidden details in Tuple Spaces Network Objects Convenient OO model for communication Semantic (Reliability) issues in RPC carry over Need to think about all the intricacies that arise in distributed programs