Distributed Computing: Communication Abstractions and Paradigms, Study notes of Computer Science

The history of distributed computing and the important question of how communication should be presented to the programmer. It discusses different communication abstractions such as inter-process communication (ipc), remote procedure calls (rpc), distributed shared memory, and object-oriented model. The document also covers inter-process communication using unix sockets, rpc implementation, distributed objects using corba, and distributed shared memory. Additionally, it touches upon group communication and the client-server model.

Typology: Study notes

Pre 2010

Uploaded on 03/16/2009

koofers-user-nop
koofers-user-nop 🇺🇸

8 documents

1 / 12

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
Distributed Computing
A Programmer’s Perspective
Advent of Distributed
Computing
Early programming models were designed for
a single computer – there was no notion of
communication between multiple machines
With the advent of computer networks, an
important question arose – how should
communication be presented to the
programmer? what communication
abstractions make more sense?
Different paradigms presented different
communication abstractions
pf3
pf4
pf5
pf8
pf9
pfa

Partial preview of the text

Download Distributed Computing: Communication Abstractions and Paradigms and more Study notes Computer Science in PDF only on Docsity!

Distributed Computing

A Programmer’s Perspective

Advent of Distributed

Computing

 Early programming models were designed for

a single computer – there was no notion of

communication between multiple machines

 With the advent of computer networks, an

important question arose – how should

communication be presented to the

programmer? what communication

abstractions make more sense?

 Different paradigms presented different

communication abstractions

Main Issue in Designing

Communication Abstractions

 Should the programmer write communication

explicitly or should communication be hidden

from the programmer?

I see one machine running one program

What should I run where?

Communication is transparent

Communication is explicit

Paradigms for Distributed

Computing

 UNIX IPC (Inter-Process Communication)

 RPC (Remote Procedure Calls)

 Distributed Shared Memory

 Object-Oriented Model

Implementing RPC

 Making remote function calls look like local

ones

main() { … function() … }

Machine A

OS

function() { send message wait for reply return }

Machine B

OS

parent() { wait for call call function() send reply }

function() { … }

Distributed Objects (CORBA)

 World is made of objects

 Programmer invokes methods on

objects without having to know where

the objects are

 Objects reside on multiple machines.

System delivers method calls to objects

across network (CORBA)

Distributed Objects (CORBA)

 ORB handles remote object invocations

main () { … obj.method() … }

Object Request Broker

Distributed Objects

Find object

Distributed Shared Memory

(Not widely used)

 Program has big virtual address space

 Address space is distributed among multiple

machines

Code segment

Data segment

Machine A Machine B

Machine C

Machine D

Machine E

Program

Client-Server Model

 World is made of:

 Servers: machine who provide services to a

population of clients (e.g., web servers,

pop mail servers, audio servers, etc)

 Clients: those who connect to servers

(e.g., browsers, mail clients, etc)

 Servers are “well known”

Peer-to-Peer

 All machines are equal – there is no

separation into servers and clients

 Machines collectively perform a service to

their peers

 Advantages:

 No central point of failure  Potentially more scalable

 Disadvantages:

 More difficult to program

The Socket Abstraction

Client

 Client plugs into a server port

 Connection creates a bi-directional pipe

Server

Port

A Simple Client-Server

Program

bind() Well-known port listen()

accept()

read()

write()

close()

eof()?

write()

read()

connect()

socket()

socket()

close()

Client

Server

The listen() call

 Moves the socket from the CLOSED to

the LISTEN state in the TCP state

diagram – socket is now ready to

accept connections

 int listen (int sockfd, int backlog)

Server Initialization

OS

  1. socket()

Web Server

  1. bind(80)
  2. listen()

80 Listen queue

The connect() Call

 Establishes a connection with a server

 int connect (int sockfd, const struct

sockaddr * servaddr, socklen_t addrlen)

Connecting to the Server

OS

  1. socket()

Web Server

  1. bind(80)
  2. listen()

80 Listen queue

Client

connect()

Request from (IP, port)