DOCSLIB.ORG

Chapter 11 User Datagram Protocol (UDP)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Chapter 11 User Datagram Protocol (UDP) Chapter 11 User Datagram Protocol (UDP) Outline o Process-to-process communication o User datagram o Checksum o UDP operation o Use of UDP o UDP package Figure 11-1 Position of UDP in the TCP/IP Protocol Suite The McGraw-Hill Companies, Inc., 2000 Introduction o A transport layer protocol usually has two responsibilities n Create a process-to-process communications n Provide control mechanism at the transport layer o UDP does this task at a very minimal level o It only provides error control to some extent Introduction (Cont.) o Thus, UDP is a connectionless, unreliable transport protocol n Only add process-to-process to the IP n And perform very limited error checking o Advantages n UDP is very simple protocol using a minimum of overhead 1111.1.1 PROCESS TO PROCESS COMMUNICATION The McGraw-Hill Companies, Inc., 2000 Process-to-Process Communication o Host-to-host communication n Network layer protocol: IP n Deliver the message only to the destination computer o Process-to-process communication n Transport layer protocol: UDP and TCP n Deliver the message to the appropriate process Figure 11-2 UDP Versus IP The McGraw-Hill Companies, Inc., 2000 Port Numbers o Used to define the process o 0~65535 o Well-known port numbers n Some serves needs to be assign a universal port number o However, client’s port number can be defined randomly n Ephemeral port number Figure 11-3 Port Numbers The McGraw-Hill Companies, Inc., 2000 Figure 11-4 IP Addresses Versus Port Numbers The McGraw-Hill Companies, Inc., 2000 IANA Ranges o The IANA divides the port numbers into three ranges n Well-known: assigned and controlled by IANA o 0~1,023 n Registered: not assigned or controlled by IANA o 1,024~49,151 o Can only be registered with IANA to prevent duplication n Dynamic (or private): neither controlled nor registered o 49152~65535 o Ephemeral ports and can by used by any process Figure 11-5 IANA Ranges The McGraw-Hill Companies, Inc., 2000 Well-Known Ports for UDP Port Protocol Description 7 Echo Echoes a received datagram back to the sender 9 Discard Discards any datagram that is received 11 Users Active users 13 Daytime Return the data and the time 17 Quote Returns a quote of a day 19 Chargen Return a string of characters 53 Nameserver Domain Name Service 67 Bootps Server port to download bootstrap information 68 Bootpc Client port to download bootstrap information Well-Known Ports for UDP (Cont.) Port Protocol Description 69 TFTP Trivial File Transfer Protocol 111 RPC Remote Procedure Call 123 NTP Network Time Protocol 161 SNMP Simple Network Management Protocol 162 SNMP Simple Network Management Protocol (trap) Socket Addresses o UDP needs two identifiers n The IP address n The port number o Socket address n The combination of an IP address and a port number Figure 11-6 Socket Addresses The McGraw-Hill Companies, Inc., 2000 1111.2.2 USER DATAGRAM The McGraw-Hill Companies, Inc., 2000 User Datagram o UDP packets: called user datagrams n Have a fixed-size header of 8 bytes o The fields are n Source port number: 16-bits: 0~65535 o Usually chosen by the UDP software n Destination port number: 16-bits: 0~65535 n Length: 16 bits: o Total length (header plus data) of the user datagram o Minimum length must be 8 bytes (contains only header) n Checksum: 16 bits o Detect errors over the entire user datagram (header plus data) Figure 11-7 User Datagram Format The McGraw-Hill Companies, Inc., 2000 User Datagram (Cont.) o However, the UDP length can also be derived from the IP header n UDP length = IP length – IP header’s length o Thus, theoretically, the length field in a UDP datagram is not necessary n However, it is more efficient to derive the length of a UDP packet by the UDP package itself o Ask the IP layer is time consuming UDUDPP lelennggtthh == IIPP lelennggtthh -- IIPP hheeadaderer’’ss lelennggthth The McGraw-Hill Companies, Inc., 2000 1111.3.3 CHECKSUM The McGraw-Hill Companies, Inc., 2000 Checksum o UDP checksum calculation is different from the one for IP and ICMP o The checksum includes three sections n The Pseudoheader o However, it will not appear in the UDP datagram n The UDP header n The data coming from the application layer Pseudoheader o Some part of the header of the IP packet with some fields are filled with 0s o Fields n Source and destination IP address o To prevent that UDP datagram is correct but IP header is corrupted and be delivered to the wrong host n Protocol o To prevent the packet to deliver to the TCP o UDP has the value of 17 PseudoheaderAdded to the UDP Datagram Checksum Calculation at Sender o Add the pseudoheaderto the UDP datagram o Fill the checksum field with zeros o Divide the total bits into 16-bits words o If the total number of bytes is not even n Add 1 byte of padding (all 0s) o Add all 16-bit section using one’s complement arithmetic o Complement the result and insert it in the checksum field o Drop the pesudoheaderand any added padding o Deliver the UDP datagram to the IP software Checksum Calculation at Receiver o Add the pseudoheaderto the UDP user datagram o Add padding if needed o Divide the total bits into 16-bit sections o Add all 16-bit sections using one’s complement arithmetic o Complement the result o If the result is all 0s n Drop the pseudoheaderand any added padding n Accept the user datagram o Otherwise n Discard the user datagram Figure 11-9 Checksum Calculation of a Simple UDP User Datagram The McGraw-Hill Companies, Inc., 2000 Optional Use of the Checksum o The calculation of the checksum in UDP is optional o If the checksum is not calculated n The field is filled with 0s 1111.4.4 UDP OPERATION The McGraw-Hill Companies, Inc., 2000 UDP Operation o Connectionless Services o Flow and Error Control o Encapsulation and Decapsulation o Queuing Connectionless Services o Each user datagram is an independent datagram n Even coming from the same source process o The user datagram is not numbered o No connection establishment and no connection termination Flow and Error Control o No flow control n The receiver may overflow with incoming messages o No error control except for the checksum n The sender does not know if a message has been lost or duplicated Figure 11-10 Encapsulation and Decapsulation The McGraw-Hill Companies, Inc., 2000 Figure 11-11 Queues in UDP The McGraw-Hill Companies, Inc., 2000 Figure 11-12 Multiplexing and Demultiplexing The McGraw-Hill Companies, Inc., 2000 1111.5.5 USE OF UDP The McGraw-Hill Companies, Inc., 2000 Uses of UDP o For a process that require simple request-response communication with little concern for flow and error control o For a process with internal flow and error-control n TFTP (Trivial File Transfer Protocol) o For muticastingand broadcasting n Embedded in UDP but not in the TCP software o For some management processes o For some route updating protocol n RIP (Routing Information Protocol) 1111.6.6 UDP PACKAGE The McGraw-Hill Companies, Inc., 2000 UDP Package o Five components n A control-block table n Input queues n A control-block module n An input module n An output module Figure 11-13 UDP Package The McGraw-Hill Companies, Inc., 2000 Control-Block Table o Keep track of the open ports o Each entry has a minimum of four fields n State: FREE or IN-USE n Process ID n Port number n Corresponding queue number Input Queues o A set of input queues n One for each process o In the book’s design n They do not use output queues Control-Block Module o Manage the control-block table o Pseudo code n Receive: a process ID and a port number n Search the control block table for a FREE entry o If (not found) n Delete an entry using a predefined strategy o Create a new entry with the state IN-USE o Enter the process ID and the port number n Return Input Module o Receive: a user datagram from IP o Look for the corresponding entry in the control- block table n If (found) o Check the queue field to see if a queue is allocated o If (no) n Allocate a queue o Enqueuethe data in the corresponding queue n If (not found) o Ask the ICMP module to send an “unreachable port” message o Discard the user datagram o Return Output Module o Receive: data and information from a process o Create a UDP data datagram o Send the user datagram o Return Example: Control-Block Table at the Beginning State Process ID Port Number Queue Number -------- ------------ -------------- ------------------ IN-USE2,34552,01034 IN-USE3,42252,011 FREE IN-USE4,65252,01238 FREE EExaxammpplele 11 o The first activity is the arrival of a user datagram with destination port number 52,012 o The input module searches for this port number and finds it o Queue number 38 has been assigned to this port n The port has been previously used o The input module sends the data to queue 38 o The control-block table does not change EExaxammpplele 22 o After a few seconds, a process starts o It asks the operating system for a port number and is granted port number 52,014 o Now the process sends its ID (4,978) and the port number to the control-block module to create an entry in the table o The module does not allocate a queue at this moment n because no user datagramshave arrived for this destination Modified Table After Example 2 State Process ID Port Number Queue Number -------- ------------ -------------- ------------------ IN-USE2,34552,01034 IN-USE3,42252,011 IN-USE4,97852,014 IN-USE4,65252,01238 FREE EExaxammpplele 33 o A user datagram now arrives for port 52,011 o The input module checks the table and finds that no queue has been allocated for this destination n This is the first time a user datagram has arrived for this
Load more

