Appunti di Distributed System

Modelling

• Run Time Architecture
  • Client-Server
  • Service Oriented
  • Web Service
  • P2P
  • Object Oriented
  • Data Center
  • Event Based
  • C-Rest
  • Linda
  • Mobile Code
  • Remove Evaluation
  • Mobile Agent
  • Code On Demand
• Interaction Model
  • Synchronous
  • Asynchronous
• Failure Model
  • Omission
  • Byzantine
  • Timing

Modelling

• RPC
• RMI
• Message Oriented
  • Message Passing
  • Message Queueing
• Stream Oriented
  • Public\Subs

Naming

• Flat Naming
  • Simple
  • Home Based
• Structured Naming
  • Hierarchical
• Attribute Based Naming
• Removinc Unrefered Entity
  • Reference Counting
  • Reference Listing
  • Mark and Sweep

Synchronization

• Physical Clock
  • Cristian
  • Berkely
  • Network Time Protocol
• Logical Time
  • Happened Before
  • Scalar Clock
  • Vector Clock
• Mutual Exclusion
  • Simple Solution
  • Scalar Clock
  • Token Ring
• Leader Election
  • Bully Election
  • Ring Solution
• Collecting Global State
  • Chandy Laport
• Distributed DeadLock
  • Centralized
  • Distributed
• Distributed Transaction
  • On Copy
  • On Data
  • Atomicity
  • Concurrency
  • 2PL
    • Pessimistic
    • Optimistic
• Termination Detection
  • Distributed Snapshot
  • Dijkstra-Sholten

Fault Tolerance

• Failures
  • Omission
  • Byzantine
  • Timing
• Consensus Problem
  • FloodSet
  • Laport Algorithm
• Reliable Group Communication
  • Scalable Multicast
  • Close Synch
  • Virtual Synch
• Commit Protocol
  • 2 Phase Commit
  • 3 Phase Commit
• Recovery Technique
  • CheckPoint
    • RollBack
    • Checkpoint
  • Logging
    • Pessimistic
    • Optimistic

Replication and Consistency

• Consistency Protocols
  • BackUP
  • SingleLeader
  • MultiLeader
  • LeaderLess
• Data Centric
  • Linearizability
  • Sequential
  • Causal
  • FIFO
• Client Centric
  • Monotonic Read
  • Monotonic Write
  • Read Your Write
  • Write your Read
• Design Strategy
  • Replica Replacement
    • Permanent
    • Server Initialized
    • Client Initialized
  • Update Propagation
    • send Update
    • Send Notification
    • Send Info
  • How to Propagate
    • Push- Based
    • Pull-Based
  • Propagation Strategy
    • Leader
    • LeaderLess

Peer- To -Peer

• Napster: Centralized Search
• Gnutella: Query Flooding
• Kazaa: Hierarchy Topology
• BitTorrent: Collaborative System
• BitCoin: BlockChain
• DHT: Structured topology

Big Data Platform

• Map Reduce
  • Apache Spark
  • Apache Flink

Security

• Cryptography
  • Asynchronous
  • Synchronous
• Secure Channel
  • Challenge Response
  • Public Key
    • KDC
• Secure Management
  • Logical Key
  • Centralized Flat Table
• Secure Replication Server
  • Simple Sol
  • (n,m) Threshold
  • Applied To Signature
• Access Control

Communication

Different type of communication:

• Transient: Client must be both online
• Persistent: Receiver could download the data after
• Asynchronous
• Synchronous

Remote procedure Calls (RPC)

There are different mechanisms to pass parameters: By value, reference or Copy/Restore

I need to know the interface of the procedure (signature) and client/server programming language to apply RPC.

To implement RPC we need to convert Structured Data into byte stream (serialization) and hosts may use different data representation, so conversion is needed (marshalling).

Interface Definition Language (IDL) is used to describe the procedure signatures in the middleware.

Passing by reference is not supported: many languages don’t have the notion of reference, and we can't use pointers due to the lack of shared memory.

Binding the client to the server: we need to find out which server provides a given service. We have 2 problems: find out where the server process is and how establish communication with it

Sun’s Solution:Introduce a daemon process (port map) that binds call and server port: the server picks an available port and tells it to the portmap. Client contact a given portmap to establish communication.

Portmap provides only server info to local clients, so it solves only the second problem.

DCE’s solution:The directory server enables location transparency: client needs to know only where the directory server is. In DCE, the directory service can actually be distributed.

Lightweight RPC: RPC used on the same machine: not shared memory on application level but at OS level. It is invoked:- client puts copies the parameters in shared stack and do a system call- kernel is asked to switch to execute the procedure in the server- result are copied on the stack and kernel switch to the client applicationIn this way we use less thread/processes and economize parameter copy

Type of Synchronous in RPC

Synchronous

The caller is suspended while the call is done.

Asynchronous

If no result is needed execution can resume after a server ACK.

To deal with the result, the caller may invoke the callback.

Batched RPC: RPCs that don't require a result are buffered on the client until a non-batched call is required.