Course:CICS525/Notes/Infrastructure-2
< Course:CICS525 | Notes
Introduction
- Why is RPC not sufficient?
- Distributed objects goals
- Java RMI
Why is RPC not sufficient?
- programmer has to write stubs
- few data structures can be passed to the client or server
- for example, can you pass a C++ object?
- a pointer and dereference it remotely?
- programmer must design a scheme for naming remote objects
- server must map names to objects
How to get better object support?
- two basic approaches:
- pull object to caller
- push call to object
- which is the best plan?
- distributed object systems
- e.g. Network Objects, CORBA, Java RMI
- "remote object references"
- real object is on server
- clients send method calls to server
- object refs as RPC return values
c = cartserver.create()
- RPC for object methods
c.add(item)
- pass remote object to any server
warehouse.ship(c)
- automatic location of object's server
warehouse can do c.list()
- distributed garbage collection
- first a simple call/return
o = ???; o.fn("hello");
- which server to send to?
- what object on server?
- what does RPC message contain?
- how does RMI s/w on server gain control?
- thread...
- how does server find the real object?
- where does server-side dispatch fn come from?
- what does a stub object look like?
- type?
- contents?
- where did it come from?
- how about passing an object as an argument?
o1 = ???; o2 = ???; o1.fn(o2);
- what must o2 look like in the RPC message?
- server host, object ID
- what if o1's server already knows about o2?
- how do we know if two objects are the same?
- must have a table mapping object ID to ptr to o2
- what if o1's server does not know about o2?
- where does it get stub type, implementation?
- can stub stuff be generated purely by client?
- there are probably type IDs, so client can re-use stub code
- an object ID must contain type ID, or an RPC to fetch it
- clients and servers must have tables mapping type ID to stub code
When can a server free an object?
- only when no client has a live reference
- server must somehow learn when new client gets a reference
- and when client local ref count drops to zero
- so clients must send RPCs to server to note first/last knowledge
- what if C1 passes to C2, C1 sends de-ref RPC before C2 sends ref?
- what if a client crashes?
- will server ever be able to free the object?
- what if a server crashes?
- will client object refs work after restart?
RMI restrictions
- equals, hash, locks defined on local ref, not obj content
- no fields
- all remote, no way to do some local
- hard choice between copying whole object graph vs. remote
- what can client do with RMI's remote method exception?
When will RMI throw the exception?
- network down for a while, timeout
- server down for a while, timeout
- obj ref not valid (server GC'd or rebooted?)
- let's assume timeout
- r/o queries
- display error to user
- retry at different server, e.g. DNS
- write queries
- problem: we don't know if server executed
- amazon order: display error to user
- user can go back and check list of orders
- or look at credit card statement
- log! audit!
- what if no user?
- what exactly is the problem in this case?
- usually multi-step operation
- e.g. debit+credit
- each step might be an RPC
- an RPC fails in the middle
- use distributed transactions (two-phase commit)
- or some kind of compensation
- r/o queries
Retrospective on RPC
- more convenenient than direct socket programming
- marshaling, stubs, appearance of function call is nice
- but not life-changing
- but *not* like local call
- failure
- no shared memory
- slow
- big vision basically failed