CSE 124January 27, 2017

Winter 2017, UCSD

Prof. George Porter

Announcements

• Today’s plan:

– Finish up DNS/naming

– Bit more detail on threading and synchronization

– Open discussion about Project 1

Part 1: Domain Name System (DNS)

Overview

• www.cs.ucsd.edu 132.239.8.67

• 1974: 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

– Email made the problem worse

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

Hierarchical Design

root

edumilorg ukcom ca

gwu ncsu ucsd unc mit

hobo www ctrl

ece cs blink

Domain Name System (DNS)

• Translate human understandable names to machine understandable names

– E.g., www.cs.ucsd.edu132.239.8.67

– 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 www.cs.ucsd.edu132.239.8.67

– Caching along the way to improve performance

Root name servers

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

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)

DNS Lookup Example

client local

DNS proxy

edu

DNS server

ucsd

DNS server

cs DNS

server

www.cs.ucsd.edu

Mapping names to addresses

Linked list of ‘addrinfo’ structs

• Q: Why a linked list?

• Q: Which of the multiple results should you use?

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

Part 2: Concurrency and synchronization

Concurrency vs. Parallelism

• Both deal with doing a lot at once, but aren’t the same thing– Given set of tasks {T1,T2,…,Tn}

• Concurrency:– Progress of multiple elements of the set overlap in

time

• Parallelism:– Progress on elements of the set occur at the same

time

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– …

Parallelism

• Multiple execution units enable progress to be made simultaneously

Processor 1

• Time 0: 1st 25% of Task1

• Time 1: 2nd 25% of Task1

• Time 2: 3rd 25% of Task1

• Time 3: 4th 25% of Task1

• Time 4: 1st 25% of Task3

Processor 2

• Time 0: 1st 25% of Task2

• Time 1: 2nd 25% of Task2

• Time 2: 3rd 25% of Task2

• Time 3: 4th 25% of Task2

• Time 4: 1st 25% of Task4

Flash traffic

• USGS Pasadena, CA office Earthquake site

• Oct 16, 1999 earthquake

Threading and performance

• Too much parallelism causes thrashing, excessive switching, lower performance

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

Thread pool demo