Distributed Systems

1
Distributed Systems

• (lecture 4 - 9/10/05)- Middleware (I)

2
Sistemi Distribuiti

• 7 CFU, 54 ore complessive in 9 settimane
• Lezioni
• Lunedì, 10.30-12.00 Aula Le
• Martedì, 10.30-12.00, Aula Le
• Mercoledì, 10.30-12.00, Aula Le
• Ricevimento studenti
• Martedì, 14.30-16.30, DEI-G stanza 313
• per appuntamento
• carlo_at_dei.unipd.it, 049-827.7729,

3
Sistemi Distribuiti

• Una piccola formalità Iscrizioni chiuse
• 120 iscritti
• Modalità desame, aspetti generali
• 5 appelli nel corso della.a.
• 2 appelli, al termine del primo trimestre
  (trimestre di erogazione del corso-sessione
  autunnale)
• nessun vincolo alla partecipazione
• Lesame si conclude con una discussione orale
• Modalità desame aspetti particolari (ancora in
  via di definizione)

4
Sistemi Distribuiti

• Avvisi
• Trasparenze alle lezioni disponibili a
• http//www.dei.unipd.it/carlo/DS06
• ...firme di frequenza...

5
Software Layers
6
The layered view...

• though appropriate for simple types of resource
  data sharing
• e.g. databases of names/addresses/exam grades
• too restrictive for more complex functions?
• reliability, security, fault-tolerance, etc,
  need access to applications data
• see end-to-end argument Saltzer, Reed
• Clarke

7

• Some communiction-related functions can be
  completely and reliably implemented only with the
  knowledge and help of the application standing at
  the end points of the communication systems
• Saltzer, J.H., Read, D.P. and Clarke, D. (1984).
  End-to-End Arguements in System Deisgn. ACM
  Transactions on Computer Systems Vol. 2, No 4,
  pp. 277-288

8
Architectural models

• Define
• software components (processes, objects)
• ways in which components interact
• mapping of components onto the
  underlying network
• Why needed?
• to handle varying environments and usage
• to guarantee performance

9
Main types of models

• Client-server
• first and most commonly used
• Multiple servers
• to improve performance and reliability
• e.g. search engines (1000s of computers)
• Proxy servers
• to reduce load on network, provide access
  through firewall
• Peer processes
• when faster interactive response needed
• Mobile Agent

10
Design Requirements for DSs

• Judging how good the architecture is...
• Performance
• how fast will it respond?
• Quality of Service
• are video frames and sound synchronised?
• Dependability
• does it work correctly?

11
Fundamental models

• Interaction model ... It reflects communication
  delays and limited accuracy
• Failure model ...
• Security model ...

12
Interaction model ...

• Synchronous distributed systems
• Step execution, message trasmission time and
  clock drift are bounded.
• Asynchronous distributed systems
• Agreement problem
• Temporal ordering of events ... Logical time

13
Failure model ...
14
Security models
15
Figure 2.13The enemy
16

• Cryptography and shared secrets
• Authentication
• Secure channels

17
(No Transcript)
18
Software Layers
19
Middleware provides...

• support for distributed processes/objects
• suitable for applications programming
• communication via
• remote method invocation (Java RMI), or
• remote procedure call (Sun RPC)
• services infrastructure for application
  programs
• naming, security, transactions, event
  notification, ...
• products CORBA, DCOM

20
Inter-Process Communication

• ... Middleware level ...
• Support for communication between objects
• Client-server
• Group communication

21
Inter-Process Communication

• Message passing
• send, receive, group communication
• synchronous versus asynchronous
• types of failure, consequences
• socket abstraction
• Java API for sockets
• connectionless communication (UDP)
• connection-oriented communication (TCP)

22
API for Internet programming...
23
Inter-process communication

• Distributed systems
• consist of components (processes, objects)
  which communicate in order to co-operate and
  synchronise
• rely on message passing since no shared memory
• Middleware provides programming language
  support, hence
