CS 5565 Network Architecture and Protocols Lecture 5 Godmar Back

Announcements Problem Set 1 due Feb 18 Project 1A due Feb 19 CS 5565 Spring 2009 12/31/2018

Queuing Layer k+1 send queues recv queues Layer k Layer k-1 CS 5565 Spring 2009 12/31/2018

Demultiplexing End systems must decide which layer instances should process an incoming packet Layer k has “type information” in header to say which instance of layer k+1 to pick Issues: speed and flexibility Ethernet Frame as received Ethernet Type …….0800 ->IP IP Protocol ……06 ->TCP.…. TCP Port ……50 ->http.…. Http Request ……GET /~gback.…. Ethernet Header IP Header TCP Header HTTP Request CS 5565 Spring 2009 12/31/2018

Demultiplexing Issues (1) How does a layer k determine which layer k+1 should get a packet? Generally done using dispatch/function pointer table indexed by known/registered protocols Works well layer to layer But… can’t see if a packet will be accepted by (or is useful to) higher layers CS 5565 Spring 2009 12/31/2018

Demultiplexing Issues (2) Receiver Livelock: Spending entire CPU cycles doing low-level processing on packets that eventually need to be discarded. Goal: Early Packet Discard (On interrupt): don’t waste time on packets that you need to discard anyway Because no one’s listening Or: because listener doesn’t keep up (application slow, buffers full, etc.) Combined with Lazy Receiver Processing (LRP) After initial acceptance, postpone further processing to accounted context See http://www.cs.rice.edu/CS/Systems/LRP/ for details CS 5565 Spring 2009 12/31/2018

Demultiplexing Issues (3) How do you achieve early packet discard? Often: optimize common case, support a few well-known protocols Better/more general solution: Allow higher layers to register demultiplexing predicates, e.g. (eth.type == IP && ip.prot == TCP && tcp.port == http && http.req matches ‘/~gback/’) Ideally composable Must be safe BPF: Berkeley Packet Filter – interpreted language to decide if a packet matches or not CS 5565 Spring 2009 12/31/2018

Fast Demux: DPF [Engler’96] Uses dynamic code generation to install demux filters CS 5565 Spring 2009 12/31/2018

Scout OS Developed at U Arizona by Larry Peterson Idea: center entire OS around “network paths” “communication OS” data-driven scheduling Path 1 Path2 CS 5565 Spring 2009 12/31/2018

Arguments against Layering Design Some functions don’t fit in a layer network management Possibility of making (and having to live with) bad design decisions Possibility of duplication Performance Possible performance penalties from crossing layers: memory-to-memory copies Mistuning: (Old) layer implementation at k+1 may be suboptimal when (new) layer k is improved CS 5565 Spring 2009 12/31/2018

Layering not always strict Example: FDDI Station Management CS 5565 Spring 2009 12/31/2018

End-To-End Argument If you were to design a network from scratch, how would you decide which functionality goes in which layer? E2E Argument [Saltzer/Reed/Clark ’84] says: Functionality whose complete & correct implementation requires knowledge that only end points have should be implemented at the end points. Corollary: only put in layer ‘k’ that which benefits all instances of layer ‘k+1’ Example: file transfer Where should you put error recovery? NB: be careful to define end points Human phone conversation vs. speech message system Guiding principle, not hard rule CS 5565 Spring 2009 12/31/2018

Architecture vs. Engineering Clark & Tennenhouse [SIGCOMM 1990] Architectural Considerations for a New Generation of Protocols Layering but one design/engineering principle: not always best Argue for “flexible decomposition” Suggest two alternate ideas Application-level Framing (ALF) Integrated Layer Processing (ILP) CS 5565 Spring 2009 12/31/2018

The Application Layer

Application Layer Let’s look at some applications (in keeping with top-down) Application architectures: Client/Server, P2P, Hybrid Client/Server Architecture vs Client Process/Server Process Transport Layer Requirements CS 5565 Spring 2009 12/31/2018

Creating a network app Write programs that run on different end systems and communicate over a network. No software typically written for devices in network core Network core devices do not function at app layer This design allows for rapid app development Exception: extensible routers Research: active networks application transport network data link physical CS 5565 Spring 2009 12/31/2018

Client-Server Architecture always-on host permanent IP address server farms for scaling clients: communicate with server may be intermittently connected may have dynamic IP addresses do not communicate directly with each other CS 5565 Spring 2009 12/31/2018

