slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter 3: Network and Communication PowerPoint Presentation
Download Presentation
Chapter 3: Network and Communication

Loading in 2 Seconds...

play fullscreen
1 / 44

Chapter 3: Network and Communication - PowerPoint PPT Presentation


  • 235 Views
  • Uploaded on

Chapter 3: Network and Communication. What is a network? What types of network are there? What networking standards are there? How do you represent information? What is communication protocol? What are communication models? (message-passing, stream communication and RPC).

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 'Chapter 3: Network and Communication' - barth


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
slide1

Chapter 3: Network and Communication

  • What is a network?
  • What types of network are there?
  • What networking standards are there?
  • How do you represent information?
  • What is communication protocol?
  • What are communication models? (message-passing, stream communication and RPC)

Distributed Systems

slide2

Anatomy of a network

  • A set of interconnected resources
  • Hosts that run network applications software
    • Clients and servers
    • Set of peers
  • The network infrastructure that interconnects the hosts
    • The networking hardwareand software
      • Network node devices such as routers and switches
      • Links: cables, connectors, network interfaces

Distributed Systems

slide3

Types of network

  • Main types:
    • LAN, WAN, MAN, and Internet
  • LAN (Local Area Network) is mainly private
    • Ether net, Token ring
    • Or interconnected
  • WAN (Wide Area Network) can be private or public
    • Interconnected
  • MAN (Metropolitan Area Network) is mainly public
    • Interconnected by Optical fibre
  • Global Network is public
    • The internet
    • The telephone network

Distributed Systems

slide4

To the

Internet

To offsite

LANs

Interconnecting LANs and WANs

  • Host systems usually connect into a LAN switch
    • Number of hosts limited by the number of ports on the switch
  • Routers have two main uses
    • Interconnecting LANs
    • Connecting to a WAN or to the Internet
  • Routers interconnect LANs
    • To separate the users
    • To separate the traffic

switch

router

Distributed Systems

slide5

The OSI and IETF Protocol Suites

IETF: The Internet Engineering Task Force

OSI: Open System Interconnection Reference Model

OSI model

IETF model

Layer 7- Application

application

protocols

layers 5/6/7:Application

Layer 6 - Presentation

Layer 5 - Session

TCP, UDP

Layer 4 - Transport

IP

Layer 3 - Network

networking

protocols

Logical

MAC

PPP, 802.3,5,11, etc

Layer 2 - Link:

Layer 1 - Physical

Physical

Distributed Systems

slide6

Application

Layer

Application data

Transport header andpayload (e.g. TCP segment)

Transport

Layer

T hdr

App data

Network header andpayload (e.g. IP packet)

Network

Layer

N hdr

Transport

Link header and payload

(e.g. Ethernet frame)

Link Layer

L hdr

Network

CRC

Physical Layer

101011100101

Protocol Data Encapsulation

Distributed Systems

slide8

Addresses

Addresses

Webclient

DNSclient

URL

Web server

Source port

Destination port

TCP

UDP

TCP

UDP

Transport protocol

Transport protocol

Encapsulation

Encapsulation

IP

IP

Source IP

Destination IP

Physical network

Physical network

Source NIC

Destination NIC

Protocol Data Flow

Distributed Systems

slide9

Communication Models

  • Message Passing
  • lowest level of communication, e.g. sockets
  • unstructured peer-peer IPC
  • varieties of communication patterns
  • Data Stream
  • continuous media
  • satisfy real time data services
  • Request / Reply semantics
  • basis of Client-Server
  • RPC (Remote Procedure Call)
  • RMI (Remote Method Invocation)

Distributed Systems

message passing definitions 1
Message Passing Definitions(1)
  • Procedures: send, receive, accept, create, connect, locate , reply, acknowledge
  • Multiplicity: point-to-point,broadcast, multicast
  • Message Content: data or instruction, by value or by reference (address)
  • Channels:
    • - link, port, mailbox
    • - direction can be uni-diection or bi-direction
    • - capacity can be unbounded (i.e. asynchronous, no blocking)
    • or null (implies synchronous) or fixed (implies buffering)
  • Message Receipt:
    • explicit receive – receiver can select message, call get, receive
    • implicit receive – receiver must receive from sender, reference the variable causes message reception (do not have to call get)

Distributed Systems