• does not support low-level untyped data
  primitives (this is the function of operating
  system)
• implements higher-level language primitives
  typed data

24
Inter-process communication
25
Communication service types

• Connectionless UDP
• send and pray unreliable delivery
• efficient and easy to implement
• Connection-oriented TCP
• with basic reliability guarantees
• less efficient, memory and time overhead for
  error correction

26
Connectionless service

• UDP (User Datagram Protocol)
• messages possibly lost, duplicated, delivered
  out of order, without telling the user
• maintains no state information, so cannot
  detect lost,
• duplicate or out-of-order messages
• each message contains source and destination
  address
• may discard corrupted messages due to no error
  correction (simple checksum) or congestion
• Used e.g. for DNS (Domain Name System).

27
Connection-oriented service

• TCP (Transmission Control Protocol)
• establishes data stream connection to ensure
  reliable, in-sequence delivery
• error checking and reporting to both ends
• attempts to match speeds (timeouts, buffering)
• sliding window state information includes
• unacknowledged messages
• message sequence numbers
• flow control information (matching the speeds)
• Used e.g. for HTTP, FTP, SMTP on Internet.

28
Timing issues

• Computer clocks
• may have varying drift rate
• rely on GPS radio signals (not always
  reliable), or synchronise via clock
  synchronisation algorithms
• Event ordering (message sending, arrival)
• carry timestamps
• may arrive in wrong order due to transmission
  delays

29
Types of interaction

• Synchronous interaction model
• known upper/lower bounds on execution speeds,
  message transmission delays and clock drift rates
• more difficult to build, conceptually simpler
  model
• Asynchronous interaction model (more common, cf
  Internet, more general)
• arbitrary process execution speeds,
  message transmission delays and clock drift rates
• some problems impossible to solve (e.g.
  agreement)
• if solution valid for asynchronous then also
  valid for synchronous.

30
Send and receive

• Send
• send a message to a socket bound to a process
• can be blocking or non-blocking
• Receive
• receive a message on a socket
• can be blocking or non-blocking
• Broadcast/multicast
• send to all processes/all processes in a group

31
Receive

• Blocked receive
• destination process is blocked until message
  arrival
• most commonly used
• Variations
• conditional receive (continue until receiving
  indication that message arrived or polling)
• timeout
• selective receive (wait for message from one
  of a number of ports)

32
Asynchronous Send

• Characteristics
• send is non-blocking (process continues after
  the message is sent out)
• buffering needed (at receive end)
• mostly used with blocking receive
• usable for multicast
• efficient implementation
• Problems
• buffer overflow
• error reporting (difficult to match error with
  message)
• Maps closely onto connectionless service.

33
Synchronous Send

• Characteristics
• send is blocking (sender suspended until
  message received)
• synchronisation point for both sender
  receiver
• easier to reason about
• Problems
• failure and indefinite delay causes indefinite
  blocking (use timeout)
• multicasting/broadcasting not supported
• implementation is more complex
• Maps closely onto connection-oriented service.

34
Location transparency in send/receive

• Clients refer to services by name a name server
  (binder) translates names into server locations
  at run-time.

35
Sockets and ports
36
Sockets

• Characteristics
• endpoint for inter-process communication
• message transmission between sockets
• socket associated with either UDP or TCP
• processes bound to sockets, can use multiple
  ports
• no port sharing unless IP multicast
• Implementations
• originally BSD Unix, but available in Linux,
  Windows,
• here Java API for Internet programming

37
Java API for Internet addresses

• Class InetAddress
• uses DNS (Domain Name System)
• InetAddress aC
• InetAddress.getByName(gromit.cs.bham.ac.uk)
• throws UnknownHostException
• encapsulates detail of IP address (4 bytes for
  IPv4 and
• 16 bytes for IPv6)

38
Java API for Datagram Comms
39
(No Transcript)
40
Java API for Datagram Comms

• Class DatagramSocket
• socket constructor (returns free port if no
  arg)