Pure P2P Architecture no always on server arbitrary end systems directly communicate peers are intermittently connected and change IP addresses example: Gnutella Highly scalable But difficult to manage CS 5565 Spring 2009 12/31/2018

Hybrid of client-server and P2P (Original) BitTorrent File transfer P2P; Tracker centralized Instant messaging Presence detection/location centralized: User registers its IP address with central server when it comes online User contacts central server to find IP addresses of buddies Chatting between two users can be P2P File transfer between users typically P2P CS 5565 Spring 2009 12/31/2018

App-layer Protocols Public-domain protocols: defined in RFCs Defines: Types of messages exchanged, e.g., request & response messages Syntax of message types: what fields in messages & how fields are delineated Semantics of the fields, ie, meaning of information in fields Rules for when and how processes send & respond to messages Public-domain protocols: defined in RFCs allows for interoperability e.g., HTTP, SMTP Proprietary protocols: e.g., Skype CS 5565 Spring 2009 12/31/2018

Transport Service Requirements Application file transfer e-mail web documents real-time audio/video stored audio/video interactive games instant messaging Data loss no loss loss-tolerant Bandwidth elastic audio: 5kbps-1Mbps video:10kbps-5Mbps same as above few kbps up Time Sensitive no no (?) yes, 100’s msec yes, few secs yes and no CS 5565 Spring 2009 12/31/2018

Internet apps: application, transport protocols layer protocol SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] proprietary (e.g. RealNetworks) (e.g., Skype) Underlying transport protocol TCP TCP or UDP typically UDP Application e-mail remote terminal access Web file transfer streaming multimedia Internet telephony CS 5565 Spring 2009 12/31/2018

Communicating Processes Client process: process that initiates communication Server process: process that waits to be contacted Process: program running within a host. Access services through sockets Note 1: client/server process is really a property of socket state Note 2: process can be both server & client process for different communications when multiple sockets are used CS 5565 Spring 2009 12/31/2018

Addressing Processes For a process to receive messages, it must have an identifier A host has a unique 32-bit IP address Not sufficient because multiple processes can be on same host Add 16-bit port number Identifier includes both the IP address and port number associated with the process on the host. Example port numbers: HTTP server: 80 Mail server: 25 “Well-known” port numbers /etc/services CS 5565 Spring 2009 12/31/2018

UDP & Socket Programming

UDP Service provided Passes segments straight to IP source port # dest port # 32 bits Application data (message) UDP segment format length checksum Length, in bytes of UDP segment, including header Service provided Demultiplexing Payload checksum Passes segments straight to IP No congestion control So simple it fits on one slide CS 5565 Spring 2009 12/31/2018

Socket Programming Socket API Goal: learn how to build client/server application that communicate using sockets a host-local, application-created, OS-controlled interface (a “door”) into which application process can both send and receive messages to/from another application process socket Socket API introduced in BSD 4.1 UNIX, 1981 explicitly created, used, released by apps used for both local and remote communication CS 5565 Spring 2009 12/31/2018

Network Socket Programming Socket: (narrow definition:) a door between application process and end-end-transport protocol (UDP or TCP) process Stack w/ buffers, variables socket controlled by application developer operating system host or server internet CS 5565 Spring 2009 12/31/2018

Addressing For UDP/IP or TCP/IP socket communication, generally need 4 parameters: Source Identifier (32-bit IP Address) Source Port (16-bit) Destination Identifier (32-bit IP Address) Destination Port (16-bit) Notice that the relationship of “local” and “remote” (also called “peer”) to source/destination depends on direction of communication Note: UDP uses only Destination (IP+Port) for demultiplexing TCP uses Source + Destination (quadruple: Src IP, Src Port, Dst IP, Dest Port) CS 5565 Spring 2009 12/31/2018

BSD Socket API API – Application Programming Interface Provides access to services Specified in C language Implemented on many platforms in one way or the other (Windows: WinSock2, CSocket MFC classes for BSD-like look) Sockets (in Unix) are file descriptors General idea: writing to the socket is sending data to network, reading from socket is receiving data Good because read(2), write(2), close(2) and others (select(2), poll(2), ioctl(2), SIGIO, fcntl(2)) can be reused Bad because ? Study C API first and observe how other languages embedded sockets CS 5565 Spring 2009 12/31/2018

UDP Sockets: Overview Client Server socket() socket() connect() (optional) bind() send() acts like sendto() recvfrom() recv() acts like recvfrom() sendto() Client Server CS 5565 Spring 2009 12/31/2018

