Systems Programming Lec7 - CoreServices For DistributedSystems, Study notes of Computers and Information technologies

Download Systems Programming Lec7 - CoreServices For DistributedSystems and more Study notes Computers and Information technologies in PDF only on Docsity!

111

Systems Programming

Core Services for Distributed Systems

2

Core Services for Distributed Systems – Overview 1

Core / Generic services are low-level server processes which are invisible to users and are generally regarded as an integral part of a distributed IT infrastructure.

Providing such services achieves: ► (^) Transparency ► (^) Consistency ► (^) Resilience ► (^) Scalability ► (^) Security ► (^) Usability

These services themselves need to be robust, scalable etc, and are thus usually distributed or replicated across the nodes of a distributed system.

4

Core Services for Distributed Systems – Directory / Name Services 1

Possibly the most-basic challenge (on which all else depends) is automatically locating services / resources, despite a constantly changing system.

For example, consider a client/Server application, in which the user starts the client part locally. The client must contact the server to request some action. But - where is the server?

• how can the client find out?

Some ways that this can be done, but all have serious limitations: ► (^) Hardcoded address – only for prototyping ► (^) Configuration file – only for locally managed services ► (^) Ask user – only for prototyping ► (^) Broadcast request for service – only if server is local ► (^) Broadcast service advertising – only if server is local

A directory / name service maintains a database of provided name-to-address mappings via a well defined interface through which clients can request information in real time.

5

Core Services for Distributed Systems – Directory / Name Services 2

A directory service can vary in sophistication from a simple local “address book” to a global service overseeing a large distributed IT infrastructure spanning many countries.

At its simplest a directory / name service will map user-friendly names onto an address.

1 Client asks directory service for location of Server 2 Directory service responds with address if known 3,4 Client and Server communicate

General directory service concept

3

4

2

1

Application client

Application server

Directory service

7

Core Services for Distributed Systems – Domain Name System (DNS)

The most common directory service is the Domain Name Service (DNS) ► (^) Maps names to IP addresses, ► (^) An essential part of communication over the Internet.

DNS maps Application-level names (such as host names, email addresses, and URL fragments) to IP addresses: This is important because URLs are ‘human-friendly’ i.e. easy to remember and understand. However, IP addresses are the only way to actually direct a message to a specific location in The Internet.

DNS consists of: ► (^) A distributed database to hold naming information ► (^) A hierarchical domain-based naming scheme

A DNS service must be available to every Internet host, otherwise all IP addresses must be provided explicitly.

Core Services for Distributed Systems

- DNS – Name Space

DNS server for gre.ac.uk domain. Only resolves names for services below gre.ac.uk, such as staffmail.cms.gre.ac.uk

► (^) Name space is divided into domains. ► (^) Domains are organised hierarchically. ► (^) Each domain has local DNS server. ► (^) Each server only resolves names for its own domain:

• scalability,
• reconfigurability,
• performance. ► (^) Servers can be replicated:
• robustness,
• performance.

root

com gov org uk

ac

gre

ft

Hard disk

DN S

10

Core Services for Distributed Systems – Trading services (1)

Trading is the process of matching client requests for service with appropriate service offers accessible somewhere within a distributed system.

A Trading service matches client to service by service-provision rather than by server-name.

A Trading service takes the simple concepts of a directory service further, enabling a client to dynamically locate a server offering a particular service.

The trading service adds transparency in that the client application does not need to even know the name of the service it is connected to.

There are a number of issues which must be considered when designing such a service: ► (^) The application service may be replicated, ► (^) The application service may be partitioned (e.g. distributed databases in which not all servers have all data), ► (^) At the time of a request, the application service may be active or inactive.

11

Core Services for Distributed Systems – Trading services (2)

Application client

Application server

Trading service

1. Export
2. Import
3. Query
4. Application activity

Overview of communication steps

Trading service lookup table

Current address

192.84.56. 192.84.56. 193.93.67. 196.38.58.

Server name

Encryption Encryption Security Kerberos_AS

Service type

DES encryption Data compression RSA encryption DES encryption

13

Core Services for Distributed Systems – Time Services – Overview 2

