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




Download 29,25 Kb.
Sana22.03.2020
Hajmi29,25 Kb.
#8580

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.


Download 29,25 Kb.




Download 29,25 Kb.

Bosh sahifa
Aloqalar

    Bosh sahifa



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

Download 29,25 Kb.