int socket(int domain, int type, int protocol) domain: PF_INET, PF_UNIX, PF_INET6, …. type: SOCK_DGRAM, SOCK_STREAM, … protocol: 0 for Unspecified (or IPPROTO_UDP) returns integer file descriptor entirely between process and OS – no network actions involved whatsoever man pages: ip(7), udp(7), tcp(7), socket(2), socket (7), unix(7) type “man 2 socket”, “man 7 socket” CS 5565 Spring 2009 12/31/2018

int bind(int sockfd, struct sockaddr *my_addr, socklen_t addrlen) sockfd: return by socket() my_addr: “socket address” addrlen length of address (address is variable-sized data structure) “binds” socket to (local) address specified This affects network protocol namespace, but no information is transmitted over network Typically: one socket per port, exception: multicast CS 5565 Spring 2009 12/31/2018

How are addresses represented? struct sockaddr { /* GENERIC TYPE, should be “abstract” */ sa_family_t sa_family; /* address family */ char sa_data[14]; /* address data */ }; /* This is the concrete “subtype” you’ll use */ struct sockaddr_in { sa_family_t sin_family; /* address family: AF_INET */ u_int16_t sin_port; /* port in network byte order */ struct in_addr sin_addr; /* internet address */ /* Internet address. */ struct in_addr { u_int32_t s_addr; /* address in network byte order */ CS 5565 Spring 2009 12/31/2018

More on bind(2) Address specified is the “local” address Which is destination for receive and source for sends. sin_addr.s_addr useful for “multi-homed” hosts, otherwise use INADDR_ANY sin_port may be zero if any port would do Use getsockname() to retrieve assigned port s_addr and sin_port are specified in network byte order This convention holds throughout socket API CS 5565 Spring 2009 12/31/2018

Common Pitfalls (1) Network vs. Host Byte order Network order is big endian, most-significant byte first Host order may be either big or little: little endian on x86 Use ntohs(), ntohl(), htons(), htonl() to convert 16-bit (“short”) and 32-bit (“long”) values portably Never convert addresses/ports in sockaddr_in structures in place Not as much an issue in languages that hide data representation (e.g., Java) CS 5565 Spring 2009 12/31/2018

int getsockname(int s, struct sockaddr *name, socklen_t *namelen); Common Pitfalls (2) Pay attention to “length” parameters Example namelen here is not OUT, its INOUT aka value-result You know what socket it is, the OS doesn’t! Always check return codes! int getsockname(int s, struct sockaddr *name, socklen_t *namelen); CS 5565 Spring 2009 12/31/2018

sendto(2), recvfrom(2) s, buf, len as in read/write ssize_t sendto(int s, const void *buf, size_t len, int flags, const struct sockaddr *to, socklen_t tolen); ssize_t recvfrom(int s, void *buf, size_t len, int flags, struct sockaddr *from, socklen_t *fromlen); s, buf, len as in read/write flags: MSG_OOB, MSG_PEEK – mostly 0 to/from are of type struct sockaddr_in These are remote/peer addresses: where did the packet come from, where should it be sent to NB: fromlen is value-result! CS 5565 Spring 2009 12/31/2018

Then what does connect() do??? UDP & connect(2) Then what does connect() do??? No notion of connections in UDP connect(2) can be used to tell OS “default destination” for future sends Then can use send(2) and write(2) instead of sendto(2), or can omit the destination address in sendto(2) What does “ECONNREFUSED” mean for UDP? Courtesy extended by other nodes which send ICMP packet saying “no one’s listening for UDP packets at the port number you sent it to” OS relayed this information to UDP application CS 5565 Spring 2009 12/31/2018

UDP Demultiplexing Payload Payload Payload S: 10.0.0.2:3045 D: 10.0.0.1:80 Payload 10.0.0.1 10.0.0.2 S: 10.0.0.2:??? sendto(10.0.0.1:80) socket() bind(*, 80) S: 10.0.0.1:80 socket() S: 10.0.0.2:3045 recvfrom(&from) from:10.0.0.2:3045 recvfrom(&from) from:10.0.0.3:512 S: 10.0.0.3:512 D: 10.0.0.1:80 Payload recvfrom(&from) from:10.0.0.3:512 S: 10.0.0.1:53 bind(*, 53) 10.0.0.3 S: 10.0.0.3:512 bind(10.0.0.3,512) S: 10.0.0.3:512 D: 10.0.0.1:53 Payload CS 5565 Spring 2009 12/31/2018