1 / 264

CS716 Advanced Computer Networks By Dr. Amir Qayyum

CS716 Advanced Computer Networks By Dr. Amir Qayyum. 1. Lecture No. 25. Review Lecture. Switched Networks. A network can be defined recursively as. Two or more nodes connected by a link Circular nodes (switches) implement the network Squared nodes (hosts) use the network.

talli
Télécharger la présentation

CS716 Advanced Computer Networks By Dr. Amir Qayyum

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. CS716 Advanced Computer Networks By Dr. Amir Qayyum 1

  2. Lecture No. 25

  3. Review Lecture

  4. Switched Networks • A network can be defined recursively as... • Two or more nodes connected by a link • Circular nodes (switches) implement the network • Squared nodes (hosts) use the network

  5. Switched Networks • A network can be defined recursively as... • Two or more networks connected by one or more nodes: internetworks • Circular nodes (router or gateway) interconnects the networks • A cloud denotes “any type of independent network”

  6. Switching Strategies • Packet switching: • Store-and-forward messages • operates on discrete blocks of data • utilizes resources dynamically according to traffic demand • send/receive messages at variable rate • example: Internet • Circuit switching: Carry bit streams • establishes a dedicated circuit • links reserved for use by communication channel • send/receive bit stream at constant rate • example: original telephone network

  7. L1 R1 Multiple flows on a single link L2 R2 Switch 1 Switch 2 L3 R3 Multiplexing • Physical links/switches must be shared among users • (Synchronous) Time-Division Multiplexing (TDM) • Frequency-Division Multiplexing (FDM) Do you see any problem with TDM / FDM ?

  8. Statistical Multiplexing • On-demand time-division, possibly synchronous (ATM) • Schedule link on a per-packet basis • Buffer packets in switches that are contending for the link • Packets from different sources interleaved on link … Do you see any problem ?

  9. Host Host Application Host Channel Application Host Host Inter-Process Communication • Turn host-to-host connectivity into process-to-process communication, making the communication meaningful. • Fill gap between what applications expect and what the underlying technology provides. Abstraction for application-level communication

  10. Abstract Channel Functionality • What functionality does a channel provide ? • Smallest set of abstract channel types adequate for largest number of applications • Where the functionality is implemented ? • Network as a simple bit-pipe with all high-level communication semantics at the hosts • More intelligent switches allowing hosts to be “dumb” devices (telephone network)

  11. Performance Metrics • … and to do so while delivering “good” performance • Bandwidth (throughput) • Data transmitted per unit time, e.g. 10 Mbps • Link bandwidth versus end-to-end bandwidth • Notation • KB = 210 bytes • Kbps = 103 bits per second

  12. Performance Metrics • Latency / Delay • Time to send message from point A to point B • One-way versus Round-Trip Time (RTT) • Components Latency = Propagation + Transmit + Queue Propagation = Distance / c Transmit = Size / Bandwidth • Note: • No queuing delay in direct (point-to-point) link • Bandwidth irrelevant if size = 1 bit • Process-to-process latency includes software processing overhead (dominates over shorter distances)

  13. Delay x Bandwidth Product • Amount of data “in flight” or “in the pipe” • Example: 100ms RTT x 45Mbps BW = 560KB • This much data must be buffered before the sender responds to slowdown the request Delay Bandwidth

  14. Network Architecture • The challenge is to fill the gap between hardware capabilities and application expectations, and to do so while delivering “good” performance • Designers cope with this complex task by developing a network architecture as a guideline • Layering, protocols, standards

  15. Layering • Alternative abstractions at each layer • Manageable network components • Modify layers independently Application programs Request/reply Message stream channel channel Host-to-host connectivity Hardware

  16. Protocols • Building blocks of a network architecture • Each protocol object has two different interfaces • service interface: operations on this protocol • peer-to-peer interface: messages exchanged with peer • Term “protocol” is overloaded • Specification of peer-to-peer interface • Module that implements this interface • Peer modules are interoperable if both accurately follow the specifications

  17. Protocol Interfaces Host1 Host2 Service High-level High-level interface object object Protocol Protocol Peer-to-peer interface

  18. Protocol Graph – Network Architecture • Collection of protocols and their dependencies • Most peer-to-peer communication is indirect • Peer-to-Peer is direct only at hardware level Host 2 Host 1 Digital Digital Video Video File File library library application application application application RRP: Request Reply Protocol MSP: Message Stream Protocol HHP: Host-to-Host Protocol application application RRP MSP RRP MSP HHP HHP

  19. Protocol Machinery • Multiplexing and Demultiplexing (demux key) • Encapsulation (header/body) in peer-to-peer interfaces • Indirect communication (except at hardware level) • Each protocol adds a header • Part of header includes demultiplexing field (e.g., pass up to request/reply or to message stream?)

  20. Data RRP RRP Data Data RRP Data HHP Encapsulation Host 1 Host 2 Application Application program program Data RRP RRP HHP HHP

  21. Standard Architectures • Open System Interconnect (OSI) Architecture • International Standards Organization (ISO) • International Telecommunications Union (ITU), formerly CCITT • “X dot” series: X.25, X.400, X.500 • Primarily a reference model

  22. OSI Architecture End host End host Application Application Data formatting Connection management Process-to-process communication channel Host-to-host packet delivery Framing of data bits Transmission of raw bits Application Presentation Presentation User level Session Session Transport Transport OS kernel Network Network Network Network Data link Data link Data link Data link Physical Physical Physical Physical One or more nodes within the network

  23. Internet Architecture • TCP/IP Architecture • Developed with ARPANET and NSFNET • Internet Engineering Task Force (IETF) • Culture: implement, then standardize • OSI culture: standardize, then implement • Became popular with release of Berkeley Software Distribution (BSD) Unix; i.e. free software • Standard suggestions traditionally debated publically through “Request For Comments” (RFC’s)

  24. Internet Architecture • Implementation and design done together • Hourglass Design (bottleneck is IP) • Application vs Application Protocol (FTP, HTTP) FTP HTTP NV TFTP UDP TCP IP … NET NET NET 2 1 n

  25. Internet Architecture • Layering is not very strict Application UDP TCP IP Network

  26. Networking in the Internet Age

  27. Network Application Programming Interface (API) • Interface that the OS provides to its networking subsystem • Most network protocols are implemented in software • All systems implement network protocols as part of the OS • Each OS is free to define its own network API • Applications can be ported from one OS to another if APIs are similar • *IF* application program does not interact with other parts of the OS other than the network (file system, fork processes, display …)

  28. Protocols and API • Protocols provide a certain set of services • API provides a syntax by which those services can be invoked • Implementation is responsible for mapping API syntax onto protocol services

  29. Socket API • Use sockets as “abstract endpoints” of communication • Issues • Creating & identifying sockets • Sending & receiving data • Mechanisms • UNIX system calls and library routines socket process

  30. Protocol-to-Protocol Interface • A protocol interacts with a lower level protocol like an application interacts with underlying network • Why not using available network APIs for PPI ? • Inefficiencies built into the socket interface • Application programmer tolerate them to simplify their task • inefficiency at one level • Protocol implementers do not tolerate them • inefficiencies at several layers of protocols

  31. Protocol-to-Protocol Interface Issues • Configure Multiple Layers • Static vs Extensible • Process Model • Avoid context switches • Buffer Model • Avoid data copies

  32. Process Model procedure call inter-process communication (a) (b) Process-per-Protocol Process-per-Message

  33. Buffer Model Application Process Buffer Copy Buffer Copy send() deliver() Topmost Protocol

  34. Network Programming • Things to Learn • Internet protocols (IP, TCP, UDP, …) • Sockets API (Application Programming Interface) • Why IP and Sockets • Allows a common name space across most of Internet • IP (Internet Protocol) is standard • Reduces number of translations, which incur overhead • Sockets: reasonably simple and elegant Unix interface (most servers run Unix)

  35. Socket Programming • Reading: Stevens 2nd edition, Chapter 1-6 • Sockets API: A transport layer service interface • Introduced in 1981 by BSD 4.1 • Implemented as library and/or system calls • Similar interfaces to TCP and UDP • Can also serve as interface to IP (for super-user) known as “raw sockets” • Linux also provides interface to MAC layer (for super-user) known as “data-link sockets”

  36. Client-Server Model • Asymmetric relationship • Server/Daemon • Well-known name • Waits for contact • Process requests, sends replies • Client • Initiates contact • Waits for response Server Client Client Client

  37. Client-Server Model • Bidirectional communication channel • Service models • Sequential: server processes only one client’s requests at a time • Concurrent: server processes multiple clients’ requests simultaneously • Hybrid: server maintains multiple connections, but processes requests sequentially • Server and client categories not disjoint • Server can be client of another server • Server as client of its own client (peer-to-peer architecture)

  38. SYN J SYN K ACK J+1 ACK K+1 TCP Connections • TCP connection setup via 3-way handshake • J and K are sequence numbers for messages Client Server Hmmm … RTT is important!

  39. FIN J ACK J+1 FIN K ACK K+1 TCP Connections • TCP connection teardown (4 steps) (either client or server can initiate connection teardown) active close passive close closes connection Server Client Hmmm … Latency matters!

  40. UDP - Aspects of Services • Unit of transfer is a datagram (variable length packet) • Unreliable, drops packets silently • No ordering guarantees • No flow control • 16-bit port space (distinct from TCP ports) allows multiple recipients on a single host

  41. Addresses and Data • Internet domain names: human readable • Mnemonic • Variable Length • e.g. www.case.edu.pk, www.carepvtltd.com (FQDN) • IP addresses: easily handled by routers/computers • Fixed Length • Tied (loosely) to geography • e.g. 131.126.143.82 or 212.0.0.1

  42. Endianness • Machines on Internet have different endianness • Little-endian (Intel, DEC): least significant byte of word stored in lowest memory address • Big-endian (Sun, SGI, HP): most significant byte...

  43. Socket Address Structures • Socket address structures (all fields in network byte order except sin_family) IP address struct in_addr { in_addr_t s_addr; /* 32-bit IP address */ }; TCP or UDP address struct sockaddr_in { short sin_family; /* e.g., AF_INET */ ushort sin_port; /* TCP / UDP port */ struct in_addr; /* IP address */ };

  44. Address Conversion • All binary values used and returned by these functions are network byte ordered struct hostent* gethostbyname (const char* hostname); translates English host name to IP address (uses DNS) struct hostent* gethostbyaddr (const char* addr, size_t len, int family); translates IP address to English host name (not secure) int gethostname (char* name, size_t namelen); reads host’s name (use with gethostbyname to find local IP)

  45. Address Conversion in_addr_t inet_addr (const char* strptr); translate dotted-decimal notation to IP address; returns -1 on failure, thus cannot handle broadcast value “255.255.255.255” int inet_aton (const char* strptr, struct in_addr inaddr); translate dotted-decimal notation to IP address; returns 1 on success, 0 on failure char* inet_ntoa (struct in_addr inaddr); translate IP address to ASCII dotted-decimal notation (e.g., “128.32.36.37”); not thread-safe

  46. Socket API • Creating a socket int socket(int domain, int type, int protocol) • domain (family) = AF_INET, PF_UNIX, AF_OSI • type = SOCK_STREAM, SOCK_DGRAM • protocol = TCP, UDP, UNSPEC • return value is a handle for the newly created socket

  47. Sockets (cont) • Passive Open (on server) int bind(int socket, struct sockaddr *addr, int addr_len) int listen(int socket, int backlog) int accept(int socket, struct sockaddr *addr, int addr_len) • Active Open (on client) int connect(int socket, struct sockaddr *addr, int addr_len)

  48. Sockets (cont) • Sending Messages int send(int socket, char *msg, int mlen, int flags) • Receiving Messages int recv(int socket, char *buf, int blen, int flags)

  49. Point-to-Point Links Reading: Peterson and Davie, Ch. 2 Outline Hardware building blocks Encoding Framing Error Detection Reliable transmission • Sliding Window Algorithm

  50. Direct Link Issues in the OSI and Hardware/Software Contexts Application Presentation user-level software Session Transport reliability kernel software (device drivers) Network framing, error detection, MAC Data Link hardware (network adapter) Physical encoding

More Related