Download CS 390 Unix Programming Environment

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Supercomputer wikipedia , lookup

Functional programming wikipedia , lookup

Falcon (programming language) wikipedia , lookup

Subroutine wikipedia , lookup

Go (programming language) wikipedia , lookup

Supercomputer architecture wikipedia , lookup

Library (computing) wikipedia , lookup

Object-oriented programming wikipedia , lookup

Reactive programming wikipedia , lookup

Abstraction (computer science) wikipedia , lookup

One-pass compiler wikipedia , lookup

Dependency injection wikipedia , lookup

Distributed computing wikipedia , lookup

C Sharp (programming language) wikipedia , lookup

Structured programming wikipedia , lookup

Transcript
CS 390 Unix Programming
Environment
Topics to be covered:
 Distributed Computing
Fundamentals
CS 390- Unix Programming
Environment
Topics
Distributed Systems
 Building Distributed Systems
 Remote Procedure Calls (RPC’s)
 Interface Definition Language

CS 390- Unix Programming
Environment
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
CS 390- Unix Programming
Environment
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
CS 390- Unix Programming
Environment
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
CS 390- Unix Programming
Environment
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
complex tasks
CS 390- Unixthese
Programming
Environment
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.
CS 390- Unix Programming
Environment
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
CS 390- Unix Programming
handshaking for exchange
Environmentof 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
CS 390-programming
Unix Programming
burden of socket
Environment
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
CS 390- Unix Programming
Environment
How a local procedure
works
int 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
CS 390- Unix Programming
• Original calling procedure
accepts this value
Environment
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
CS 390- Unix Programming
Environment
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
CS 390- Unix Programming
Environment
RPC Architecture
Client
code
Client
Stub
Operating
System
Network
Server
stub
Server
code
Operating
System
CS 390- Unix Programming
Environment
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
CS 390- Unix
Programming
Environment
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
CS 390- Unix Programming
Environment
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
CS 390- Unix Programming
Environment
Sample IDL
interface test {
int add(in int a, in int b);
void add(in int a, in int b,
out result);
}
CS 390- Unix Programming
Environment
Building a RPC
IDL
IDL
compiler
Client
code
Client
stub
Compiler and Linker
Client Application
Server
skeleton
RPC
Implementation
Compiler and Linker
Server Application
CS 390- Unix Programming
Environment
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
CS 390- Unix Programming
Environment
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
CS 390- Unix Programming
Environment
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()); }
CS 390- Unix Programming
Environment
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
CS 390- Unix Programming
Environment
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