CSE 124 January 27, Winter 2017, UCSD Prof. George Porter

Transcription

1 CSE 124 January 27, 2017 Winter 2017, UCSD Prof. George Porter

2 Announcements Today s plan: Finish up DNS/naming Bit more detail on threading and synchronization Open discussion about Project 1

3 Part 1: Domain Name System (DNS)

4 Overview : single hosts.txt file stored and distributed from a single site: Stanford University Contained all hostname to IP address mappings Centralized control did not fit with distributed management Number of hosts changed from number of timesharing systems to number of workstations Organizations to users Exponential resource usage for distributing the file made the problem worse

5 Domain Name System 1982: proposal for decentralized directory DNS Hierarchical namespace with typed data Control delegated in hierarchical fashion Convince node above you to delegate control Designed to be extensible w/support for new data types 1985: some hosts solely utilize DNS

6 Hierarchical Design root org mil edu com uk ca gwu ncsu ucsd unc mit ece cs blink hobo www ctrl

7 Domain Name System (DNS) Translate human understandable names to machine understandable names E.g., Hierarchical structure Every DNS server knows where the root is The root can tell you how to get to.edu.edu server can tell you how to find ucsd.edu ucsd.edu tells you about cs.ucsd.edu cs.ucsd.edu translates Caching along the way to improve performance

8 Root name servers

9 Query Processing Query local name server Authoritative/cached answers Support both recursive and iterative queries If not cached locally, locate server lowest in the hierarchy with entry in local DB In the worst case, contact root (.) Cache locally with TTL

10 Zones and Caching Mechanisms for data distribution Zones Provide local autonomy Any contiguous set of nodes in the tree Can be grown to arbitrary size Each domain should provide redundant servers Caching Time to live (TTL) associated with each name low value => higher consistency high value => better performance (less traffic)

11 DNS Lookup Example edu DNS server client local DNS proxy ucsd DNS server cs DNS server

12 Mapping names to addresses

13 Linked list of addrinfo structs Q: Why a linked list? Q: Which of the multiple results should you use?

14 Hints Can provide hints as to what you re looking for: Server socket (hints.ai_flags = AI_PASSIVE) Returned sockaddr_in suitable for server-side bind() Client socket (otherwise) IPv4 vs. IPv6 TCP vs. UDP

15 Part 2: Concurrency and synchronization

16 Concurrency vs. Parallelism Both deal with doing a lot at once, but aren t the same thing Given set of tasks {T 1,T 2,,T n } Concurrency: Progress of multiple elements of the set overlap in time Parallelism: Progress on elements of the set occur at the same time

17 Concurrency Might be parallel, might not be parallel A single thread of execution can time slice a set of tasks to make partial progress over time Time 0: Work on first 25% of Task 0 Time 1: Work on first 25% of Task 1 Time 2: Work on first 25% of Task 2 Time 3: Work on first 25% of Task 3 Time 4: Work on second 25% of Task 0 Time 5: Work on second 25% of Task 1

18 Parallelism Multiple execution units enable progress to be made simultaneously Processor 1 Time 0: 1 st 25% of Task1 Time 1: 2 nd 25% of Task1 Time 2: 3 rd 25% of Task1 Time 3: 4 th 25% of Task1 Time 4: 1 st 25% of Task3 Processor 2 Time 0: 1 st 25% of Task2 Time 1: 2 nd 25% of Task2 Time 2: 3 rd 25% of Task2 Time 3: 4 th 25% of Task2 Time 4: 1 st 25% of Task4

19 Flash traffic USGS Pasadena, CA office Earthquake site Oct 16, 1999 earthquake

20 Threading and performance Too much parallelism causes thrashing, excessive switching, lower performance

21 Constrained fork-based multiplexing Pre-spawn a set of N processes, all sharing a server socket Each process calls accept() on the server socket Then handles that client accept() called from different threads/processes returns a client socket to only one of the callers

22 Thread pool demo