Distributed Systems

1. Distributed Systems Docent: Vincent Naessens

2. Chapter 5: Naming

3. Chapter 5: Naming • 5.1. Names, identifiers and addresses • 5.2. Flat naming • 5.3. Structured naming • 5.4. Attribute-based naming

4. 5.1. Names, identifiers and addresses • Properties of a true identifier: • An identifier refers to at most one entity. • Each entity is referred to by at most one identifier. • An identifier always refers to the same entity

5. 5.2. Flat naming • Broadcasting names • EX: in LAN • broadcast IP address • Machine answers with Ethernet address • Multicasting • Joining multicast groups • Sending requests to the right multicast group • Forwarding pointers (see next slide) • Leaving pointer if a mobile entity moves from A to B • Problem: highly mobile user  many pointers

6. 5.2. Flat naming • Example: SSP chains • Server leaves a client stub if it moves to another location

7. 5.2. Flat naming • Example: SSP chains • Client redirects as he is informed of the new location • Problem: what if one machine in chain crashes? • Solution: home location always keeps a reference to current location of server

8. 5.2. Flat naming • Home-based approaches (f.i. Mobile IP) • Home location: LAN where entity is created • Home agent: located in LAN where entity is created • Care-of address: address received by another LAN

9. 5.2. Flat naming • Home-based approaches (f.i. Mobile IP) • Problem: • mobile entity moves permanently to other location • Solution: changing home location • Naming service that keeps track of home location of entities

10. 5.2. Flat naming • Distributed hash tables (f.i. Chord system) • Assign random identifiers to nodes  id • Assign random keys to items  k • k is then stored at node wit id == succ(k) • How can node id locate an item with key k? • Solution 1: each node p keeps link to succ(p) and pred(p) • Disadvantage: O(N) • Solution 2: distributed hash tables  O(log(N)) • Each node p keeps a finger table: FTp[i]=succ(p+2i-1) • Forward lookup request to q = FTp[j]<=k<FTp[j+1] • Mechanisms for joining + keeping DHTs up-to-date

11. 5.2. Flat naming • Resolving key 26 from node 1 and key 12 from node 28 in the chord system

12. 5.2. Flat naming • Distributed hash tables (f.i. Chord system) • Exploiting network proximity for assigning id’s • Topology based assignment of identifiers: • mapping world to 1 dimension, namely a ring • Proximity routing • Keeping a list of alternatives per entry in the table • Solves failures in certain intermediate nodes at lookup • Proximity neigbour selection • Slecting the nearest node as neighbour

13. 5.2. Flat naming • Hierarchical approaches: • splitting location service into domains • Each domain directory keeps list of entities in the domain and pointers to right subdomain • An entity can have belong to multiple domains

14. 5.2. Flat naming • Hierarchical approaches • Storing location information in directories

15. 5.2. Flat naming • Hierarchical approaches • Looking up a location

16. 5.2. Flat naming • Hierarchical approaches • Inserting address info about an entity in another domain

17. 5.3. Structured naming • Flat names: convenient for machines • Structured names: convenient for users • Name spaces • Name resolution • Implementation of a name space • Example: DNS

18. 5.3.1. Name spaces • Name spaces (figure)

19. 5.3.1. Name spaces • Name spaces (terminology – see course operating systems) • Absolute versus relative path name • Global name versus local name • Hard links versus soft links • Mounting  merging name spaces

20. 5.3.2. Name resolution • Information required to mount a foreign name space in a distributed system • The name of an access protocol (f.i. NFS). • The name of the server (f.i. flits.cs.vu.nl). • The name of the mounting point in the foreign name space (f.i. /home/steen/mbox). • Example: nfs://flits.cs.vu.nl//home/steen

21. 5.3.2. Name resolution

22. 5.3.3. Implemation of name space • Distribution of name space across multiple servers (for instance, DNS)

23. 5.3.3. Implemation of name space • Comparison between name servers in large-scale name spaces

24. 5.3.3. Implementation of name space • Implementation of name resolution • Assumptions: • No replication of name servers • No client-side caching • How to solve root:<nl,vu,cs,ftp,pub,glob,index.html> ? • Client accesses a local name resolver • Two strategies: • ITERATIVE NAME RESOLUTION (next slide) • RECURSIVE NAME RESOLUTION (next next slide)

25. 5.3.3. Implementation of name space • Iterative name resolution

26. 5.3.3. Implementation of name space • Recursive name resolution

27. 5.3.3. Implementation of name space • Recursive name resolution • Disadvantage: higher performance of name server • Advantages: • More effective caching of names • Reduction of communication costs • In practise: • Many organisations use a local, intermediate name server shared by all clients • Local name server caches results

28. 5.3.3. Implementation of name space • Recursive name resolution: • Name servers can cache intermediate results

29. 5.3.3. Implementation of name space • Iterative (I) versus Recursive name resolution • Communication overhead San Fransisco The netherlands

