Network Objects

Presenter: Dan Williams

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!

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

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!

Linda

New model for parallel programming Simple, Elegant

Linda in Context. Carriero and Gelernter.

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!

Basic Idea: Linda

Tuple Space

(“a string”, 15.01, 17, “another string”)

(0, 1)

Process 1 Process 2

• in / rd

• out / eval

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

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)

Linda vs. Concurrent Logic Parallel conjunction Guarded clauses Shared logical

variables Merge Problem

Multiple clients – explicit merge

Dining philosophers Much simpler in Linda

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

Conclusion

Linda is wonderful Or is it?

Tuple Spaces: Location

Where is it located: 3rd party?

Node with tuple space

A B

Tuple Spaces: Location

Where is it located: 3rd party?

Node with tuple space

A B

Large tuples?

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

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?

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?

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”?

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

Linda Today Jini/Javaspaces

                                                                              

                                                 

Figure 1. Processes use spaces and simple operations to coordinate activitiesCopyright Sun Microsystems, Inc.

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.

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

Local Obj vs. Remote Obj

Client

Server

call

Client

Server

call

Transparent!

method invocation on local object

method invocation on remote object

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

Object Types

T

TSrg TImpl

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)

Overview

Obj Ref

Obj

Client Owner

Overview

Stub

Obj Ref

• Unmarshal Ref

• Select Transport

• Select Srg Type Obj

Client Owner

Overview

Stub

Surrogate Objectcall

Obj Ref

• Unmarshal Ref

• Select Transport

• Select Srg Type Obj

Client Owner

Overview

Stub

Surrogate Objectcall

Obj Ref

• Unmarshal Ref

• Select Transport

• Select Srg Type Obj

Dispatcher

Client Owner

Overview

Stub

Surrogate Objectcall

Obj Ref

• Unmarshal Ref

• Select Transport

• Select Srg Type Obj

Dispatcher

Client Owner

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?

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

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

Efficiency

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

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?

Other Issues

Semantics still not powerful enough Multicast not primitive

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

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