"Network Objects", Birrell, Nelson, Owicki, Wobber, SOSP 1993. What problems are they trying to solve? Make RPC more transparent! Avoid explicit server binding arguments to all RPCs. Automatic handling of object handles. 3rd-party transfers. Distributed GC. More convenient marshaling (via pickling; avoid complete type specs). Can we think of any situation where this would be valuable? X clients exchange complex data in cut buffers via server. This is not client/server! Symmetric. What restrictions are they willing to live with? OO. Language-dependent. Pure types -- methods only. All types descended from NetObj.T. How do they provide location transparency for objects? Attaches a fixed location to each object. I.e. objects do not move. Send method calls back to object's home machine. Allows one to pass/return objects in any call. Pass object refs to any machine (not just object's server). Was this model the only possible solution? Why not distributed shared memory? (To support non-pure objects.) Why not allow objects to move? How does a call on a surrogate's method work? I.e. client already knows about the object. Surrogate object in client contains SpaceID/ObjID, location, and stub method. Stub method creates a new connection to the owner (SpaceID). Send just ObjID and method # to owner. In owner, connection's thread reads the ObjID. Looks up ObjID in object table, calls object's dispatch stub method. Dispatch stub method reads method # and args, calls real method. Marshalls return value and sends back. What's a NetObj? An actual object. (Almost) always sub-typed: owner sub-types with real implementation others sub-type with surrogate that has stub methods Contents on owner: State, WireRep, Dispatcher Contents on others: State, WireRep, Location Crucial table: objtbl: WireRep -> NetObj ------------------------------------------------------------------------ What if owner wants to return (or pass) a network object? I.e. call a method on some other object, or return from method. So network objects system has control, knows we're doing this. If it hasn't been exported before: Allocate an ObjID. Create entry in object table (map ObjID to obj ref). Set the real object's disp field from stub table. Once it's been exported: Just send my SpaceID and ObjID across network. What if non-owner wants to pass a network object? I.e. a surrogate object. Object representation contains SpaceID/ObjID. Just send them to target. What if you receive a ref to a network object? I.e. SpaceID/ObjID. Look in objtbl, may already be there. I.e. already allocated a NetObj. *Must* re-use it so equality works. If not already known: Find owner by asking sender about SpaceID. Ask owner for type. Figure out corresponding local type code. Create a surrogate for that type, Tsrg from stub table. Put it in local objtbl. ------------------------------------------------------------------------ Various tables: stubs: TypeCode -> TypeCode (of surrogate), Dispatcher names: SpaceID -> Endpoint maps between TypeCode and Fingerprint ------------------------------------------------------------------------ What are TypeCodes? What are fingerprints? Where do they come from? Why are they neccessary? Type relationships NetObj, T1, T2, T2Impl, T2Srg. T2Impl is *not* the same as T2. What if the client stub for a class isn't present? What if the server stub isn't present? What if the client casts an object and then calls a method? Cast up inheritance tree -- no difference. Cast down -- no difference, but not allowed to cast below Tsrg. System has to get surrogate types right regardless of declarations. ------------------------------------------------------------------------ What does the stub compiler produce for T? Surrogate sub-class of T. Methods overridden to marshall and call owner. Dispatcher function in owner. Unmarshalls, calls correct real method. Puts both in stub table. ------------------------------------------------------------------------ What does N.O. require from the surrounding system? Universal naming of computers (i.e. IP addresses), for SpaceID/Endpoint. Universal connectivity. (NAT? firewalls?) A name registry to get started. Automatic allocation, so N.O. can create stub objects. Garbage collection, so N.O. can free stub objects. Does it have to be reference counting? Run-time type tags: to allocate surrogates. Type fingerprints: portable type descriptions. Threads, so a program can always service calls w/o deadlock. ------------------------------------------------------------------------ Does N.O. solve real problems? Dramatically more transparent than ordinary RPC! Programs look almost exactly like local code. Don't have to bind, worry about where server is, create e.g. filehandles. Handles 3rd party stuff. ------------------------------------------------------------------------ Is it fully transparent to the programmer? I.e. can we add it to existing programs with no pain? You have to run the stub generator on the right types. You have to make the right types children of NetObj.T If objects are the right granularity of location. If objects don't need to move. If all object accesses are through methods. If performance isn't a problem. If security isn't a problem. If you don't have to GC inter-machine cycles. If no hidden concurrency problems: if(item.inventory() > 0){ item.decrement_inventory(); shipment.add_item(item); } Or partial failure (after the decrement). Is this a good paper? Does it have clearly stated claims? Does it support those claims? Does it analyze whether the system is successful?