1 / 40

CS 5565 Network Architecture and Protocols

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.

irmab
Télécharger la présentation

CS 5565 Network Architecture and Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS 5565Network Architecture and Protocols Godmar Back Lecture 5

  2. Announcements • Problem Set 1 due Feb 18 • Project 1A due Feb 19 CS 5565 Spring 2009

  3. Queuing Layer k+1 send queues recv queues Layer k Layer k-1 CS 5565 Spring 2009

  4. 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

  5. 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

  6. 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

  7. 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

  8. Fast Demux: DPF [Engler’96] Uses dynamic code generation to install demux filters CS 5565 Spring 2009

  9. 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

  10. 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

  11. Layering not always strict • Example:FDDIStationManagement CS 5565 Spring 2009

  12. 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

  13. 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

  14. The Application Layer

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

  24. 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

  25. UDP & Socket Programming

  26. 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

  27. 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

  28. 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

  29. 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

  30. 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

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

  32. 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

  33. 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

  34. 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

  35. 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

  36. 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

  37. 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

  38. 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

  39. 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

  40. 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

More Related