• send a DatagramPacket, non-blocking
• receive DatagramPacket, blocking
• setSoTimeout (receive blocks for time T and
  throws
• InterruptedIOException)
• close DatagramSocket
• throws SocketException if port unknown or in
  use
• See textbook site cdk3.net/ipc for complete code.

41
UDP client example
42
UDP server example
43
Java API for Data Stream Comms

• Data stream abstraction
• attempts to match the data between
  sender/receiver
• marshaling/unmarshaling
• Class Socket
• used by processes with a connection
• connect, request sent from client
• accept, issued from server waits for a
  connect request,blocked if none available
• See textbook site cdk3.net/ipc for complete code.

44
Java API for Data Stream Comms

• Class ServerSocket
• socket constructor (for listening at a server
  port)
• getInputStream, getOutputStream
• DataInputStream, DataOutputStream
• (automatic marshaling/unmarshaling)
• close to close a socket
• raises UnknownHost, IOException, etc

45

• In the next example...
• TCP Client
• makes connection, sends a request and receives
  a reply
• TCP Server
• makes a connection for each client and then
  echoes the clients request

46
TCP client example
47
TCP server example
48
TCP server example ctd
49
Client-Server Interaction

• Request-reply it supports the roles and
  message exchanges in client-server interaction
• port must be known to client processes (usually
  published on a server)
• client has a private port to receive replies

50
Client-server communications

• Notes
• ACK are redundant ....
• Flow control may be redundant ...
• send/receive can be implemented either using UDP
  or TCP

51
Request-Reply Communication
52
Operations of Request-Reply

• public byte doOperation (RemoteObjectRef o,
  int
• methodId, byte arguments)
• sends a request message to the remote object
  and returns the reply.
• the arguments specify the remote object, the
  method to be invoked and the arguments of that
  method.
• public byte getRequest ()
• acquires a client request via the server port.
• public void sendReply (byte reply,
  InetAddress
• clientHost, int clientPort)
• sends the reply message reply to the client at
  its Internet address
• and port.

53
Message structure
54
Remote Object Reference
55
Failure model of the R-R protocol

• Omission failure
• Crash failure
• Order not guaranteed
• Timeouts
• Discarding duplicate requests

56

• Lost reply ... Repetition
• Idempotent operation it has the same effects in
  spite of the number of time it is executed.
• Trace / History

57
Exchange protocols
58
Marshalling

• Program oriented data representation (data
  structures) message oriented data representation
  (sequences of bytes)
• Communication requires data conversion
• Conversion methods
• Senders format
• Agreed external format (external data repr.)
• Needed in RMI and RPC

59
Data Marshaling/Unmarshaling

• Marshalling conversion of data into machine
  independent format, suitable for transmission
• necessary due to heterogeneity varying
  formats of internal data representation
• Unmarshalling the inverse process ...
• Approaches
• CORBA CDR (Common Data Representation)
• Java object serialisation, cf DataInputStream,

60
CORBA Common Data Representation (CDR)

• External data representation defined in CORBA 2.0
• Represent all the data type in arguments and
  return values in remote invocation.
• Short, long, unsigned short, unsigned long,
  float, double, char, boolean, octet any
  composit types
• n.b. No pointers .....

61
CORBA Common Data Representation (CDR)
62

• struct Person
• string name
• string place
• long year

63
(No Transcript)
64

• The type of the data items are not given
• Sender and recipient know types and order
• Corba IDL is used to describe data ...
• Corba interface compiler generate (un)marshalling
  operations

65
(Java) Object serialization

• public class Person implements Serializable
• private String name
• private String place
• private int year
• public Person(String aName, String aPlace, int
  aYear)
• name aName
• place aPlace
• year aYear

66

• Information about the class of each object is
  included in the serialized form.
• objects in objects are serialized too ...
• Look at class ObjectOutputStream,
  ObjectInputStream ...

67
(No Transcript)
68
Reflection

• Ability to enquire about the properties of a
  class (names and types)