CS 390- Unix Programming Environment 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 these complex tasks
CS 390- Unix 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 handshaking for exchange of data
CS 390- Unix Programming Environment 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
CS 390- Unix Programming 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 Original calling procedure accepts this value
CS 390- Unix Programming 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 Server stub Server code Operating System Network
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 stub Server skeleton Client code RPC Implementation Compiler and Linker Client ApplicationServer 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)