Network Objects

1
Network Objects

• Based on Network Objects by
• Andrew Birrell, Greg Nelson, Susan Owicki, and
  Edward Wobber
• Digital Systems Research Center, 1993
• Presented by
• Hernán Stamati
• Prepared for Distributed Systems (Rice
  University), Fall 2005

2
Key Points

• Identify the concepts and challenges associated
  with a distributed objects system.
• Design a distributed objects system that provides
  a simple interface to the user.
• Give an idea of the key implementation details
  that may enable anyone to build a distributed
  objects system.

3
What is a Network Object?
Definition A network object is an object
whose methods can be invoked over a network.
method call on object object.method(par)
object
result (if any)
4
Basic Terminology

• Owner the program containing the actual object
• Client the program invoking a method
• Implementation Object lives in the owners
  address space where it performs its actions
• Surrogate Object also called a stub, lives in
  the clients address space and redirects calls to
  its methods to the implementation object across
  the network

From a programs perspective, using a network
object is (almost) no different from using a
local object
5
Concepts
How can we achieve this transparency? Lets start
with a simple design
6
Exporting and Importing

• Servers make network objects available through
  name exporting.
• Clients get references to them through importing.

• Named objects those that have been exported by
  the agent and have an entry in the agents table
  under a name (typically service objects).
• Anonymous objects those that are exported but
  not present on any agent table (the vast
  majority) and are typically created and returned
  by others.

7
Invoking Dispatching

• What happens when a method is invoked on a remote
  network object?
• Assume a method call on a surrogate network
  object with 2 parameters that returns a network
  object.
• There is a listening thread at the server which
  looks up the requested object in its object
  table.
• A dispatcher object (aka server stub) redirects
  the call to the implementation object.
• Back at the client, the surrogate gets a
  reference to another surrogate (the result) and
  passes it to the caller.

result objsrg.method1(par1,par2)
8
Marshalling
result obj.method1( par1, par2 )

• Basic types (integers, reals, character strings)
  can be marshaled easily
• What if par1 is a network object? If it is
  in-out? (next slide)
• What about other (non-network) objects?

rep representation
9
Transferring Objects

• Identification of remote objects
• SpaceID a number that identifies the owner
• ObjID distinguishes different objects within
  owner
• Wire Representation the pair ( SpaceID, ObjID )
• When a process receives receives references to
  network objects
• If it owns the object, theres nothing to do,
  just reference its implementation.
• If it has seen the object before, it probably
  still has a surrogate for it.
• If it has never seen this object before, it
  doesnt have a surrogate for it, so create the
  appropriate one and store it.
• Third party transfer when program A has a
  reference to a network object owned by program B
  and passes the reference to a third program C, so
  that it can call methods on it.

10
File Server Example
2. Server Runtime returns handle to exported
FServer 4. FServer returns handle to File 6. File
sends data
Client
FServer
1. Requests handle to Fserver (imports) 3. Asks
FServer to open a File 5. Reads from File
Server
11
File Server Example
NetObj
Abstract (interface definition only)
Local implementations
Surrogate or Stub
12
File Server Example

• Export at Server
• NetObj.Export( fserverimpl, FS1 )
• NetObj.Service() // Wait for clients

Import at Client FServer s NetObj.Import(
FS1, NetObj.LocateHost(fs.rice.edu)) File
f s.open(/usr/dict/words) while (! f.eof())
print( f.getChar() )
13
Key Points

• Identify the concepts and challenges associated
  with a distributed objects system.
• Design a distributed objects system that provides
  a simple interface to the user.
• Give an idea of the key implementation details
  that may enable anyone to build a distributed
  objects system.

14
Assumptions

• Our design will assume that the underlying
  computer system provides us with
• Objects with simple inheritance and dynamic type
  checking.
• Threads
• Inter-address space communication (e.g. TCP/IP,
  UDP/IP, etc.)
• Local garbage collection

15
Designing the Runtime

• Some classes for the runtime implementation
• State a network object can be EXPORTED,
  SURROGATE or UNEXPORTED
• Location represents an address space (program
  on a computer) and can generate Connections to
  it.