message passing definitions 2
Message Passing Definitions(2)
  • Synchronous/Asynchronous
    • Synchronous – receiver waits ready for sender message and responds in real time (e.g. phone call). Both sender and receiver return when transfer is complete. No buffer is required. (both must block until comm. ends)
  • Asynchronous – sender sends message into buffer, message picked up later at receivers convenience (e.g. mailbox). Sender process returns whether or not a message is received. Receiver blocks until the message is available
    • Blocking/Non-Blocking
    • Blocking – sender cannot proceed after sending message until receiver picks up message
    • Non Blocking – sender can continue as soon as message send is done (e.g. added to buffer)
    • Sender/Receiver Naming
    • Static – sender and receiver names (location) fixed
    • Dynamic – names may change (e.g. ask a static name server

Distributed Systems

message passing definitions 3
Message Passing Definitions(3)
  • Connection Link
    • Connection Oriented – link is established and held for duration of service. Guaranteed link but bandwidth may be wasted.
    • Connectionless – connection not established until message send occurs e.g. different packets sent by different routes
  • Transient
    • message is only stored by system while sender and receiver are executing (e.g. MSN messenger) (both must be running)
  • Persistent
    • message is stored and delivered by system, even if receiver is not executing (e.g. email)

Distributed Systems

slide13

Persistence and Synchronicity in Communication (1)

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

Distributed Systems

slide14

Persistence and Synchronicity in Communication (2)

(a) Persistent asynchronous communication

(b) Persistent synchronous communication

Distributed Systems

slide15

Persistence and Synchronicity in Communication (3)

(c) Transient asynchronous communication

(d) Receipt-based transient synchronous communication

Distributed Systems

slide16

Persistence and Synchronicity in Communication (4)

(e) Delivery-based transient synchronous communication at message delivery

(f) Response-based transient synchronous communication

Distributed Systems

slide17

Socket Programming

  • A socket is a communication endpoint between processes
  • A socket forms the API that allows processes to communicate point-to-point over the internet, within a LAN or within a single computer
  • Each internet host implements the TCP/IP family of protocols
  • A socket is identified by a socket address consisting of an IP (version 4) address and port number e.g. 129.86.5.20:80
  • IP addresses are stored as unsigned 32 bit integer, and frequently represented in dotted decimal notation.
  • /* Internet address structure */
  • structin_addr {unsigned ints_addr;};
  • Port numbers are unsigned 16 bit integers (range 0-65535). Port numbers 0-1024 are well known and reserved, e.g. 21 ftp, 23 telnet, 25 email, 80 http...

Distributed Systems

slide18

Socket Families and Types

  • AF_UNIX – for communicating between processes on the same (UNIX) computer.
  • AF_INET – for communicating between processes on different machines connected by the internet or a LAN.
  • SOCK_STREAM is for reliable TCP (Transmission Control Protocol) connection oriented communication that can be for AF_UNIX or AF_INET sockets. These streaming sockets allow for continuous communication.
  • SOCK_DGRAM is for unreliable UDP (User Datagram Protocol) connectionless communication in which process are not required to connect to the socket continuously. These datagram sockets allow data to be sent in finite packets (or datagrams). The datagram protocol applies only to internet AF_INET sockets.

Distributed Systems

slide19

Socket primitives for TCP/IP

Distributed Systems

slide20

socket()

create socket

bind()

bind local IP address of socket to port

place socket in passive mode ready to accept requests

listen()

take next request from queue (or wait) then forks and create new socket for client connection

accept()

socket()

Blocks until

connection

from client

Issue connection request to server

connect()

recv()

send()

Transfer message strings with

send/recv or read/write

Process request

send()

recv()

Close socket

close()

close()

Server

Client

TCP/IP Socket Calls for Connection

Distributed Systems

slide21

socket()

create socket

bind()

bind local IP address of socket to port

Receive senders address

and senders datagram

recvfrom()

blocks until

datagram

received

from a client

socket()

request

specify senders address

and send datagram

sendto()

Process request

reply

sendto()

recvfrom()

close()

Close socket

Server

Client

UDP/IP Socket Calls for Connection

Distributed Systems

slide22

UDP/IP Socket program example(1)

#include <stdio.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#define PORT_NUM 2222

char message[20];

main(){ /* process:send1.c */

intsend1,fromlen;

structsockaddr_insend1_addr, send2_addr;

send1 = socket(AF_INET, SOCK_DGRAM, 0);

send1_addr.sin_family = AF_INET;

send1_addr.sin_addr.s_addr = INADDR_ANY;

send1_addr.sin_port = 0;

bind(send1, (structsockaddr*)&send1_addr, sizeof(send1_addr));

send2_addr.sin_family = AF_INET;

send2_addr.sin_addr.s_addr = inet_addr(“xxx.xxx.xxx.xxx”);

send2_addr.sin_port = PORT_NUM;

strcpy(message, “send2, hi!”);

sendto(send1, message, sizeof(message), 0,

(structsockaddr) &send2_addr, sizeof(send2_addr));

fromlen = sizeof(send2_addr);

recvfrom(send1, message, sizeof(message), 0,

(structsockaddr) &send2_addr, &fromlen);

printf(“send2 says: %s\n”, message);

close(send1);

}

Distributed Systems

slide23

UDP/IP Socket program example(2)

#include <stdio.h>

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#define PORT_NUM 2222

char message[20];

main(){ /* process: send2.c */

intsend2,fromlen;

structsockaddr_insend1_addr, send2_addr;

send2 = socket(AF_INET, SOCK_DGRAM, 0);

send2_addr.sin_family = AF_INET;

send2_addr.sin_addr.s_addr = INADDR_ANY;

send2_addr.sin_port = PORT_NUM;

bind(send2, (structsockaddr*)&send2_addr, sizeof(send2_addr));

fromlen = sizeof(send2_addr);

recvfrom(send2, message, sizeof(message), 0,

(structsockaddr) &send1_addr, &fromlen);

printf(“send1 says: %s\n”, message);

strcpy(message, “hi send1, how are you!”);

sendto(send2, message, sizeof(message), 0,

(structsockaddr) &send1_addr, sizeof(send1_addr));

close(send2);

}

Distributed Systems

slide24

Stream Oriented Communication

sender

receiver

  • Continuous Media: the temporal (time) relationships between different data item are fundamental to correctly interpreting what the data actually means (movies, audio streams).
  • Discrete Media: the temporal relationships between data items are not important (text, still images).

Distributed Systems

slide25

Data Stream transmission modes

  • Asynchronous mode: no timing constraints on data stream.
  • Synchronous mode: there is a max end-to-end delay, but how about too fast?
  • Isochronous mode: data items are transferred on time, both max delay and min delay.

Distributed Systems

slide26

Request / Reply Model

Principle of RPC between a client and server program.

Distributed Systems

slide27

Local Procedure Call

main(){

char cip[] = “Buubdl!bu!ebxo”; /* cipher*/

int key = 1;/* secret key */

intlen = decrypt(cip, key); /* LPC */

/* other processing */

}

int decrypt(char * s, int key){ /* decryption */

inti = 0;

while( *s) { *s -= key; i++; s++;}

return i;

}

call

LPC

procedure

return

stack

stack

stack

Return address

i -> 0

s -> main.cip

key -> 1

before

after

cip ->Buubdl!bu!ebxo

len -> ?

key -> 1

cip ->Buubdl!bu!ebxo

len -> ?

key -> 1

cip ->Attack at dawn

len -> 14

key -> 1

Distributed Systems

slide28

Remote Procedure Call

Binding server

binder

recvreq

register

or search

return

(0)

program stub

(1)

(8)

stub procedure

(5)

(6)

(2)

LPC

Bind req

Recv bind

marshal

Send req

Recv result

unmarsh

return

recv req

unmarsh

LPC

marshal

send

result

execute

return

(3)

(5)

(1)

(4)

(8)

(7)

(6)

client

server

Distributed Systems

slide29

Goal: make RPC transparent

  • (i.e., behave just like normal (local) procedure call)
  • Potential Problems
  • address space (server location)
  • parameters passing methods
  • and failures of server or clients
  • Basic RPC
  • - normal procedure call : count = read(fd,buf,nbytes)
  • Parameters passing methods
  • - call-by-value
  • - call-by-reference
  • call-by-copy/restorRPC
  • implementation uses client stubs in the place actual procedure

Distributed Systems

slide30

Remote Procedure Call: steps

(0) Remote procedures registration;

(1) Client procedure calls client stub in normal way;

(2) Client stub sends a binding request asking for information;

(3) Binding server searches for binding and reply to client stub;

(4) Client stub packs a message (marshalling) and send to server stub;

(5) Server stub unpacks parameters (unmarshalling), invokes LPC;

(6) Server procedure executes and returns results to server stub;

(7) Server stub packs results (marshalling) and sends to client stub;

(8) Client stub unpacks results and returns to client procedure.

Call-by-value: parameter is a straight value (int, float, …)

Call-by-reference: parameter is a pointer to anything (int, record, array, pointer, …)

Distributed Systems

slide31

Parameter Passing

- parameter marshaling -- packing parameters into a msg

- n = sum(4,7)

must be able to:

- handle different data representations

EBCDIC, ASCII, Unicode, floating point numbers, little endian (bytes from

right to left, 486) and big endian (bytes from left to right, SPARC)

-Need to represent data in standard format e.g XDR

- how to handle pointers : address at 1000

send a copy of data and restore value on return at a ddress

Binding client to sever:

Static binding: server address known at complete time

Dynamic binding (server location resolved at run time)

- how to locate a server: use name server

- how to register a server : need registry service at registry directory

- Server is identified by (name, version, handle, unique-id)

Distributed Systems

slide32

RPC Semantics in the Presence of Failures (1)

- goal: RPC behave like local procedure call

1) cannot locate the server