Various applications use clocks (inc. time, timestamps or a notion of ordering) in different ways.

Depending on the accuracy needed, various different techniques can be used.

Physical clocks keep imperfect track of time These are important if the actual time at which events occur is significant to the outcome of the application (such as stock trading where the price is fixed at a specific time the deal is completed).

Logical clocks are monotonically increasing integer values These are used to indicate the relative time at which events occur. The ‘time’ values are a sequence of numbers and do not relate to ‘wall-clock’ time.

In synchronising the clocks it is usually more important to be able to order events than to synchronise with any real-world clock.

There are two principal event ordering mechanisms – timestamping using globally synchronised physical clocks and the use of logical clocks.

14

Core Services for Distributed Systems – Physical clock synchronisation

A Time Service must synchronise (within acceptable limits) the clock of a local computer with that of other computers in a network.

One approach is to designate some servers as “reference servers”; these servers provide an accurate, stable time source to clients on the network. In order to do this the reference servers must synchronise their host’s physical clocks to agree with some real-world clock.

Clients and non-reference servers adjust their clocks to agree with the time reported by a reference server.

The problems involved in this synchronisation process are as follows ► (^) Clocks can drift which can lead to differences between local clock times. ► (^) Network delays are unpredictable. ► (^) Client and server processing delays are unpredictable.

16

The Berkeley algorithm aims to synchronise all clocks in a group of computers – but does rely on an actual reference clock.

Assumes ‘errors’ cancel out to a certain extent. This approach is only useful where relative synchronisation (e.g. within a local pool of computers supporting a sequencing-critical service), but is not particularly useful if the service is absolute-time critical.

Operation: An election algorithm is necessary to choose a new master in the event of failure of the current master.

1. A computer is elected as a master time server (only if one does not already exist)
2. The master time server actively polls other computers.
3. It computes the average time (significant outlier values are ignored)
4. It sends a message telling other computers to set their clocks accordingly.

Physical clock synchronisation - The Berkeley Algorithm (1)

17

Core Services for Distributed Systems – Berkeley (2)

1 Master polls all hosts, “what is the time? 2 Send reply 3 Compute average time (ignore outliers e.g. 11:39) 4 Send “the time is 12:03”

Master Time server

1

1

1

1

(^2 )

(^22)

4

4

4

4

3

Time Service Process Host A

Time Service Process Host B

Time Service Process Host C

Time Service Process Host D

12:01 12:

12:

12:04 (^) 11:

The Network Time Protocol (NTP) is the most popular Internet time protocol, and also the one that provides the best performance.

The client process runs as a background task that periodically gets updates from one or more servers. The client ignores responses from servers that appear to be sending the wrong time (as with the Berkeley algorithm), and averages the results from those that appear to be correct.

Many NTP clients for personal computers don’t do averaging. These make a single timing request to a signal server and use this information to set their computer’s clock. This is termed as a SNTP (Simple Network Time Protocol).

NIST servers listen for NTP requests on port 123, and respond with UDU data packets in the NTP format (i.e. THE NTP PDU). The PDU includes a 64-bit timestamp containing the time in UTC seconds since January 1, 1900. 19

Internet Time Service protocols – Network Time Protocol (RFC-1305)

20

Internet Time Service protocols – Daytime Protocol (RFC-867) 1

The time is sent using standard ASCII characters. The time code format is:

JJJJJ YY-MM-DD HH:MM:SS TT L H msADV UTC(NIST) OTM

JJJJJ is the Modified Julian Date (MJD). Starting midnight on Nov 17, 1858. MJD is calculated by subtracting 2,400,000.5 days from the Julian Date. (Julian Date is no. days from noon on 1 January 4713 B.C. (Julian Day zero)).

YY-MM-DD is the date.

HH:MM:SS is the time. Time is sent as Coordinated Universal Time (UTC). An offset has to be applied to obtain local time.

TT is a two digit code (00 to 99) that indicates whether the US is on Standard Time (ST) or Daylight Saving Time (DST).

L is a one-digit code that indicates whether a leap second will be added or subtracted at midnight on the last day of the current month.