Film

CIS3210 Computer Networks. Transport Layer

Description
CIS3210 Computer Networks Transport Layer 1 Housekeeping Assignment #1 Implementation: Client-Server started Documentation: Ongoing! Goal for end of week: Load Balancer started, Client-Server nearing completion
Categories
Published
of 48
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
CIS3210 Computer Networks Transport Layer 1 Housekeeping Assignment #1 Implementation: Client-Server started Documentation: Ongoing! Goal for end of week: Load Balancer started, Client-Server nearing completion Assignment #2: Will be released sometime this week Give you an idea of what to focus on for A1 Lab Notes & Source: Will be posted on the website 2 Housekeeping Application Layer Animation DNS Animation on textbook website: ex.html Lets you visualize difference between recursive and iterative DNS queries, and how caching of past queries works 3 Goals Understand principles behind transport layer services: Multiplexing / De-multiplexing Reliable Data Transfer Flow Control Congestion Control Learn about transport layer protocols in the Internet UDP: connectionless transport TCP: connection-oriented TCP: congestion control 4 Outline Transport Layer Services Multiplexing / De-multiplexing Connectionless Transport: UDP Principles of Reliable Data Transfer Connection Oriented Transport: TCP Segment Structure Flow Control Connection Management Principles of Congestion Control TCP Congestion Control 5 Transport Services and Protocols provide logical communication between app processes running on different hosts transport protocols run in end systems send side: breaks app messages into segments, passes to network layer rcv side: reassembles segments into messages, passes to app layer Note: segments are essentially the same thing as packets recall different names at different layers! 6 Transport Services and Protocols more than one transport protocol available to apps Internet: TCP and UDP 7 Less common: Datagram Congestion Control Protocol (DCCP) Good for timing constraints Stream Control Transmission Protocol (SCTP) Allows for multiple IP addresses for endpoints, good for failover Resource Reservation Protocol (RSVP) Quality of Service For more see: ory:transport_layer_protocols Transport vs Network Layer network layer: logical communication between hosts transport layer: logical communication between processes relies on, enhances, network layer services Household analogy: 12 kids sending letters to 12 kids processes = kids app messages = letters in envelopes hosts = houses transport protocol = Ann and Bill (one kid in each house used for delivery to siblings) network-layer protocol = postal service 8 Internet Transport Layer Protocols reliable, in-order delivery (TCP) congestion control flow control connection setup unreliable, unordered delivery: UDP no-frills extension of besteffort IP services not available: delay guarantees bandwidth guarantees 9 Internet Transport Layer Protocols Notice, within the infrastructure, the transport layer may not be implemented! Because there is no service guarantee it is possible for extreme unfairness within the Internet 10 Outline Transport Layer Services Multiplexing / De-multiplexing Connectionless Transport: UDP Principles of Reliable Data Transfer Connection Oriented Transport: TCP Segment Structure Flow Control Connection Management Principles of Congestion Control TCP Congestion Control 11 Multiplexing / De-multiplexing Multiplexing at send host: gathering data from multiple sockets, enveloping data with header (later used for demultiplexing) Demultiplexing at rcv host: delivering received segments to correct socket = socket = process User application P3 application P1 P2 P4 application OS transport network transport network transport network hardware link physical link physical link physical host 1 host 2 host 3 12 Multiplexing / De-multiplexing Packets may arrive at physical layer in host2 in any order OS Layers determine which processes at App layer to send packets to = socket = process User application P3 application P1 P2 P4 application OS transport network transport network transport network hardware link link physical physical host 1 host 2 host 3 link physical 13 How De-Multiplexing Works host receives IP datagrams each datagram has source IP address, destination IP address each datagram carries 1 transport-layer segment each segment has source, destination port number host uses IP addresses & port numbers to direct segment to appropriate socket 32 bits source port # dest port # other header fields application data (message) TCP/UDP segment format 14 How De-Multiplexing Works host uses IP addresses & port numbers to direct segment to appropriate socket Recall from socket programing, each network interface (ethernet, wifi, etc.) has an IP associated with it Sockets must also be bound to a port, this maps the process to the IP and port 32 bits source port # dest port # other header fields application data (message) More about Internet Protocol (IP) in the Network Layer TCP/UDP segment format 15 Connectionless (UDP) De-multiplexing (Java) Create a socket with port number (there is a mapping). DatagramSocket mysocket1 = new DatagramSocket(9157); DatagramSocket mysocket2 = new DatagramSocket(5775); Send packet with destination IP address and port number. DatagramPacket sendpacket = new DatagramPacket(sendData, senddata.length, IPAddress, 6428); UDP socket identified by a two-tuple: When host receives UDP segment: checks destination port number in segment directs UDP segment to socket with that port number IP datagrams with different source IP addresses and/or source port numbers, but have the same destination IP and destination port number will be directed to same socket (dest IP address, dest port number) 16 Connectionless (UDP) De-multiplexing (C) Get server info with the particular port and IP / hostname (uses DNS to get IP) struct addrinfo hints, *servinfo; hints.ai_family = AF_UNSPEC; hints.ai_socktype = SOCK_DGRAM; getaddrinfo(ipaddress, 9157, &hints, &servinfo); // ipv4 or ipv6 // UDP //fill server info into servinfo linked list Loop through potential results until a successful socket is returned for(p = servinfo; p!= NULL; p = p- ai_next) { if ((sockfd = socket(p- ai_family, p- ai_socktype, p- ai_protocol)) == -1) { continue; } } Send packet with destination IP address and port number. char * msg = Hello World! ; sendto(svsockfd, msg, sizeof(msg)); UDP socket identified by a two-tuple: (dest IP address, dest port number) 17 Connectionless (UDP) De-multiplexing When host receives UDP segment: checks destination port number in segment directs UDP segment to socket with that port number IP datagrams with different source IP addresses and/or source port numbers, but have the same destination IP and destination port number will be directed to same socket = socket = process User application P3 application P1 P2 P4 application OS transport network transport network transport network hardware link physical link physical link physical 18 host 1 host 2 host 3 Connectionless (UDP) De-multiplexing When host receives UDP segment: checks destination port number in segment directs UDP segment to socket with that port number IP datagrams with different source IP addresses and/or source port numbers, but have the same destination IP and destination port number will be directed to same socket What is the source port used for? 19 Connectionless Demux (cont`d) P3 Server listening on port (6428); P1 P1 P2 Client IP: A SP: 9157 DP: 6428 IPs, data SP: 6428 DP: 9157 IPs, data server IP: C SP: 6428 DP: 5775 IPs, data SP: 5775 DP: 6428 IPs, data Client IP:B Source port number provides return address 20 Connection Oriented Demux TCP socket identified by 4- tuple: source IP address source port number dest IP address dest port number receiving host uses all four values to direct segment to appropriate socket Recall UDP requires only 2- tuple Server host may support many simultaneous TCP sockets: each socket identified by its own 4-tuple Web servers have different sockets for each connecting client non-persistent HTTP will have different socket for each request 21 Connection Oriented Demux Notice, server connections all in separate processes P1 P4 P5 P6 P2 P1 P3 SP: 5775 DP: 80 S-IP: B D-IP:C client IP: A SP: 9157 DP: 80 S-IP: A D-IP:C server IP: C SP: 9157 DP: 80 S-IP: B D-IP:C Client IP:B 22 Connection Oriented Demux: Threaded Web Server Notice, server connections all in one process, but separate threads P1 P4 P2 P1 P3 SP: 5775 DP: 80 S-IP: B D-IP:C client IP: A SP: 9157 DP: 80 S-IP: A D-IP:C server IP: C SP: 9157 DP: 80 S-IP: B D-IP:C Client IP:B 23 Threaded vs Non-Threaded Server Threaded or multi-process servers using fork() for example Handle multiple connections simultaneously More complex to implement Non threaded / multi-process Must handle request one at a time In order of arrival If persistence is used, users must wait until entire session completes before request is handled! Consider a web page with many objects Not good at handling requests of varying service times 24 Connection Oriented Demux 25 Connection Oriented Demux Table Example of what the OS keeps track of for Demux at the Server Dest. IP Dest. Port # Source IP Source Port # Socket ID (unique, OS dependent) Sockets: data structures, buffers, connection information, etc. 4ADDF563 4ADC ADDF ADC5634 5DEDA DEDA773 4B77883D B77883D A5553B DDA CDAAA52 4CDAAA52 4DDA5565 5A5553B7 26 Outline Transport Layer Services Multiplexing / De-multiplexing Connectionless Transport: UDP Principles of Reliable Data Transfer Connection Oriented Transport: TCP Segment Structure Flow Control Connection Management Principles of Congestion Control TCP Congestion Control 27 UDP: User Datagram Protocol [RFC 768] no frills, bare bones Internet transport protocol best effort service, UDP segments may be: lost delivered out of order to app connectionless: no handshaking between UDP sender, receiver each UDP segment handled independently of others Why is there a UDP? no connection establishment (which can add delay) simple: no connection state at sender, receiver small segment header no congestion control: UDP can blast away as fast as desired Good for multimedia, games 28 Applications and UDP 29 UDP: more often used for streaming multimedia apps loss tolerant rate sensitive other UDP uses DNS SNMP reliable transfer over UDP: add reliability at application layer application-specific error recovery! Length, in bytes of UDP segment, including header source port # dest port # length 32 bits Application data (message) checksum UDP segment format 30 UDP: more Length: Header (64 bits) + data length The length itself is 32 bits Max size Length, in bytes of UDP segment, including header 32 bits source port # dest port # length checksum Application data (message) UDP segment format 31 UDP Checksum Goal: detect errors (e.g., flipped bits) in transmitted segment Sender: treat segment contents as sequence of 16-bit integers checksum: addition (1 s complement sum) of segment contents sender puts checksum value into UDP checksum field Receiver: compute checksum of received segment check if computed checksum equals checksum field value: NO - error detected YES - no error detected. But maybe errors nonetheless? More later. 32 Internet Checksum Example Note When adding numbers, a carryout from the most significant bit needs to be added to the result Example: add two 16-bit integers wraparound sum checksum Outline Transport Layer Services Multiplexing / De-multiplexing Connectionless Transport: UDP Principles of Reliable Data Transfer Connection Oriented Transport: TCP Segment Structure Flow Control Connection Management Principles of Congestion Control TCP Congestion Control 34 Principles of Reliable Data Transfer important in app., transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) 35 Principles of Reliable Data Transfer important in app., transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) 36 Principles of Reliable Data Transfer important in app., transport, link layers top-10 list of important networking topics! characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) 37 Principles of Reliable Data Transfer characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Traditionally, the same reliable data transfer protocols for wired networks were applied to wireless However, wireless may be inherently more unreliable Subject to Interference Multipath Fading One of the arguments against strict adherence to layered architecture, at least for wireless 38 Multipath Fading 39 Multipath Fading Consider using GPS in an urban environment (Calgary, AB) 40 Multipath Fading Yellow is actual path, in some cases, off by more than a block, in others no signal at all! 41 Principles of Reliable Data Transfer important in app., transport, link layers top-10 list of important networking topics! In your application you are using send() or recv() characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) 42 Reliable Data Transfer: Getting Started rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer deliver_data(): called by rdt to deliver data to upper send side receive side udt_send(): called by rdt, to transfer packet over unreliable channel to receiver rdt_rcv(): called when packet arrives on rcv-side of channel 43 Reliable Data Transfer: Getting Started We ll: incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) consider only unidirectional data transfer but control info will flow on both directions! use finite state machines (FSM) to specify sender, receiver event causing state transition actions taken on state transition state: when in this state next state uniquely determined by next event state 1 event actions state 2 44 RDT 1.0: Reliable Transfer over a Reliable Channel underlying channel perfectly reliable no bit errors no loss of packets separate FSMs for sender, receiver: sender sends data into underlying channel receiver read data from underlying channel Wait for call from above rdt_send(data) packet = make_pkt(data) udt_send(packet) Wait for call from below rdt_rcv(packet) extract (packet,data) deliver_data(data) sender receiver 45 Outline Transport Layer Services Multiplexing / De-multiplexing Connectionless Transport: UDP Principles of Reliable Data Transfer Connection Oriented Transport: TCP Segment Structure Flow Control Connection Management Principles of Congestion Control TCP Congestion Control 46 For Next Class Think about what will happen if we introduce bit errors into RDT 1.0 model How can we detect and handle errors using states Also think about what happens when sender rate!= receiver rate If you haven`t already read how to do it in chapter 3, come up with a solution yourself and compare it to the techniques in the book 47 Reference * Computer Networking: A Top Down Approach, 5 th edition. Jim Kurose, Keith Ross Addison- Wesley, April 2009 This set of slide has been modified by Nidal Nasser, 2010 and Jason Ernst,
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks