Common Application Components

Slides:



Advertisements
Similar presentations
DISTRIBUTED COMPUTING PARADIGMS
Advertisements

Categories of I/O Devices
OSI Model OSI MODEL.
OSI Model OSI LAYER / MODEL.
28.2 Functionality Application Software Provides Applications supply the high-level services that user access, and determine how users perceive the capabilities.
Network Operating Systems Users are aware of multiplicity of machines. Access to resources of various machines is done explicitly by: –Logging into the.
© 2007 Cisco Systems, Inc. All rights reserved.Cisco Public 1 Version 4.0 OSI Transport Layer Network Fundamentals – Chapter 4.
CS 582 / CMPE 481 Distributed Systems Communications (cont.)
Protocols and the TCP/IP Suite
1 More on Distributed Coordination. 2 Who’s in charge? Let’s have an Election. Many algorithms require a coordinator. What happens when the coordinator.
16: Distributed Systems1 DISTRIBUTED SYSTEM STRUCTURES NETWORK OPERATING SYSTEMS The users are aware of the physical structure of the network. Each site.
Top Three Layers Session Layer Presentation Layer Application Layer.
COE 342: Data & Computer Communications (T042) Dr. Marwan Abu-Amara Chapter 2: Protocols and Architecture.
 The Open Systems Interconnection model (OSI model) is a product of the Open Systems Interconnection effort at the International Organization for Standardization.
OIS Model TCP/IP Model.
Chapter 26 Client Server Interaction Communication across a computer network requires a pair of application programs to cooperate. One application on one.
What is a Protocol A set of definitions and rules defining the method by which data is transferred between two or more entities or systems. The key elements.
Protocols and the TCP/IP Suite
Architectures. Many tasks involved in encoding, protecting and transmitting user application data as bit stream. Network Architecture is how tasks are.
Chapter Nine The Session Layer. Objectives We’ll see how a new session is created, maintained, and dismantled. The process of logon authentication will.
Service Primitives Six service primitives that provide a simple connection-oriented service 4/23/2017
CS 390- Unix Programming Environment CS 390 Unix Programming Environment Topics to be covered: Distributed Computing Fundamentals.
DISTRIBUTED COMPUTING PARADIGMS. Paradigm? A MODEL 2for notes
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved RPC Tanenbaum.
CSE 451: Operating Systems Winter 2015 Module 22 Remote Procedure Call (RPC) Mark Zbikowski Allen Center 476 © 2013 Gribble, Lazowska,
Chapter 5: Distributed objects and remote invocation Introduction Remote procedure call Events and notifications.
1 Client-Server Interaction. 2 Functionality Transport layer and layers below –Basic communication –Reliability Application layer –Abstractions Files.
OSI Reference Model. Open Systems Interconnection (OSI) Model International standard organization (ISO) established a committee in 1977 to develop an.
The Client-Server Model And the Socket API. Client-Server (1) The datagram service does not require cooperation between the peer applications but such.
Enterprise Network Systems TCP Mark Clements. 3 March 2008ENS 2 Last Week – Client/ Server Cost effective way of providing more computing power High specs.
© Oxford University Press 2011 DISTRIBUTED COMPUTING Sunita Mahajan Sunita Mahajan, Principal, Institute of Computer Science, MET League of Colleges, Mumbai.
Computer Engineering and Networks, College of Engineering, Majmaah University Protocols OSI reference MODEL TCp /ip model Mohammed Saleem Bhat
Object Interaction: RMI and RPC 1. Overview 2 Distributed applications programming - distributed objects model - RMI, invocation semantics - RPC Products.
Object Interaction: RMI and RPC 1. Overview 2 Distributed applications programming - distributed objects model - RMI, invocation semantics - RPC Products.
OSI Model OSI MODEL. Communication Architecture Strategy for connecting host computers and other communicating equipment. Defines necessary elements for.
OSI Model OSI MODEL.
What is a Protocol A set of definitions and rules defining the method by which data is transferred between two or more entities or systems. The key elements.
Last Class: Introduction
THE OSI MODEL By: Omari Dasent.
Prof. Leonardo Mostarda University of Camerino
Chapter 3 Internet Applications and Network Programming
Lecturer, Department of Computer Application
Last Class: RPCs and RMI
DEPARTMENT OF COMPUTER SCIENCE
Understanding the OSI Reference Model
#01 Client/Server Computing
Client/Server Example
Client-Server Interaction
Packet Sniffing.
Protocols and the TCP/IP Suite
Chapter 3: Open Systems Interconnection (OSI) Model
CSE 451: Operating Systems Winter 2006 Module 20 Remote Procedure Call (RPC) Ed Lazowska Allen Center
Network Fundamentals – Chapter 4
DISTRIBUTED COMPUTING
Outline Announcements Fault Tolerance.
Lecture 4: RPC Remote Procedure Call Coulouris et al: Chapter 5
Process-to-Process Delivery:
CSE 451: Operating Systems Autumn 2003 Lecture 16 RPC
CSE 451: Operating Systems Winter 2007 Module 20 Remote Procedure Call (RPC) Ed Lazowska Allen Center
Lecture 4: RPC Remote Procedure Call CDK: Chapter 5
CSE 451: Operating Systems Winter 2004 Module 19 Remote Procedure Call (RPC) Ed Lazowska Allen Center
OSI Model OSI MODEL.
CSE 451: Operating Systems Spring 2012 Module 22 Remote Procedure Call (RPC) Ed Lazowska Allen Center
CSE 451: Operating Systems Autumn 2009 Module 21 Remote Procedure Call (RPC) Ed Lazowska Allen Center
Chapter 2. Protocols and Architecture
Protocols and the TCP/IP Suite
CSE 451: Operating Systems Autumn 2010 Module 21 Remote Procedure Call (RPC) Ed Lazowska Allen Center
CSE 451: Operating Systems Winter 2003 Lecture 16 RPC
CSE 451: Operating Systems Messaging and Remote Procedure Call (RPC)
#01 Client/Server Computing
Presentation transcript:

