C locates s by network address (including port) such that an initial request can be sent. Program S

Overview of Client/Server and RPC

• Some contexts

• Some issues raised

• Growth of de facto RPC

• Binding and marshalling

• Some services

• Example new technology service: time

• RPC and threads vs. events

Basic Client/Server protocol

• 1.Program C locates S by network address (including port) such that an initial request can be sent.

• 2. Program S deciphers message from C and responds

• 3. C deciphers message from S and responds if needed

• Repeat 2,3 until done

Client/Server contexts I

• Remote file systems -- operating system interface. Special hardware runs gamut from high-performance (e.g., striping) to low-performance (e.g., older machine, small memory -- no user interface, no graphics)

• File servers --- application level service -- e.g. using serialization of objects

Client/Server contexts II

• Database servers -- often direct, no opsys support

• Network time servers -- obtain a time within limits. Simple case: time will fall between request and response for non-swapping process.

Client/Server contexts III

• Network Security servers -- key storage, key generation. Authentication. (PGP?)

• Network mail and news servers -- sending, receiving, storing, forwarding.

• Web servers -- provide documents of various media types, including dynamically created documents (i.e., program input and output).

• Symbolic name servers -- tables (SYS001…)

Some example issues

• Consistent data

• Timely delivery

• Single standard, many needs

Data replication

• Cardinal sin of system design

• But not always --- some data is not numbers and can tolerate inaccuracies (NN data, systems that learn)

• Particularly apropos for distributed systems

• Caching, such as done with web clients, is a form of data replication. Many difficulties to address with this regarding keeping data consistent.

Caching issues

• Is coherency guaranteed?

• Obscure problems: Web documents are cached (windows\temporary internet files\chache1…) which means privacy may be violated.

Proxy update problems

• Proxy servers for the web may themselves be out of date.

• Proxy Client-server A gets a copy of data D from the master server S.

• A serves D to Client B.

• D is updated to D’ on S.

• A Client B refresh from A will not help because Client A is now out of date (D != D’)

Ad hoc Client/Server solutions

• Program C locates S by network address (including port) such that an initial request can be sent.

• Program S deciphers message from C and responds, but the response does not get through.

• Meanwhile program C waits for response...

• Many ways for something to go wrong, and programmers had to take many similar steps to account for these

Need for RPC

• A number of the problems with requesting remote services are the same as when a procedure is called, or can be made to look like this.

• If remote computing can be made to look like a procedure call, a familiar programming paradigm can be used to deal with the problems arising.

LPC / RPC transparency

• Agreed goal was to make remote computing look as much like local computing as possible.

• Using an Interface Definition Language (IDL) describe the interface between the local and remote programs. Compile with a special compiler. Generate stubs in which the real code is to be written.

• Code was being written anyway, so adopted as a de facto standard before fully understood.

Not that easy

• Semantics of RPC allow it to either look like LPC (local procedure call) or run efficiently, but not both.

• Standard, embodied in millions of lines of code is flawed.

Failure of remote system

• RPC works well if there are no failures, but it can be difficult to understand behaviors, and build robust code, in cases where failures occur. The question is then -- is the system under consideration one where failures might occur? (!)

Fix it?

• Semantics of RPC are much better understood now.

• A major re-engineering of RPC might be called for, but…

• With alternative constructs such as CORBA, RMI, and possibly DCOM, probably not worth it.

Distributed stress… I

Distributed Stress…. II

Distributed Stress… III

Semantics for distributed systems

• On the one hand… use modern theoretical understanding to build robust, reliable system

• On the other hand… remember the lessons of the Web.

• Robust but usable standards.

One level down into RPC

Binding / Marshalling

• Establish communication

• Transfer program information back and forth

Binding

• Establish connection(s) between client and server -- this might include starting a server through a factory, and what happens when the connection to the factory fails?

• Negotiate compatibility between remote systems

• Arg format

• Version of client/server code

• verify services supported

Bind -- connect

• Start server on remote client -- which one?

• Choose from eligible candidates running or in factories -- this places responsibility for load-balancing on the client, not necessarily a good idea.

• If no response, then what?

• Connection is dropped, then what?

Bind --versioning

• Code now lives in places unknown, -- no longer resides in one location or time

• True geographically

• True temporally as well.

• Requires version accounting to guarantee compatibility.

• Client may be off line during upgrades, may be more than one version out of date…

RPC arg conventions depend on need

• Easy RPC programming, hard application programming… restrictive form

• Easy application programming (maybe), hard RPC considerations… flexible form

Restrictive RPC format

• Restrictive RPC. Limits on the types of data, and on size of args passed. Fast, easy, on RPC side. Might be fine --- until some dynamic data object takes on a larger size (years later?) and major logic changes must be instituted to break up the data into smaller chunks.

Flexible RPC format

• Flexible RPC -- complex RPC code, and not necessarily easy application writing. Loop with a single reference to a large data object ---

• Copy to remote site each time

• Cache at remote site

• Tradeoff is between inefficiency (possibly fatal) and complicated code.

Marshalling and data types I

• ASN.1 (Abstract Syntax Notation) -- self-describing data types (e.g., like old IBM variable-length strings)

• XDR (external data representation) SUN NFS RPC format.

Marshalling and data types II

• 64-bit, 32-bit, 16-bit, integers/pointers

• Floating point

• Big Endian, Little Endian (next slide)

• Data alignment (word boundaries, byte boundaries?) Efficiency vs. storage space. Different needs for different systems. Different systems likely for different services.

Byte ordering

• Big-Endian -most significant byte on the left end of the word. Motorola.

• Most RISCs running UNIX

• TCP/IP network protocol

• Little-Endian. Intel.

• x86, VAX, Alpha, Windows NT machines

• CArchive bNoByteSwap mode flag

• value defaults to general x86 ordering

Byte ordering II

RPC and word size

• 64 -bit representation requires 4 times the memory size to store much of a program. 4 times the loading time, storage space, swapping, etc.

• RPC standard 64 bit, 32 bit, 16 bit?

• Marshalling arguments requires time and code.

• Memory not so much of an issue anymore, except in networked apps, and embedded apps --- where much of distributed systems lies.

Marshalling --- pointers

• NOT shared memory space. What does a pointer mean?

• copy all referenced data objects automatically

• copy no pointer-referenced data objects, but fetch them if referenced remotely (lazy)

• What about LISP, etc., where everything is a pointer? -- Garbage collection?

• Leave up to the user (complex user code)

Marshalling -- Null pointer

• If you decide to copy everything, either proactively or in a lazy manner, your marshalling algorithm still may need to know application specifics. For example, what happens in a linked structure (e.g., tree) which has null pointers?

RPC threads

• Each new client request to a server spawns a new thread to handle it.

• Have to be careful to avoid synchronization problems, just as with operating systems resources

RPC and deadlock

• Without threads, A binds to B which binds to C which in turn needs A, which is busy waiting for B.

• With threads this can be avoided, unless A is bound to a non-sharable resource.

RPC and events

• Windowing systems (like Win95 and Windows NT) use an event dispatch model, wherein, e.g., the code attached to a window will receive a call from the operating system (a call back) telling it to handle the fact that a mouse button was pushed. RPC can be invoked this way as well.

Threads vs. events

• If a thread has been sleeping (blocking), and then wakes up to resume processing a client request, it has its state with it, and hence knows what to do next.

• If an event is called to resume processing the next step in some client request, it must first restore the state of that request.