- server may be down

- Version number mismatch

- In this case : need to raise an exception

2) request msg is lost

use timer and resend request msg

Distributed Systems

slide33

Failure semantics continue (2)

3) reply msg is lost

- use timer and resent another request

- server need to tell whether the request is duplicate

unless the request is idempotent

Idempotent means: the operation can be executed more

than one without harm

e.g., read (fd, buf, n)

read (fd, buf, pos, n)

deposit (money) -- not possible to make it Idempotent

ii) assign request nos and keep track

Distributed Systems

slide34

Failure semantics continue (3)

  • 4) server crashes after receiving a request
  • unique no not enough since cannot know whether or not RPC done or not
  • - Possible Semantics
  • i) at least once (retransmit after time out)
  • ii) at most once ( do not retransmit request)
  • iii) exactly once (not possible to implement)
  • 5) client crashes after sending a request
  • - make request and then crash
  • Server computation becomes orphan - potential problems -- waste cycles at server , etc.
  • how to deal with orphans: extermination for long computations, problem if server is holding a lock

Distributed Systems

slide35

Example: SUN RPC (1)

/* eXtended Data Representation (XDR) definition,file name:caesar.x */

const MAX = 100;

typedefstruct { /* return type */

intlen;

char code[MAX];

} Data;

typedefstruct { /* parameter type */

int key;

char cipher[MAX];

} Args;