Common Application Components Some frequently needed elements in applications that involve communication between separate systems

Common Elements of the Application Layer Some things have to be done in all applications Others are very common Having a bag of tools handy can save recreating a solution every time the problem arises

Base set of common services Establish contact Remote execution Reliable transfer of data Coordination of distributed processing elements

Establishing contact Locate the processing partner Associate semantics with messages exchanged Understand network service level Match processing elements Identify initiator of the contact

ACSE Association Control Service Element Two types of services offered: Association establishment Association termination release abort by the user abort by the lower layer network services

A-ASSOCIATE Association establishment parameters describe the set of desired characteristics (the context) of the association what application service elements will be active in the cooperating systems identification of the destination process location for communication OSI PSAP (Presentation Service Access Point) TCP/IP port number Presentation context how should the receiver interpret data that arrives {1{PersonnelData, Encrypted}, 2{Annual Report, Compressed}, 3{AnnualReport,Basic}} The example lists the set of abstract syntaxes and associated transfer modes to available be used in communication between these processes. Context identifier 2 in the Presentation Context Definition List … Optional -- user data. May be used for login purposes Optional -- QOS specification O

A-RELEASE, A-ABORT A-RELEASE: Orderly termination of an association between cooperating processes A-ABORT: Abrupt termination, with possible loss of data

Closing an Association Confirmed service Unconfirmed service

Communication between layers Peer to Peer Service Requestor / Service Provider Service Requestor / Service Provider Peer to Peer Service Requestor / Service Provider Service Requestor / Service Provider

Within layers Peer to Peer Peer to Peer Service Requestor / Service Provider Service Requestor / Service Provider Peer to Peer Service Requestor / Service Provider Service Requestor / Service Provider

Parameters Information shared between peers and between service requestors and providers Each invocation of a service, or response to a service request, involves information passed both within the local stack and with peers in a cooperating stack. The single list of parameters must be split into those that inform the service provider and those that inform the peer process.

ASSOCIATION ESTABLISHMENT

System state regarding protocols A system is in one of a number of states at any given time. The state depends on what conditions are in effect, what has happened so far. The state determines what are possible responses to future events Initial state (Idle) limited set of events are acceptable others are considered error conditions For example, the arrival of data before an association is established would be an error condition

Protocol machine Key: Event Response The event occurs, the protocol machine changes state and performs the indicated response. Here the response is something sent or issued. Two views: top shows the state transition in graphical form; bottom shows the layer interaction.

Association Establishment Protocol Machine Idle A-ASSOCIATE.req AARQ AARQ A-ASSOCIATE.ind Outgoing association pending Incoming association pending AARE A-ASSOCIATE.conf A-ASSOCIATE.resp AARE Association Established

Association Established Once Association is Established the context of the interaction is established data can be exchanged an orderly termination of the association can be done ACSE is the OSI protocol for establishing an association. Other stacks, like TCP/IP, do not have a named entity for this purpose, but must establish this sort of connection

