- If arrival rate (in bits) to link exceeds transmission rate of link for a period of time: - Packets will queue, wait to be transmitted on link. - Packets can be dropped (lost) if memory (buffer) fills up --- # Two key network-core functions </img> --- # Alternative core: circuit switching </img> --- # Internet protocol stack --- # Outline - Network architecture: - Client-server architecture - P2P architecture - Protocols: - TCP (Transmission Control Protocol) - UDP (User Datagram Protocol) - Socket programming: - TCP - UDP --- # Creating a network app </img> --- # Creating a network app ### Write programs that: - Run on (different) end systems - Communicate over network - E.g., web server software communicates with browser software --- # Creating a network app ### No need to write software for network-core devices - Network-core devices do not run user applications - Applications on end systems allow for rapid app development, propagation --- # Application architectures --- # Client-server architecture --- # Client-server architecture --- # P2P architecture --- # Processes communicating

Process: program running within a host

- Within same host, two processes communicate using inter-process communication (defined by OS) - Processes in different hosts communicate by exchanging messages --- # Processes communicating

Socket: a software mechanism that allows a process to create and send messages into, and receive messages from the network.

- A process is analogous to a house, and its socket is analogous to its door - Interface between application layer and transport layer. --- # Sockets - Process sends/receives messages to/from its socket - Socket analogous to door - Sending process shoves message out of the door - Sending process relies on transport infrastructure on other side of the door to deliver message to a socket at the receiving process --- # Sockets </img> --- # What transport service does an app need? ### Data integrity - Some apps (e.g., file transfer, web transactions) require 100% reliable data transfer - Other apps (e.g., audio) can tolerate some loss --- # What transport service does an app need? ### Security - Encryption, data integrity, ... --- # What transport service does an app need? ### Timing - Some apps (e.g., Internet telephony, interactive games) require low delay to be “effective --- # Internet transport protocols services ### TCP service: - Connection-oriented: setup required between client and server processes - Reliable transport between sending and receiving process - Flow control: sender won’t overwhelm receiver - Full-duplex connection: connection can send messages to each other at the same time --- # Internet transport protocols services ### UDP service: - Unreliable data transfer between sending and receiving processes - Does not provide: reliability, flow control, congestion control, timing, security, or connection setup --- # P2P architecture: example - P2P messenger - using TCP --- # P2P architecture: solution

import socket
import threading
import sys
from getopt import getopt

def receiver(address):
    with socket.socket() as s:
        s.bind(address)
        s.listen(1)
        while True:
            connection, (peer_ip, _) = s.accept()
            with connection:
                message = connection.recv(1024).decode()
                print("{}: {}".format(peer_ip, message))

def sender(address):
    while True:
        message = input(">> ")
        with socket.socket() as s:
            s.connect(address)
            s.sendall(message.encode())

def start():
    o = dict(getopt(sys.argv[1:], 'h:p:l:')[0])
    threading.Thread(target=receiver, args=(('', int(o.get('-l',8080))),)).start()
    threading.Thread(target=sender, args=((o.get('-h',''), int(o.get('-p',8080))),)).start()

if __name__ == "__main__":
    start()

--- # App-layer protocol defines - Types of messages exchanged - E.g. request, response - Message syntax - What fields in messages & how fields are delineated - Message semantics - Meaning of information in fields --- # App-layer protocol defines --- # HTTP Overview --- # HTTP overview (continued) - Uses TCP: - Client initiates TCP connection (creates socket) to server, port 80 - Server accepts TCP connection from client - HTTP messages (application-layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server) - TCP connection closed --- # HTTP overview (continued) - HTTP is “stateless” - Server maintains no information about past client requests
</br> --- # HTTP connections - Non-persistent HTTP - At most one object sent over TCP connection - Connection then closed - Downloading multiple objects required multiple connections - Persistent HTTP - Multiple objects can be sent over single TCP connection between client, server --- # Non-persistent HTTP Suppose a user enters an URL: www.someSchool.ac.uk/computer.science/ - HTTP client initiates TCP connection to HTTP server at someSchool.ac.uk on port 80 1. HTTP server at host is waiting for TCP connections on port 80 and accepts to the connection notifying the client 2. HTTP client sends HTTP request message (containing URL) into the TCP connection socket. The message indicates the client wants e.g. computer.science/index.html --- # Non-persistent HTTP (continued) 3. HTTP server receives request message, forms response message containing requested object, and sends message into its socket 4. HTTP server closes TCP connection as soon as the client received the response intact 5. HTTP client receives response message containing html file, displays html. Parsing html file, finds 10 referenced objects (e.g., JPEG) 6. Steps 1-4 are repeated for each of the 10 jpeg objects --- ## Non-persistent HTTP: Response time --- # Persistent HTTP: - Server leaves connection open after sending response - Subsequent HTTP messages between same client/server sent over open connection - Client sends requests as soon as it encounters a referenced object - Persistent HTTP response time = RTT + file transmission - Assuming connections to server already established - Assuming all files requested in parallel --- # HTTP Standards - HTTP/1.1 introduced 1997 - HTTP/2 currently in use - requires Transport Layer Security (TLS) 1.2 or newer - HTTP/3 proposed next standard - already in use by some browsers - uses UDP not TCP (see QUIC) - attempts to solve "head-of-line" blocking --- # Summary - Application architectures - Client-server - P2P - Application service requirements - Internet transport service model - Connection-oriented, reliable: TCP - Unreliable, datagrams: UDP - Application Layer Protocols - HTTP - persistent HTTP - non-persisten HTTP