program CAESAR { /* CAESAR program */

version VERSION {

Data DECRYPT(Args) = 1; /* decryption procedure */

Data ENCRYPT(Args) = 2; /* encryption procedure*/

} = 5;

} = 8888;

Distributed Systems

slide36

Example: SUN RPC(2)

Invoke XDR compiler rpcgento generate the following files:

  • Client stub
  • Server main program and server stub
  • XDR parameter marshalling/unmarshalling functions
  • Program header file, caesar.h, which includes constants, user defined types, remote procedure prototypes.

Now, we are ready to design other programs.

Distributed Systems

slide37

Example: SUN RPC(3)

/* client program file:client.c */

#include <rpc/rpc.h>

#include “caesar.h”

main(){

CLIENT *cp;

char *serverName = “Caesar_server”;

Argsarg;

Data * plaintext;

/* create client pointer */

cp = clnt_create(serverName, CRESAR, VERSION, “udp”);

if (cp == NULL) exit(1);

arg.key = 1; /* set RPC parameters */

arg.cipher = “Buubdl!bu!ebxo”;

plaintext = decrypt_2(&arg, cp); /* issue RPC */

/* other processing */

clnt_destroy(cp); /* delete client pointer */

}

/* server program file:server.c */

#include <rpc/rpc.h>

#include “ceasar.h”

Data* decrypt_2(Args *a){ /* decryption */

static Data output; /* must be static */

char s = a->cipher;

int i = 0;

while( *s) { output.code[i] = *s - key; i++; s++;}

output.len = i;

return &output; /* return result */

}

Data* encrypt_2(args *a){ /* encryption */

/* … */

}

Distributed Systems

slide38

Example: SUN RPC(4)

Server program

Server code

Server stub

RPC

library

XDR Definition

Header file

client stub

Client program

Client code

The steps in writing a client and a server in SUN RPC

Distributed Systems

slide39

The steps in writing a client and a server in DCE RPC

IDL: Interface Definition Language; uuidgen: IDL file generator

DCE: Distributed Computing Environment (Open Software foundation)

Distributed Systems

slide40

Re-sending RPC

Replica filtering

Re-sending results

RPCsemantics

no

no

no

maybe

yes

no

no

at-least-once

yes

yes

no

maybe-once

yes

yes

yes

at-most-once

RPC Semantics

LPC has exact-once semantics, how about RPC?

Server dead? RPC request lost? Reply lost?

  • Re-sending RPC (time out)
  • Replica filtering
  • Re-sending results

Distributed Systems

remote method invocation
Remote Method Invocation
  • Remote Method Invocation (RMI) is a Java mechanism similar to RPCs. (java implementation of RPC)
  • RMI allows a Java program on one machine to invoke a method on a remote object.
remote method invocation1
Remote Method Invocation
  • RMI and RPC differs in two ways:
  • RPCs support procedural programming whereby only remote procedures or functions may be called. RMI is object based: It supports invocation of methods on remote objects.
  • The parameters to remote procedures are ordinary data structures in RPC; with RMI it is possible to pass objects as parameters to remote methods.
  • If the marshaled parameters are local (non remote) objects, they are passed by copy using a technique known as object serialization.
    • Object serialization allowed the state of an object to be written to a byte stream.
creating a distributed system with rmi
Creating a Distributed System with RMI
  • Four major steps
    • Define remote interface
      • Describes client/server communication
      • Client calls remote methods, server implements them
    • Define server application to implement remote interface
      • Same name as remote interface, ends with Impl
    • Define client application that uses remote interface reference
      • Interacts with server implementation
    • Compile and execute server and client