CS 390- Unix Programming Environment CS 390 Unix Programming Environment Topics to be covered:...

CS 390- Unix Programming Environment

CS 390 Unix Programming Environment

Topics to be covered: Distributed Computing

Fundamentals


Topics Distributed Systems Building Distributed Systems Remote Procedure Calls (RPC’s) Interface Definition Language


Introduction Since the early days of computers engineers

have been able to dramatically improve the price/ performance of computer systems

How:• Advances in the hardware technology• Software that takes advantage of, and requires

powerful hardware support Can this continue?

We are now starting to see the limits of the laws of physics effect the performance of microprocessor designs

Not being able to access every part of the chip


Introduction Question: Where do we go from here? Answer: Add multiple processors to

computer systems design that allow these processors to work together to improve the overall computing capacity of the computer

How: • Take advantage of advances in Hardware technology• Make use of distributed systems architecture in an

effective manner• The future of distributed systems will have thousands

of processors


Distributed Systems

A Distributed System is a collection of independent computers that appears to the user as a single computer

Fundamental aspects of the distributed systems definition

• Computers are autonomous• Users think of the system as a single

computer


Challenges The challenges for a distributed system are

consistent with that of a centralized (non-distributed) system

However, distributed systems are more complex than the centralized systems

• Coordination issues• Synchronization issues

• Logical Clock• Communication issues

Desire to have a distributed system architecture with a distributed OS to handle and abstract these complex tasks


Desire of Distributed OS One of the primary desire of having an

operating system is to shield programmers from the complexity of the hardware

• OS is a layer that sits on top on hardware• OS provides an interface or virtual machine that is

easy to understand and program

In Similar ways a distributed system architecture must incorporate a Distributed System OS that would shield the client from complexities.


Building Distributed Systems To enable a distributed system, one processor

must communicate with another processor We can do this by building out own

communication programs using sockets With sockets we are responsible for:

• Encoding all data• Having the client locate the server• Byte Ordering• Client and server processes must agree on the format on

exchanged buffers• Client and server processes must agree on handshaking

for exchange of data


Building Distributed Systems contd… In the term project, we implemented a

distributed application• Client and Server communicated through sockets• We implemented most of the socket features we

discussed in the previous slide

Summary: With sockets the programmer is intimately familiar with the details of communications programming

We will now discuss about a technology that enables programmers to focus on building application code and lessen the burden of socket programming


Remote Procedure calls RPC’s look like traditional procedure

(function) calls from the perspective of the programmer

RPC’s abstract data communication issues and allow a process on one machine to invoke a procedure on another machine

RPC’s are usually supported by tools that generate all of the communication code that is used by both the client and server programs


How a local procedure worksint add(int a, int b) {return a+b;

}void main() {printf(“%d \n”, add(5,4));

} How a local call works?

• Values put on stack• A call is made• Local procedure accepts parameters from the stack• Local procedure performs its operation and returns value to

the register• Original calling procedure accepts this value


Parameter passing conventions Pass by value Pass by reference Pass by copy/restore

• Parameter value is passed from calling procedure to called procedure

• When the call finishes, the new parameter value overwrites the calling procedures original value

• This feature is not supported by C++• However, it holds


Remote Procedure Call Desire is to enable a RPC to support call by

reference and call by value conventions Problem: traditional language syntax is not

descriptive enough to describe if it is call by reference or call by value

Also there are problems when we are trying to pass by reference How do we pass pointers? We need additional information such as storage

space for pointers


RPC Architecture

Client code

Client Stub

Operating System

Server stub

Server code

Operating System

Network


RPC Architecture contd… Client stub marshals the parameters that

are passed from the client program to the server-based program

Client stub implements communication code to send arguments to the server stub

Server stub demarshals the client parameters

Server stub calls the RPC Server stub passes the result back to the

client via the client stub


Performing an RPC The key to performing a successful RPC is

the marshaling and demarshaling code that is performed by the client and server stubs

Marshaling handles• Encoding and decoding of the procedure parameters• User must be able to augment the basic marshaling

facility to instruct the stubs on how to properly handle user-defined data types

The marshaling code must properly handle pointers


IDL: The key to enabling RPC’s IDL is an Interface Definition Language Includes interface code only, no

implementation code is included in the IDL file

The IDL consists of special code that gives following details

• Procedures or the services that the server provides• Parameters specifying their data type and also

indicating whether they are in, out or in out type


Sample IDL

interface test {

int add(in int a, in int b);

void add(in int a, in int b, out result);

}


Building a RPCIDL

IDL compiler

Client stub

Server skeleton

Client code

RPC Implementation

Compiler and Linker Compiler and Linker

Client Application Server Application


Static or Dynamic Binding Static Binding

• Client specifies the location (IP address) of the server application during the IDL compilation phase

• At run time this address is used to establish connection with the server

Dynamic Binding• Server registers its name with a name server• At run time the client contacts the name server for

location of the server process• The client builds and uses a binding handle to

communicate with the server


Handling errors in RPC RPC’s are more error prone than the

local procedures There are lots of issues:

• Client unable to locate the server• Losing messages during communication• Client/server crashes

A programmer must handle these errors properly while coding


Handling errors using Exceptions Exceptions are error handling techniques An Exception has a try and catch block. A try

block has the code and catch block catches an exception when an error occurs in the try block

try { . . . Arrays[r] = new String(“Deal”);} catch (ArrayIndexOutOfBoundsException e)

{ out.close(); // don't do this; it duplicates code System.err.println("Caught ArrayIndexOutOfBoundsException: " + e.getMessage()); }

catch (IOException e) { System.err.println("Caught IOException: " + e.getMessage()); }


RPC issues RPC’s may be quite slow because

excessive copying of information is necessary

Timer Management• Synchronization issues

Coordination issues• Message Passing

Communication issues• Crashes


Some Architectures based on RPC’s Java RMI (Java Remote Method

Invocation) CORBA (Component Object Request

Broker Architecture) COM (Microsoft’s Component Object

Model)

CS 390- Unix Programming Environment CS 390 Unix Programming Environment Topics to be covered:...

Documents

Transcript of CS 390- Unix Programming Environment CS 390 Unix Programming Environment Topics to be covered:...