Remote Operation Call for the execution of an operation on a remote system Basic questions related to remote operation What do we know about the data to be used? How will the initiator know when the remote operation is complete? Is it safe to repeat a request if the remote system crashes before completing? Stop and wait or continue working? Do we have to send data? Will the remote system understand the data the same way the requestor does? Completion: If a result is expected but has not arrived, it may mean that the system is still executing or that it has crashed Idempotent operation: Bank balance examples

ROSE; remote procedure calls What do we know about the data to be used? ASN.1 and BER or alternatives such as XDR How will the initiator know when the remote operation is complete? Requesting some result from every operation allows the initiator to know when the operation is done Is it safe to repeat a request if the remote system crashes before completing? CCR or its equivalent Stop and wait or continue working? Synchronous or asynchronous invocation

Remote operation services In the OSI protocols, ROSE - The Remote Operation Service Element Other, RPC - Remote Procedure Call RMI - Java’s Remote Method Invocation

ROSE service RO-INVOKE RO-RETURN-RESULT RO-RETURN-ERROR call a method located in another system have it run in the other system RO-RETURN-RESULT send a result to the invoking method RO-RETURN-ERROR send an error notification to the invoking method RO-REJECT-U/RO-REJECT-P reject the invocation request

ROSE characteristics Minimal state information All services unconfirmed All responsibility for correctness is on the designer of the application

Synchronous or Asynchronous blocking Asynchronous non-blocking report results and errors report errors only report results only report nothing Not all operations have results that need to be reported. Example, request to delete a file or reset a printer or display a message -- these do not require that a result be sent back to the initiator. Good practice: get a result so you know what happened. Synchronous operation: RO-RESULT or RO-ERROR must follow and RO-REQUEST

ASN.1 definition of a remote operation

Using the definition RO-INVOKE (…,0, “PS”…) other required parameters identify remote system to be contacted, etc. 0 is the identifier of getcount; PS is the name of the queue to examine. RO-RETURN-RESULT (“PS”,250) Queue PS has 250 entries RO-RETURN-ERROR (1, “PS”) Queue PS is not available

Remote Operation Summary Protocols cover only the communication between the caller and the called method how method is identified what information is provided what is understood between them Separate issue write the method to carry out the desired action

Reliable transfer of information What is needed beyond a dependable transport layer? Protect against errors that occur after the data is delivered to the machine example: Jammed printer or a disk failure prevents completion of the desired action, but the transport layer is satisfied

RTSE: Reliable Transport Service Element Invokes services of the session layer, uses ACSE Services provided by RTSE: RT-OPEN RT-TRANSFER RT-TURN-PLEASE RT-TURN-GIVE RT-CLOSE RT-U-ABORT/RT-P-ABORT

RT-TRANSFER, RT-TURN confirmed service parameters specify data to be sent, maximum time allowed for completion If two-way data transfer, RT-TURN-PLEASE, an unconfirmed service, requests the opportunity to send data; RT-TURN-GIVE, unconfirmed service to yield turn

RTSE protocol Use A-ASSOCIATE to establish connection with peer Invoke turn-taking facilities of the Session layer Invoke activity management facilities of the Session layer to establish checkpoints between data segments used by X.400 mail system and available to ROSE when a lot of data must be moved

Commitment, Concurrency, and Recovery assurance that the server process will carry out a request regardless of difficulties that might arise Concurrency: protection from the intrusion of interleaved operations that interfere with correct completion of a requested task Recovery: establishment of procedures to overcome failures by one or more participating process during execution of a distributed application

The Lost Transaction Problem Process 1 Credit Limit Process 2 5,000 Read credit 5000 Read credit 5000 Subtract new purchase (850) update credit 4,150 Subtract new purchase (54.50) update credit 4,945.50 Time

CCR Services Bracket atomic action C-BEGIN, C-PREPARE SERVER --> CLIENT ready C-READY SERVER --> CLIENT no C-REFUSE CLIENT, SERVER agree to go on C-COMMIT CLIENT --> SERVER no C-ROLLBACK CLIENT/SERVER go back C-RESTART

Multiple servers participate

Server refuses request

Some TCP/IP handy tools Not exactly the same kind of thing, but useful nonetheless ping sends a message and looks for a response to determine that the other machine is alive and active traceroute displays the path taken by messages between two cooperating systems on sun cluster: /usr/sbin/ping or traceroute NOTE-- overuse of these is considered very unfriendly behavior. Be gentle, considerate.

Overall summary Net-centered computing has more elements than computing on a single machine. Many characteristics are the same from one application to another Understand what is the same and what varies between applications