• Connection an abstract communication channel
  it contains a reader rd and a writer wr, (our
  communication primitives for marshaling calls).
• WireRep the wire representation (SpaceID,
  ObjID)
• Dispatcher takes a NetObj implementation o and
  a Connection c, unmarshals a method call from
  c.rd, calls on o, and marshals the result into
  c.wr. In the literature this is also known as
  server stub or skeleton.

16
The NetObj class

• If an objects state is
• EXPORTED wr contains its wire representation
  and disp its dispatcher loc is unused since we
  are its owner.
• SURROGATE wr contains its wire representation,
  but now loc is used to generate connections to
  the owners (remote) process and disp is unused.
• UNEXPORTED we are its owner, but nobody has
  ever asked for a reference to it. When this
  object is returned to a remote caller (marshaled)
  for the first time, a dispatcher is created for
  it and state is set to EXPORTED.

17
The Dirty Set

• The system provides network-wide
  reference-counting garbage collection.
• For each exported NetObj, the runtime records
  which clients currently have surrogates for them
  (dirty set).
• If the dirty set for a NetObj is nonempty, the
  local GC is prevented from collecting it (since
  the dirty set has a reference to it).

18
The Dirty Set (contd)

• A surrogates destructor communicates to the
  owner to remove itself from the dirty set,
  decreasing the remote reference count.
• If the dirty set becomes empty, the runtime
  removes the entry and the local GC can collect
  the object.
• Special case NetObj returned as a result could
  lead to premature collection if after returning
  the callee drops it. So, require an ACK from the
  receiver before dropping it.

19
The Object Table

• Maintained by each address space, it contains
• All of the process surrogates
• All of the process NetObjs in the EXPORTED state
  
• (When an UNEXPORTED NetObj becomes
  EXPORTED it gets added to objtbl)

20
The Stubs Table

• Has correct dispatchers for each surrogate type,
  and each entry is initialized by each stub module

The abstract subclass of NetObj Im interested in.
Handles remote calls on objects of type Objtype
21
Key points

• Identify the concepts and challenges associated
  with a distributed objects system.
• Design a distributed objects system that provides
  a simple interface to the user.
• Give an idea of the key implementation details
  that may enable anyone to build a distributed
  objects system.

22
Marshalling and UnmarshallingNetwork Objects
MarshalNetObj( NetObj o, Connection c ) if
(o.state UNEXPORTED) newid
newObjID() o.wr WireRep( spaceID, newid
) objtbl(o.wr.spid, newid) o o.type
EXPORTED o.disp getDispatcher( Type(o)
) MarshalInt( o.wr.spid, c )
MarshalInt( o.wr.objid, c )
NetObj UnmarshalNetObj( Connection c ) sp
UnmarshalInt(c) i UnmarshalInt(c) if
(objtbl(sp,i) ! NULL) return
objtbl(sp,i) else return NewSurrogate(
sp, i, c )
23
Putting it all together File server example
revisited
The surrogates
The implementations
Class FServerSrg implements interface FServer
File open( String name ) File res
Connection c loc.new() MarshalNetObj(
this, c ) MarshalInt( 0 , c ) // Method
ID MarshalString( name , c ) res
UnmarshalNetObj(c) // Wait for response
loc.free() return res Class FileSrg
implements interface File // Similar code
Class FServerImpl implements interface FServer
File open( String name ) // Actual O/S
file opening return f Class FileImpl
implements interface File char getChar()
// return next char bool eof() //
return true/false
24
Putting it all together File server example
revisited (contd)
25
Results

• The size of the implementation is small (around
  10 kLoc in Modula-3)
• Performance was estimated comparing times between
  calls

Total time TCP echo overhead Modula-3
context switches

• An important subjective result that is not easily
  measurable is user friendliness but most would
  agree it is crucial.

26
Conclusion

• The authors effectively designed a DOS with a
  simple interface and straightforward to use.
• Instead of adding layers to RPC, the system uses
  its own marshalling and communication code.
• Although the authors did not focus too much on
  performance, the architecture is clean and can be
  adapted to most applications. The paper was
  referenced by work on distributed OS, distributed
  graphics libraries, etc.