30. 5.3.4. Example: DNS • Label: max. 63 characters • Complete path name: max 255 characters • The contents of each node is formed by set of resource records (see next slides)

31. 5.3.4. Example: DNS • The most important types of resource records

32. 5.3.4. Example: DNS • An excerpt from the DNS database for the zone cs.vu.nl

33. 5.4. Attribute based naming • Naming systems: • support structured and flat names (f.i. DNS) • Directory services: • Describe entity in terms of (attr,value) pairs • Multiple implementations: • Hierarchical implementation: LDAP (section 5.4.2) • Decentralized implementations (section 5.4.3)

34. 5.4. Attribute based naming • Hierarchical implementations • LDAP = distributed implementation of directory service • Concepts in LDAP • Number of records (~ directory entries) • Each record contains a set of (attribute, value) pairs • Collection of records = directory information base • Example of a record (~directory entry):

35. 5.4. Attribute based naming • Hierarchical implementations • C, O and OU could form a globally unique name

36. 5.4. Attribute based naming • Hierarchical implementations • Two directory entries having Host_Name as RDN

37. 5.4. Attribute based naming • Hierarchical implementations • Two lookup operations in LDAP • read /C=NL/O=Vrije Universiteit/OU=Comp.Sc./CN=Main server • will return 1 record • list /C=NL/O=Vrije Universiteit/OU=Comp.Sc./CN=Main server • Will return star and zephyr • DIT (Directory Information Tree) is distributed across multiple servers (i.e. Directory service agents) • Complex queries are possible ( more flexible than DNS) • search(“&(C=NL)(O=Vrije Universiteit)(OU=*)(CN=Main server)”) • returns all main servers at Vrije Universiteit in NL • Hence, index servers are used to accelerate lookup oper’s

38. 5.4. Attribute based naming • Decentralized implementations • See book

39. Chapter 6:Synchronisation

40. Chapter 6: sychronisation • 6.1. Clock synchronisation • 6.2. Logical clocks • 6.3. Mutual exclusion • 6.4. Global positioning of nodes • 6.5. Election algoritms

41. 6.1. Clock synchronisation • When each machine has its own clock, an event that occurred after another event may nevertheless be assigned an earlier time.

42. 6.1. Clock synchronisation • Physical clocks (6.1.1) • Global positioning systems (6.1.2) • Clock Synchronisation algorithms (6.1.3) • WWV receivers to synchronize times • What if no WWV receiver on machine? • H = ticks per second by a timer in PC (normally H=60) • 216.000 ticks per hour • In practise: clocks are drifting • [215.998 ,216.002] ticks/hour

43. 6.1. Clock synchronisation • Network time protocol • A adjusts time to time of B with WWV receiver • Offset = T3 + [(T2-T1)+(T4-T3)]/2 – T4 • Delay = [(T4-T1)-(T3-T2)]/2 • In practise: • If clock was too fast, it slows down for a while • Clocks are not turned back!!!

44. 6.1. Clock synchronisation • Network time protocol • Remark 1: • Protocol will be run multiple times • leading to (offset_i, delay_i) • Offset is modified to the offset_i with minimal delay • Remark 2: • Machines with WWV receiver are stratum-1 machines • If A synchronizes clock with B, then stratum level of A becomes 1 higher than B (or vice versa)

45. 6.1. Clock synchronisation • The Berkeley Algoritm • Time daemon actively polls for times • Average is calculated and sent back • Works even if no machine known UTC time

46. 6.1. Clock synchronisation • Clock synchronisation in Wireless Networks • Reference broadcast protocol • Only receivers synchronize clocks • Two benefits: • Message preparation time of clock token is not relevant • Time of token spent in Network Interface is not relevant

47. 6.1. Clock synchronisation • Clock synchronisation in Wireless Networks • Reference broadcast protocol • Offset between two receivers of multiple tokens sent by sender is calculated as follows: Offset[p,q]=SUM(Tp,k-Tq,k)/M • p and q are receiving nodes • they exchange their times Tx,k

48. 6.2. Logical clocks • Logical clocks are used if real time is not relevant • Lamport’s Logical clocks • The "happens-before" relation → can be observed directly in two situations: • If a and b are events in the same process, and a occurs before b, then a → b is true. • If a is the event of a message being sent by one process, and b is the event of the message being received by another process, then a → b

49. 6.2. Logical clocks • Lamport’s Logical clocks • 3 processes with their own clocks at different rates (a) • Lamport’s algorithm corrects the clocks (b)

50. 6.2. Logical clocks • Lamport’s Logical clocks • How the clock algorithm works? • Before executing an event Pi executes Ci← Ci + 1. • When process Pi sends a message m to Pj, it sets m’s timestamp ts (m) equal to Ci after having executed the previous step. • Upon the receipt of a message m, process Pj adjusts its own local counter as Cj← max{Cj , ts (m)}, after which it then executes the first step and delivers the message to the application