Communication
Download
1 / 49

Communication - PowerPoint PPT Presentation


  • 74 Views
  • Uploaded on

Communication. Chapter 2. Layered Protocols (1). Physical: voltage, transmission rate, mechanical, functional, and electrical specs,…e.g. RS-232-C Data link: reliable link-level communication (framing, CRC) e.g. HDLC Network: routing e.g. IP, ATM VC

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Communication' - xylia


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Communication

Communication

Chapter 2


Layered protocols 1
Layered Protocols (1)

Physical: voltage, transmission rate, mechanical, functional, and electrical specs,…e.g. RS-232-C

Data link: reliable link-level communication (framing, CRC)

e.g. HDLC

Network: routing e.g. IP, ATM VC

Transport: reliable end-to-end communication e.g. TCP, UDP

Session: checkpointing, synchronization

Presentation: data formats, codes

Application: FTP, HTTP, SMTP, SNMP etc.

2-1

  • Layers, interfaces, and protocols in the OSI model.


Layered protocols 2
Layered Protocols (2)

2-2

  • A typical message as it appears on the network.


Data link layer
Data Link Layer

2-3

  • Discussion between a receiver and a sender in the data link layer.


Client server tcp
Client-Server TCP

2-4

  • Normal operation of TCP.

  • Transactional TCP.


Middleware protocols
Middleware Protocols

2-5

RPC, ROI, Messages, Streams

  • An adapted reference model for networked communication.


Conventional procedure call
Conventional Procedure Call

  • Call: count = read(fd, buf, bytes);

  • a) Parameter passing in a local procedure call: the stack before the call to read

  • b) The stack while the called procedure is active

  • Issues: call-by-value/reference or copy/restore?


Client and server stubs for rpc
Client and Server Stubs for RPC

  • Principle of RPC between a client and server program.


Steps of a remote procedure call
Steps of a Remote Procedure Call

  • Client procedure calls client stub in normal way

  • Client stub builds message, calls local OS

  • Client's OS sends message to remote OS

  • Remote OS gives message to server stub

  • Server stub unpacks parameters, calls server

  • Server does work, returns result to the stub

  • Server stub packs it in message, calls local OS

  • Server's OS sends message to client's OS

  • Client's OS gives message to client stub

  • Stub unpacks result, returns to client


Passing value parameters 1
Passing Value Parameters (1)

2-8

  • Steps involved in doing remote computation through RPC


Passing value parameters 2
Passing Value Parameters (2)

  • The little numbers in boxes indicate the address of each byte

  • a) Original message on the Pentium (little endian, left to right)

  • b) The message after receipt on the SPARC (big endian)

  • SPARC would read: 5.1024 (incorrect) and “JILL” (correct)

  • The message after being inverted.

  • SPARC would read: 5 (correct) and “LLIJ” (incorrect)

  •  More information is needed


Passing Reference Parameters

Reference parameters like pointers are more complicated to handle

Solution: Use call-by-copy/restore instead of call-by-reference

However: Only useful for simple referenced data

Not useful as a general solution like when using pointers to pointers

or pointers to complex data structures

The server stub may request the data when they are needed

Distinction between input and output parameters can raise performance


Parameter specification and stub generation
Parameter Specification and Stub Generation

corresponding message

  • RPC protocol agreements include questions like:

  • How many bytes for each data type? (here 4)

  • Big or little endian?

  • Data representation? (e.g. 1’s or 2’s complement, IEEE 754)

  • Transport service: connectionless or connection-oriented?

  • Stub Generation:

  • Using and IDL compiler


Doors
Doors

  • The principle of using doors as IPC mechanism.


Asynchronous rpc 1
Asynchronous RPC (1)

2-12

  • The interconnection between client and server in a traditional RPC

  • The interaction using asynchronous RPC (useful when RPC does not have a return value e.g. void functions)


Asynchronous rpc 2 deferred synchronous
Asynchronous RPC (2)(deferred synchronous)

2-13

  • A client and server interacting through two asynchronous RPCs

  •  Another form: client does not wait for acceptance (one-way RPC)


Writing a client and a server in dce
Writing a Client and a Server in DCE

2-14

  • The steps in writing a client and a server in DCERPC.


Binding a client to a server
Binding a Client to a Server

(Server, Machine Address)

(/video/movie, 123.45.67.01)

2-15

