400 likes | 415 Views
This lecture discusses the demultiplexing process in network architecture and the advantages and disadvantages of layering. It also explores the concept of client-server architecture and pure peer-to-peer (P2P) architecture for network applications.
E N D
CS 5565Network Architecture and Protocols Godmar Back Lecture 5
Announcements • Problem Set 1 due Feb 18 • Project 1A due Feb 19 CS 5565 Spring 2009
Queuing Layer k+1 send queues recv queues Layer k Layer k-1 CS 5565 Spring 2009
Ethernet Type…….0800 ->IP IP Protocol……06 ->TCP.…. TCP Port……50 ->http.…. Http Request……GET /~gback.…. 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 Header IP Header TCP Header HTTP Request CS 5565 Spring 2009
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
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
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
Fast Demux: DPF [Engler’96] Uses dynamic code generation to install demux filters CS 5565 Spring 2009
Path 1 Path2 Scout OS • Developed at U Arizona by Larry Peterson • Idea: center entire OS around “network paths” • “communication OS” • data-driven scheduling CS 5565 Spring 2009
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
Layering not always strict • Example:FDDIStationManagement CS 5565 Spring 2009
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
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
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
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 application transport network data link physical application transport network data link physical Creating a network app CS 5565 Spring 2009
Client-Server Architecture server: • 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
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
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
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 App-layer Protocols CS 5565 Spring 2009
Transport Service Requirements Time Sensitive no no no (?) yes, 100’s msec yes, few secs yes, 100’s msec yes and no Application file transfer e-mail web documents real-time audio/video stored audio/video interactive games instant messaging Bandwidth elastic elastic elastic audio: 5kbps-1Mbps video:10kbps-5Mbps same as above few kbps up elastic Data loss no loss no loss no loss loss-tolerant loss-tolerant loss-tolerant no loss CS 5565 Spring 2009
Internet apps: application, transport protocols Application layer protocol SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] proprietary (e.g. RealNetworks) proprietary (e.g., Skype) Underlying transport protocol TCP TCP TCP TCP TCP or UDP typically UDP Application e-mail remote terminal access Web file transfer streaming multimedia Internet telephony CS 5565 Spring 2009
Process: program running within a host. Access services through sockets Client process: process that initiates communication Server process: process that waits to be contacted Communicating Processes • 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
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 andport number associated with the process on the host. Example port numbers: HTTP server: 80 Mail server: 25 “Well-known” port numbers /etc/services Addressing Processes CS 5565 Spring 2009
32 bits source port # dest port # Length, in bytes of UDP segment, including header checksum length Application data (message) UDP segment format UDP • Service provided • Demultiplexing • Payload checksum • Passes segments straight to IP • No congestion control • So simple it fits on one slide CS 5565 Spring 2009
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 Programming Goal: learn how to build client/server application that communicate using sockets 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
controlled by application developer controlled by application developer process process controlled by operating system controlled by operating system Stack w/ buffers, variables Stack w/ buffers, variables internet host or server host or server socket socket Network Socket Programming Socket: (narrow definition:) a door between application process and end-end-transport protocol (UDP or TCP) CS 5565 Spring 2009
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
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
UDP Sockets: Overview Client Server socket() socket() connect()(optional) bind() send() acts like sendto() recvfrom() recv() acts like recvfrom() sendto() CS 5565 Spring 2009
socket(2) 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
bind(2) 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
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
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
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
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
sendto(2), recvfrom(2) 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
Then what does connect() do??? UDP & connect(2) • 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
S: 10.0.0.2:3045D: 10.0.0.1:80 sendto(10.0.0.1:80) Payload socket() bind(*, 80) socket() S: 10.0.0.1:80 S: 10.0.0.2:3045 S: 10.0.0.2:??? recvfrom(&from)from:10.0.0.2:3045 S: 10.0.0.3:512D: 10.0.0.1:80 Payload recvfrom(&from)from:10.0.0.3:512 S: 10.0.0.1:53 S: 10.0.0.3:512 recvfrom(&from)from:10.0.0.3:512 bind(*, 53) S: 10.0.0.3:512D: 10.0.0.1:53 Payload bind(10.0.0.3,512) UDP Demultiplexing 10.0.0.1 10.0.0.2 10.0.0.3 CS 5565 Spring 2009