no need to write software for network-core devices
Network core doesn’t run user applications.
App architectures
Client-server architecture
Server:
Always-on host
Permanent IP address
Scalability: Must have data center (with thousands of servers)
Client:
Dynamic IP address (different access networks)
Communicate with server to get service
Possibly intermittent connection
P2P architecture
No always-on server
Arbitrary end systems directly communicate
Scalability: New peers bring service capacity (seeds), but also more service demands (leech)
Self-scalability
Peers are intermittedly connected and often change IP addresses (who?)
complex management
Process communication
Process: program running in host.
Server process: Process that waits to be contacted
Client process: Process that initiates the communication
(P2P architectures must have both in each peer!)
Inter-process communication (IPC) across different hosts by exchanging messages (data packets @ application layer)
Sockets
A local process sends/receive messages to/from its socket (the interface between application and the transport layers, i.e., between localhost and entire internet)
Note: Application layer (upper layer) utilizes the transport layer (below) for its transport service.
Analogy: the door between your localhost and “outdoors” outside of your localhost. It is an abstraction (like an API).
Addressing processes
Motivation:
To receive messages, process must have identifier
The IP address is not precise enough to idenitify individual processes in the hosts of this access network.
The identifier includes IP address and port numbers.
HTTP server: 80
Email: 25
Miscellaneous:
Port number advantage over PID
Consistent port numbers for well known services (HTTP, email) whereas PID is always varying
Socket $\neq$ Port: befoire u use a socket you need to bind it with a port number
Can 2 processes listen on the same port number? (in other words, multiple applications binding to a port)
In practice yes, but is quite complicated and implementation dependent (to ensure consistency etc).
Transport service requirements
Different services have different requirement dimensions:
data integrity
limited loss toleration
some 100% reliable data transfer
timing (delay/latency)
Low delay to be effective
Throughput
minimum amount to be effective (e.g. real time gaming)
others can make do with whatever amt they get
security
encryption, data integrity…
Transport layer services
Only 2 types of services provided by transport layer.
TCP
Reliable (whatever source sends, destination will receive)
Flow control
Congestion control
Nothing else except data integrity
Connection
UDP
Unreliable data transfer
Does not provide anything!
Cheaper (overhead, complexity etc. hence shorter delay)
Multimedia
App-layer protocol
Open protocols
defined in RFC (Request for Comment) open documents
Allow interoperability
If you don’t like browser A, you can write browser B because share same protocol
Main method of saving state (despite statelessness of HTTP).
Cookie header line of response message (from server to unique end system)
Cookie header line of end system’s next HTTP request
End system’s local storage of cookie file
Backend database of the website storing the cookies
set-cookie
cookie
Web-caches
Satisfy client request without involving origin server.
When client makes a request:
First goes through a proxy server
Checks if the content is cached there
If cached and updated: Return from cache
Else: Request object from origin server and returns the object to client
Advantages:
Usually faster as proxies are closer to end-systems.
Prevent overloading a server for a highly requested resource, by distributing service over many proxy servers.
Conditional GET
Client process $\rightarrow$ Server process: if-modified-since: <date>
Server process $\rightarrow$ Client process: If cached copy is not modified since, HTTP/1.0 304 Not modified otherwise contains most updated data.
No object transmission delay, less link utilization.
Domain name system (DNS)
Host identifiers: IP address (32 bit), name (human readable string). These two must be mapped to each other uniquely.
Distributed storage of this mapping
DNS
A network domain is an administrative grouping of multiple private computer networks or local hosts within the same infrastructure.
– Wikipedia (https://en.wikipedia.org/wiki/Network_domain)
Client searches for www.amazon.com.
Client queries root server for .com DNS server
Client queries .com DNS server for amazon.com DNS server.
Client queries amazon.com DNS server for www.amazon.com
Levels of DNS Servers
Root name servers (13 logical root name servers, what does logical mean here?)
Top-level domain servers (.com, .net, .edu, country TLDs)
Authoritative DNS server (the organization’s own DNS server)
Local DNS Server
Host makes DNS query
Query first sent to local DNS server
Search local cache of name-address pairs
Forwards query (as a proxy) into the
Does not belong to the hierarchy of distributed database that stores mapping permanently.
Root DNS Server
Iterated query
Local DNS server receives the next server to contact from the previous server, and calls them one by one until the authoritative DNS is found.
Recursive query
Local DNS server requests for the authoritative DNS from the root DNS server, where if it isn’t cached, requests from the TLD, which if it isn’t cached, it requests from the next level domain etc. and passes the information back to the local DNS server.
This is problematic:
Every request has to pass through the root server, which may overload the root server.
In the iterated structure, the responsibility of each layer is a lot clearer.
Caches
Satisfies client request without involving origin server.
Page cached: If not expired, return cache
Otherwise: Request cache from origin server and return to client.
Once (any) name server learns mapping, it caches mapping, but mappings expire after some Time To Live (TTL).
Cached entries might be out of date. (If a named host changes IP address, this won’t be universally known until all TTLs expire.)