Recommended publications
  • EECS 122, Lecture 18
    Where We Are So Far… EECS 122, Lecture 18 Today’s Topics: • Networking concepts – remote access to resources Review of Where We Are – controlled sharing Introduction to Transport Layer • multiplexing: TDM, Stat Mux UDP: The User Datagram Protocol – protocols and layering • ISO reference model, encapsulation Introduction to Reliability • service model, error detection • end-to-end argument • soft state Kevin Fall, [email protected] Where We Are So Far… Where We Are So Far… • Development of the Internet • Direct-link networks – interconnection of heterogeneous networks – signals, modulation, error detection – simple best-effort service model – best-effort delivery between attached – fully-connected graph of hosts (routing) stations – possible error correction using codes • Internet scaling issues – MAC protocols, Ethernet – use of hierarchies in routing, addresses, DNS – use of caching in DNS Where We Are So Far… What We Are Missing… • The Internet Protocol • Access to process-level information – IP service model – currently, can only send traffic from one • best-effort datagram model computer to another • error detection in header only – no way to indicate which process or service • consistent, abstract packet, addressing should receive it • routing • Reliable transport • signaling (ICMP) – no way to know whether data received was • multicasting, IGMP, multicast routing correct • IP futures with IPv6 – no way to correct for delivery errors 1 Problem Set #3 The Transport Layer • Peterson & Davie: • provide application-to-application
    [Show full text]
  • Requirements
    Requirements • System Requirements, page 1 • Considerations for Thin Clients, page 3 • Port Requirements, page 4 • Supported Codecs, page 5 • AnyConnect Profiles and the Cisco ASA, page 5 System Requirements Important Each of the components listed in the following table must meet the requirements. Use of unsupported components can result in a nonfunctional deployment. Component Requirements SUSE Linux thin clients—Hardware SP2-supported hardware: Dell Wyse Z50D or D50D SP3-supported hardware: Dell Wyse D50Q, Z50Q, or Z50QQ Note For information about video resolution and performance, see Video Resolution, on page 3. SUSE Linux Platform SP2 Image 11.2.092 SUSE Linux Platform SP3 Image 11.3.092 Deployment and Installation Guide for Cisco Virtualization Experience Media Engine for SUSE Linux Release 11.0 1 Requirements System Requirements Component Requirements Hosted virtual desktop OS (server-side) • Microsoft Windows 7 32 bit • Microsoft Windows 7 64 bit • Microsoft Windows 8 32 bit • Microsoft Windows 8 64 bit • Microsoft Windows 8.1 32 bit • Microsoft Windows 8.1 64 bit Connection broker for the hosted virtual desktop • Citrix XenDesktop 7.1, 7.5, or 7.6 • Citrix Xenapp 6.5, 7.5 or 7.6—Published desktops only • VMware Horizon View 5.3—Published desktops only • VMware Horizon 6.0 (with View)—Published desktops only • VMware Horizon 6 version 6.1.0—Published desktops only Receiver or client (on the thin client) The platform SP2 or SP3 image includes the required receiver or client. Cisco Unified Communications client Cisco Jabber for Windows 11.0 running on the hosted virtual desktop on the hosted virtual desktop (HVD).
    [Show full text]
  • Non-Trivial Off-Path Network Measurements Without Shared Side-Channel Resource Exhaustion." (2019)
    University of New Mexico UNM Digital Repository Computer Science ETDs Engineering ETDs Fall 12-14-2019 Non-Trivial Off-Path Network Measurements without Shared Side- Channel Resource Exhaustion Geoffrey I. Alexander Follow this and additional works at: https://digitalrepository.unm.edu/cs_etds Part of the Digital Communications and Networking Commons Recommended Citation Alexander, Geoffrey I.. "Non-Trivial Off-Path Network Measurements without Shared Side-Channel Resource Exhaustion." (2019). https://digitalrepository.unm.edu/cs_etds/102 This Dissertation is brought to you for free and open access by the Engineering ETDs at UNM Digital Repository. It has been accepted for inclusion in Computer Science ETDs by an authorized administrator of UNM Digital Repository. For more information, please contact [email protected], [email protected], [email protected]. Non-Trivial Off-Path Network Measurements without Shared Side-Channel Resource Exhaustion by Geoffrey Alexander B.A., Computer Science, University of New Mexico, 2011 M.S., Computer Science, University of New Mexico, 2015 DISSERTATION Submitted in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy Computer Science The University of New Mexico Albuquerque, New Mexico December 2019 Acknowledgments I would like to thank my advisor, Dr. Jedidiah R. Crandall for supporting and helping with my research over the years. I would also like to thank my dissertation committee: Dr. Soraya Abad-Mota, Dr. Phillipa Gill, and Dr. Jedidiah McClurg for serving on my dissertation committee and for their valuable feedback and suggestions on this dissertation. I would also like to thank Dr. Abdullah Mueen for his guidance when performing the clustering analysis carried out in Chapter 5.
    [Show full text]
  • User Datagram Protocol UDP • the User Datagram Protocol (UDP) Is Called a Connectionless, Unreliable Transport Protocol
    IANA International Assigned Number Authority ranges International Assigned Number Authority ranges: • It should be clear by now that the IP address and port number play different roles in selecting the final destination of data. • The destination IP address defines the host among the different hosts in the world. • After the host has been selected, the port number defines one of the processes on this destination host. Connectionless Vs connection- oriented services Connectionless services • In a connectionless services, the packet are sent from one party to another with no need for connection establishment or connection release. • The packet are not numbered; they may be delayed or lost or may arrive out of sequence. • There is no acknowledgment. • One of the transport layer protocol in the Internet model, UDP, is connectionless protocol. Connection-oriented services • In Connection-oriented service, a connection is first established between the sender and the receiver. • Data are transferred. • At the end, the connection is released. • Two of the transport layer protocol in the Internet model, TCP and SCTP, is connection- oriented protocol. Reliable Vs Unreliable • The transport layer service can be reliable or unreliable. • If the application layer program need reliability, we use a reliable transport layer protocol by implementing flow and error control at the transport layer. • This means a slower and more complex service. • On the other hand, if the application layer program does not need reliability because it uses its own flow and error control mechanism or it needs fast service or the nature of the service does nor demand flow and error control ( real- time application), then an unreliable protocol can be used.
    [Show full text]
  • Data Communication and Networking Concepts in User Datagram Protocol (UDP)
    International Journal of Recent Technology and Engineering (IJRTE) ISSN: 2277-3878, Volume-8 Issue-5, January 2020 Data Communication and Networking Concepts in User Datagram Protocol (UDP) T. Vedavathi, R. Karthick, R. Senthamil Selvan, P. Meenalochini Abstract: In most popular standards, the UDP (User PORTS datagram protocol plays a vital role in Internet protocol. To maintain point to point communication, we can use Normally, in the networking concepts are not required for datagram for specific application and also use dta sockets set up communication between data paths and also the for retransmission once packet lost. The multiplexing channels.it has used to addressing several different concepts evolved from software based structure applicable function and also provides data integrity at the source and by means of port number. The acceptable port range varies destination. TCP and SCTP are designed for many between 0 to 65535 whereas the expected message can be applications in the network interface if error free network reserved for Port 0[3]. There are three port numbers which needed. So that, to improve the performance metrics of was governed by IANA. First, UNIX based port number (0 teaching learning process, the wireless technology based to 1023. Second, (1024 to 49151) are used in particular networking concepts involved major parts. registered services. Third, (49152 to 65535 are allotted for any application specific. For all communication based Keywords: User Datagram, Internet Protocol, Internet endpoints were running through software designs. of Things. II. PACKET STRUCTURE I. INTRODUCTION The User Data gram protocol holds 16 bits of data The basic RFC 768 protocol was designed by David P.
    [Show full text]
  • Ppt on Tcp Ip Protocol Suite
    Ppt On Tcp Ip Protocol Suite weak-kneedly,Kutcha or organicism, phytophagic Ole never and debasing.relined any Issuant economiser! Baillie sometimesAlex baptise disbudded his forgivers his ululatingaustenite lissomly dually and or next-doorbeautifying after so loungingly!Quentin speedings and scrimshaws If a timer is not judge, its remaining time is considered tobe inÞnity. The lengthÞeld is not restricted like in domain term length Þeld. Understanding the intricacies of how computers interact is an adverb part of networking and is of taking interest around a sysadmin as well as delicious a developer. This table maps every lead source notice to the preferred interface used to reach from source. Then be in tcp lies between layers, which is provided for decimal value of the isn should always being purchased and. Responses are cached by firm name server, but hair usually well the resolver, although everything is implementation dependent. The table shows that equal is recommended to yell the multicast IP datagram inthree cases. The two associations collide. Alice stores this certiÞcateand public tender under JohnÕs name, but assigns a silk for this certiÞcate. The amount of compassion that same being transmitted through the Internet is increasing exponentially. As the Þgure shows, in the Þrst two cases, the report contains two group records; inthe last two cases, the report contains only time group record. Similarly, in a telephone conversation, thereare a wind of rules that either need to follow. This object deÞnes general information related to UDP, such article the numberof ports and damage of packets sent and received. UDP for the standard NFS.
    [Show full text]
  • UDP Encapsulation in Linux
    UDP Encapsulation in Linux Tom Herbert Google USA [email protected] Abstract Basics of UDP encapsulation UDP encapsulation encompasses the techniques and protocols to Encapsulation is the technique of adding network headers encapsulate and decapsulate networking packets of various to a fully formed packet for the purposes of transit across a protocols inside UDP. UDP encapsulation has become prevalent network. UDP encapsulation includes the techniques and in data centers, and in fact nearly all the solutions for network protocols to encapsulate networking packets within User virtualization currently being proposed in IETF are based on UDP Datagram Protocol [1]. Packets are contained in the UDP encapsulation. payload, and are said to be encapsulated in UDP packets. In this paper we present much of the recent work done by the Tunneling, overlay networks, and network virtualization, Linux networking community to make UDP encapsulation a first are terms often associated with encapsulation. Tunneling class citizen. This cumulative work has resulted in greatly refers to the use of a high level transport service to carry improved performance, robustness, and scalability. We begin by packets or messages from another service. Encapsulation is describing the basic support and model for UDP encapsulation. often the lower level mechanism that implements a tunnel. Next, we look at performance enhancements in the areas of load An overlay network is a computer network which is built balancing, checksum offload, and segmentation offload. Finally, on the top of another network. An overlay network may we examine two generic methods of UDP encapsulation: Foo- be composed of links which are implemented by over-UDP and Generic UDP Encapsulation.
    [Show full text]
  • Computer Networks Outline Socket Basics Ports Sockets and the OS
    Outline F Socket basics F TCP sockets F Socket details F Socket options Computer Networks F Final notes Sockets Socket Basics Ports F An end-point for a IP network connection F Numbers (vary in BSD, Solaris): – what the application layer “plugs into” – 0-1023 “reserved”, must be root – programmer cares about Application Programming Interface (API) – 1024 - 5000 “ephemeral” F End point determined by two things: – however, many systems allow > 3977 ports u (50,000 is correct number) – Host address: IP address is Network Layer F /etc/services: – Port number: is Transport Layer ftp 21/tcp F Two end-points determine a connection: telnet 23/tcp socket pair finger 79/tcp – ex: 206.62.226.35,p21 + 198.69.10.2,p1500 snmp 161/udp – ex: 206.62.226.35,p21 + 198.69.10.2,p1499 Sockets and the OS Transport Layer F UDP: User Datagram Protocol User – no acknowledgements Socket – no retransmissions Operating System – out of order, duplicate possible (Transport Layer) – connectionless F TCP: Transmission Control Protocol F User sees “descriptor”, integer index – reliable (in order, all arrive, no duplicates) – like: FILE *, or file index – flow control – returned by socket() call (more later) – connection – duplex – (proj 2) 1 Socket Details Addresses and Sockets F Unix Network Programming, W. Richard Structure to hold address information Stevens, 2nd edition, ã1998, Prentice Hall F Functions pass address from user to OS – bind() – connect() F Socket address structure – sendto() F TCP client-server F Functions pass address from OS to user F Misc stuff –
    [Show full text]
  • Tsvwg M. Larsen Internet-Draft Tietoenator Intended Status: Standards Track F
    tsvwg M. Larsen Internet-Draft TietoEnator Intended status: Standards Track F. Gont Expires: June 6, 2008 UTN/FRH December 4, 2007 Port Randomization draft-ietf-tsvwg-port-randomization-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 6, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Larsen & Gont Expires June 6, 2008 [Page 1] Internet-Draft Port Randomization December 2007 Abstract Recently, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput-reduction to broken connections or data corruption.
    [Show full text]
  • Tsvwg M. Larsen Internet-Draft Tietoenator Intended Status: Best Current F
    tsvwg M. Larsen Internet-Draft TietoEnator Intended status: Best Current F. Gont Practice UTN/FRH Expires: August 28, 2008 February 25, 2008 Port Randomization draft-ietf-tsvwg-port-randomization-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Larsen & Gont Expires August 28, 2008 [Page 1] Internet-Draft Port Randomization February 2008 Abstract Recently, awareness has been raised about a number of "blind" attacks that can be performed against the Transmission Control Protocol (TCP) and similar protocols. The consequences of these attacks range from throughput-reduction to broken connections or data corruption.
    [Show full text]
  • An Introduction to TCP/IP for Embedded System Designers 019-0074 • 070720-J
    An Introduction to TCP/IP For Embedded System Designers 019-0074 • 070720-J The latest revision of this manual is available on the Rabbit Semiconductor Web site, www.rabbit.com, for free, unregistered download. An Introduction to TCP/IP Part Number 019-0074–J • 070720 • Printed in U.S.A. ©2006 Rabbit Semiconductor Inc. • All rights reserved. No part of the contents of this manual may be reproduced or transmitted in any form or by any means without the express written permission of Rabbit Semiconductor. Permission is granted to make one or more copies as long as the copyright page contained therein is included. These copies of the manuals may not be let or sold for any reason without the express written permission of Rabbit Semiconductor. Rabbit Semiconductor reserves the right to make changes and improvements to its products without providing notice. Trademarks Rabbit and Dynamic C® are registered trademarks of Rabbit Semiconductor. Windows® is a registered trademark of Microsoft Corporation ii Table of Contents Chapter 1: Introduction 1 Chapter 2: Ethernet Basics 3 2.1 Ethernet Address.................................................................................................................................................3 2.2 Physical Connections..........................................................................................................................................3 2.2.1 Cables..........................................................................................................................................................4
    [Show full text]
  • Chapter 2 Lecture Presentation
    Chapter 2 Applications and Layered Architectures Protocols, Services & Layering OSI Reference Model TCP/IP Architecture How the Layers Work Together Berkeley Sockets Application Layer Protocols & Utilities 1 Chapter 2 Applications and Layered Architectures Protocols, Services & Layering 2 Layers, Services & Protocols z The overall communications process between two or more machines connected across one or more networks is very complex z Layering partitions related communications functions into groups that are manageable z Each layer provides a service to the layer above z Each layer operates according to a protocol z Let’s use examples to show what we mean 3 Web Browsing Application z World Wide Web allows users to access resources (i.e. documents) located in computers connected to the Internet z Documents are prepared using HyperText Markup Language (HTML) z A browser application program is used to access the web z The browser displays HTML documents that include links to other documents z Each link references a Uniform Resource Locator (URL) that gives the name of the machine and the location of the given document z Let’s see what happens when a user clicks on a link 4 1. DNS A. 64.15.247.200 Q. www.nytimes.com? z User clicks on http://www.nytimes.com/ z URL contains Internet name of machine (www.nytimes.com), but not Internet address z Internet needs Internet address to send information to a machine z Browser software uses Domain Name System (DNS) protocol to send query for Internet address z DNS system responds with Internet address 5 2. TCP ACK ACK, TCP Connection Request From: 64.15.247.200 Port 80 To:128.100.11.13 Port 1127 TCP Connection Request From: 128.100.11.13 Port 1127 To: 64.15.247.200 Port 80 z Browser software uses HyperText Transfer Protocol (HTTP) to send request for document z HTTP server waits for requests by listening to a well-known port number (80 for HTTP) z HTTP client sends request messages through an “ephemeral port number,” e.g.
    [Show full text]