123.45.67.01

1024

Daemon [email protected] port 110

(Server, Port)

(/video/movie, 1024)

  • Client-to-server binding in DCE.

  • RPC semantics:

  • At-most-once operation: repetitions are impermissible (e.g. after a crash)

  • Idempotent operation: repetition allowed (e.g. read)


Distributed objects
Distributed Objects

2-16

  • Common organization of a remote object with client-side proxy.

  •  Object: compile-time (i.e. language-based) or run-time (e.g. built using an adaptor/wrapper) object

  •  Distributed object: state may be also distributed

  •  Remote object: only interfaces are replicated


Binding a client to an object
Binding a Client to an Object

Distr_object* obj_ref; //Declare a systemwide object referenceobj_ref = …; //Initialize the reference to a distributed object obj_ref do_something(); // Implicitly bind and invoke a method

(a)

Distr_object obj_ref; //Declare a systemwide object referenceLocal_object* obj_ptr; //Declare a pointer to local objectsobj_ref = …; //Initialize the reference to a distributed objectobj_ptr = bind(obj_ref); //Explicitly bind and obtain a pointer to the local proxyobj_ptr  do_something(); //Invoke a method on the local proxy

(b)

  • (a) Example with implicit binding using only global references

  • (b) Example with explicit binding using global and local references

  • Binding: a proxy is placed within the address space of the client

  • Object References: global and unique e.g. based on:

  • (1) machine address + port + object ID: (-) port may change after crashes

  • (2) machine address + server ID + object ID: (+) survives crashes (-) fixed location

  • (3) machine address of location server + server ID + object ID: (-) not scalable


Static versus Dynamic Remote Method Invocation

a) Remote Method Invocation (RMI):

Similar to RPC in marshalling and parameter passing

Global object references (unlike RPC)

Potentially, a developer can design object-specific proxies (unlike RPC)

b) Static RMI:

Using IDL or language-based (JAVA can generate stubs automatically)

Interfaces are known prior to development (hardwired in client)

Interface changes mean that client has to be recompiled

c) Dynamic RMI:

Using IDL

Interfaces may be unknown at development time

Dynamic invocation:

invoke(object, methodName, inputParameters, outputParameters)

Interface changes do not mean a client recompilation (rather run-time errors)

Object References: global and unique e.g. based on:

(1) machine address + port + object ID: (-) port may change after crashes

(2) machine address + server ID + object ID: (+) survives crashes (-) fixed location

(3) machine address of location server + server ID + object ID: (-) not scalable


Parameter passing
Parameter Passing

2-18

  • The situation when passing an object by reference or by value.

  • L1: passed by value (local reference)

  • R1: passed by reference (remote reference)


The dce distributed object model distributed objects are an extension in dce
The DCE Distributed-Object Model(Distributed objects are an extension in DCE)

  • Distributed dynamic objects in DCE (client creates them - via RPC - at run-time)

  • Distributed named objects (server publishes them – in a directory - for use)


Java RMI

  • Only remote objects (state not distributed)

  • Fully integrated in the Java language (stub generation)

  • Differences between local and remote objects in Java:

    • Cloning:

    • Remote objects cannot be cloned by clients. Only the server possessing the object can clone it, proxies are not cloned.

    • Synchronization:

    • Only proxies can be blocked on. The remote object (in the server) cannot be protected against simultaneous access by the mere use of synchronized methods.

    • Parameter passing:

    • local objects: by value

    • remote objects: by reference

  • Object serialization (marshalling)

  • Most objects can be serialized except platform-dependent ones like file descriptors, sockets, and so on.

  • Proxies are also serializable!  can be used as object references and passed to other clients.


Message oriented communication persistence and synchronicity in communication 1
Message-oriented CommunicationPersistence and Synchronicity in Communication (1)

2-20

  • General organization of a communication system in which hosts are connected through a network


Persistence and synchronicity in communication 2
Persistence and Synchronicity in Communication (2)

  • Persistent communication of letters back in the days of the Pony Express.

  • Persistent communication: Message is stored in communication system until submission to receiver (e.g. Email system). Sender/receiver need not be active during message delivery.

  • Transient communication: Message is discarded if receiver is inactive (non-persistent)

  • Synchronous communication: Sender blocks until message reaches receiver.

  • Asynchronous communication: Sender continues (immediately) after submitting its message.


Persistence and synchronicity in communication 3
Persistence and Synchronicity in Communication (3)

2-22.1

  • Persistent asynchronous communication (e.g. email)

  • Persistent synchronous communication


Persistence and synchronicity in communication 4
Persistence and Synchronicity in Communication (4)

2-22.2

  • Transient asynchronous communication (e.g. UDP datagrams)

  • Receipt-based transient synchronous communication


Persistence and synchronicity in communication 5
Persistence and Synchronicity in Communication (5)

  • Delivery-based transient synchronous communication at message delivery. Sender waits until message is delivered to receiver. (e.g. asynchronous RPC)

  • Response-based transient synchronous communication. Sender waits until the receiver already processed message and delivered the reply (e.g. C/S interaction, RPC, RMI)


Message oriented transient communication berkeley sockets 1
Message-oriented Transient CommunicationBerkeley Sockets (1)

  • Socket primitives for TCP/IP.


Berkeley sockets 2
Berkeley Sockets (2)

  • Connection-oriented communication pattern using sockets.


The message passing interface mpi
The Message-Passing Interface (MPI)

  • Some of the most intuitive message-passing primitives of MPI.

  •  MPI is designed for multicomputers (parallel systems)

  •  Supports group communication


Message queuing systems 1 also called mom message oriented middleware
Message-Queuing Systems (1)(also called MOM: message-oriented middleware)

2-26

  • Four combinations for loosely-coupled communications using queues.

  • (persistent asynchronous communication)


Message queuing model 2
Message-Queuing Model (2)

  • Basic interface to a queue in a message-queuing system.

  • Traditional example: email

  • However: MOM does more:

  • - is targeted to applications and users (not only users)

  • - is more generic (cf. filtering emails)

  • - promotes application goals such as fault-tolerance, load balancing, guaranteed delivery, priorities etc.

  • - In fact email systems could make use of MOM but MOM supports database, workflow mgmt, groupware, and batch processing applications as well


General architecture of a message queuing system 1
General Architecture of a Message-Queuing System (1)

e.g. 127.23.45.01

  • The relationship between queue-level addressing and network-level addressing.


General architecture of a message queuing system 2
General Architecture of a Message-Queuing System (2)

2-29

  • The general organization of a message-queuing system with routers.

  • (routers know the network topology)


Message brokers
Message Brokers

2-30

  • The general organization of a message broker in a message-queuing system.

  • Broker: conversion between different message formats (interoperability)


Example ibm mqseries
Example: IBM MQSeries

2-31

  • General organization of IBM's MQSeries message-queuing system.

  • (used with financial mainframes e.g. banks)

  • MCA: message channel agent

  • Channel: a (TCP) connection between 2 MCAs


Channels in ibm mqseries
Channels in IBM MQSeries

  • Some attributes associated with message channel agents.


Message transfer 1 ibm mqseries
Message Transfer (1) IBM MQSeries

  • The general organization of an MQSeries queuing network using routing tables and aliases.

  • (QM: Queue Manager, SQ: Send Queue, LA: Local Alias)


Message transfer 2 ibm mqseries
Message Transfer (2) IBM MQSeries

  • Basic Primitives available in an IBM MQSeries MQI


Data stream 1
Data Stream (1)

  • Setting up a stream between two processes across a network.


Data stream 2
Data Stream (2)

2-35.2

  • Setting up a stream directly between two devices.


Data stream 3
Data Stream (3)

  • An example of multicasting a stream to several receivers.

    Transmission:

    • Asynchronous: data units are temporally independent (e.g. text)

    • Synchronous: there is a max. end-to-end delay for each data unit

    • Isochronous: min. and max. delays = jitter (e.g. continuous media)


Specifying qos 1
Specifying QoS (1)

  • A flow specification.


Specifying qos 2
Specifying QoS (2)

  • The principle of a token bucket algorithm.


Setting up a stream
Setting Up a Stream

  • The basic organization of RSVP for resource reservation in a distributed system.

  • Data link layer: (frame) priorities

  • ATM: QoS parameters (min./max. rate, max. jitter, ..)


Synchronization mechanisms 1
Synchronization Mechanisms (1)

  • The principle of explicit synchronization on the level data units.


Synchronization mechanisms 2
Synchronization Mechanisms (2)

2-41

  • The principle of synchronization as supported by high-level interfaces.


ad