The Ip in Tcp/Ip

Total Page:16

File Type:pdf, Size:1020Kb

The Ip in Tcp/Ip 52-20-30 DATA COMMUNICATIONS MANAGEMENT UNDERSTANDING THE INTERNET PROTOCOL: THE IP IN TCP/IP Gilbert Held INSIDE The Internet Protocol; Datagrams and Segments; Datagrams and Datagram Transmission; Routing; The IP Header INTRODUCTION This two-part article focuses on the first layer of the TCP/IP protocol suite. While the Internet Protocol (IP) is the primary protocol most peo- ple associate with the network layer, there are two related protocols that must be considered when discussing the TCP/IP protocol suite. Those protocols are the Address Resolution Protocol (ARP) and the Internet Control Message Protocol (ICMP). This article focuses on what this author commonly refers to as the Net- work Layer Troika of the TCP/IP protocol suite: IP, ARP, and ICMP. In ex- amining the Internet Protocol, particular attention is paid to the structure of the IP header and its fields, which are examined by routers as a mech- anism for making forwarding decisions. A second related article (52-20-31) focuses on another specific IP area, addressing, as the composition of IP addresses determines how data- PAYOFF IDEA grams are routed from source to des- The Internet Protocol (IP) represents the network tination, as well as the number of layer of the TCP/IP protocol suite. It was devel- hosts that can be connected to a spe- oped as a mechanism to interconnect packet- cific type of network. The second ar- switched TCP/IP networks. Since the initial devel- opment of TCP/IP, its modular architecture has ticle examines IP addressing in terms enabled literally hundreds of applications to be of several little-known areas of IP developed that use the protocol suite as a trans- that, having knowledge about, can port for communications. By developing an un- provide network design and opera- derstanding of these important technologies, the network manager will be better positioned to tion flexibility. Two examples of make effective decisions regarding the ongoing such topics are the assignment of support and evolution of networks under his or her purview. Auerbach Publications © 2001 CRC Press LLC DATA COMMUNICATIONS MANAGEMENT multiple network addresses to an interface and the use of a zero subnet. The filtering of IP datagrams by routers and firewalls can occur, based on IP addresses, as well as ICMP message types and control field values. The initial focus in this article is on IP, to include its use for routing datagrams across a network and between interconnected networks. In doing so, the author examines, in detail, the composition of the IP head- er and the use of different fields in the header. Once accomplished, attention is directed to the role and operation of the Address Resolution Protocol (ARP), which includes examining the ra- tionale for a little-known ARP technique that can considerably facilitate the operation of delay-sensitive transmissions such as Voice over IP. In concluding the second article (52-20-31), the author focuses on the Inter- net Control Message Protocol (ICMP). THE INTERNET PROTOCOL The Internet Protocol (IP) represents the network layer of the TCP/IP protocol suite. IP was developed as a mechanism to interconnect packet- switched TCP/IP-based networks to form an internet. Here, the term “in- ternet” with a lowercase “i” is used to represent the connection of two or more TCP/IP-based networks. Datagrams and Segments IP transmits blocks of data referred to as datagrams, and receives upper layer protocol data containing either a TCP or UDP header, referred to as a TCP segment or UDP datagram. The prefix of an IP header to the TCP segment or UDP datagram results in the formation of an IP datagram. This datagram contains a destination IP address that is used for routing purposes. Datagrams and Datagram Transmission To alleviate potential confusion between datagrams and an obsolete transmission method referred to as datagram transmission, a few words are in order. When the ARPAnet evolved, it experimented with two meth- ods of packet transmission. One method was referred to as datagram transmission and avoided the use of routers to perform table lookups. Under datagram transmission, each node in a network transmits a re- ceived datagram onto all ports other than the port on which the datagram was received. While this technique avoids the need for routing table lookup operations, it can result in duplicate datagrams being received at certain points within a network. This results in the necessity to develop software to discard duplicate datagrams, adding an additional level of complexity to networking. Thus, datagram transmission was soon dis- carded in favor of the creation of virtual circuits that represent a tempo- Auerbach Publications © 2001 CRC Press LLC UNDERSTANDING THE INTERNET PROTOCOL: THE IP IN TCP/IP rary path established between source and destination. As such, datagram transmission will actually be referencing the transmission of datagrams via a virtual circuit created between source and destination. Routing The actual routing of an IP datagram occurs on a best-effort or connec- tionless delivery mechanism. This is because IP by itself does not estab- lish a session between the source and destination before it transports datagrams. When IP transports a TCP segment, the TCP header results in a connection-oriented session between two Layer 4 nodes transported by IP as a Layer 3 network protocol. The importance of IP can be noted by the fact that routing between networks is based on IP addresses. As discussed later in this article, the device that routes data between different IP addressed networks is known as a router. Because it would be extremely difficult — if not im- possible — to statically configure every router in a large network to know the route to other routers and networks connected to different routers, routing protocols are indispensable to the operation of a dynam- ic series of interconnected IP networks. The best way to obtain an appre- ciation for the operation of IP is through an examination of the fields in its header. The IP Header The current version of IP is version 4, resulting in IP commonly referred to as IPv4. The next generation of IP is IPv6. This section focuses atten- tion on IPv4. Exhibit 1 illustrates the fields contained in the IPv4 header. In examin- ing this header, note that the header consists of a minimum of 20 bytes of data, with the width of each field shown with respect to a 32-bit (4-byte) word. Bytes versus Octets. In this article, the term “byte” refers to a sequence of eight bits used in a common manner. During the development of the TCP/IP protocol suite and continuing today, most standards documents use the term “octet” to reference a collection of eight bits. The use of the term “octet” is due to differences in the composition of a byte during the 1960s. During the early development of computer systems, differences in computer architecture resulted in the use of groupings of five to ten bits to represent a computer byte. Thus, the term “byte” at that time was am- biguous, and standards-making bodies decided to use the term “octet” to reference a grouping of 8 bits. Because all modern computers use 8-bit bytes, the term “byte” is no longer ambiguous. Thus, the term “byte” is used throughout this article as well as (52-20-31). Auerbach Publications © 2001 CRC Press LLC DATA COMMUNICATIONS MANAGEMENT EXHIBIT 1 — The Ipv4 Header To obtain an appreciation for the operation of IP, one can examine the functions of the fields in the header. In doing so, and when appropriate, relation of certain fields to routing and security is discussed. Vers Field. The Vers field is four bits in length and is used to identify the version of IP used to create an IP datagram. The current version of IP is v4, with the next generation of IP assigned as version 6 (v6). The four bits in the Vers field support 16 version numbers. Under RFC 1700, a listing of Internet version numbers can be obtained and a sum- mary of that listing is included in Exhibit 2. In examining Exhibit 2, note that the reason the next-generation Internet Protocol is IPv6, instead of IPv5, relates to the fact that Version 5 was previously assigned to an ex- perimental protocol referred to as the Streams 2 Protocol. Hlen Field. The length of the IP header can vary due to its ability to support options. To allow a receiving device to correctly interpret the contents of the header from the remainder of an IP datagram requires the receiving device to know where the header ends. This function is per- formed by the Hlen field, the value of which indicates the length of the header. The Hlen field is four bits in length. In examining Exhibit 1, note that the IP header consists of 20 bytes of fixed information followed by op- tions. Because it is not possible to use a four-bit field to directly indicate the length of a header equal to or exceeding 320 bytes, the value in this field represents the number of 32-bit words in the header. As an exam- ple, the shortest IP header is 20 bytes, which represents 160 bits. When divided by 32 bits, this results in a value of 160/32 (or 5), which is the value set into the Hlen field when the IP header contains 20 bytes and no options. Auerbach Publications © 2001 CRC Press LLC UNDERSTANDING THE INTERNET PROTOCOL: THE IP IN TCP/IP EXHIBIT 2 — Assigned Internet Version Numbers Numbers Assignment 0 Reserved 1–3 Unassigned 4IP 5 Streams 6 IPv6 7 TP/IX 8 P Internet Protocol (PIP) 9 TUBA 10–14 Unassigned 15 Reserved Service Type Field.
Recommended publications
  • Uila Supported Apps
    Uila Supported Applications and Protocols updated Oct 2020 Application/Protocol Name Full Description 01net.com 01net website, a French high-tech news site. 050 plus is a Japanese embedded smartphone application dedicated to 050 plus audio-conferencing. 0zz0.com 0zz0 is an online solution to store, send and share files 10050.net China Railcom group web portal. This protocol plug-in classifies the http traffic to the host 10086.cn. It also 10086.cn classifies the ssl traffic to the Common Name 10086.cn. 104.com Web site dedicated to job research. 1111.com.tw Website dedicated to job research in Taiwan. 114la.com Chinese web portal operated by YLMF Computer Technology Co. Chinese cloud storing system of the 115 website. It is operated by YLMF 115.com Computer Technology Co. 118114.cn Chinese booking and reservation portal. 11st.co.kr Korean shopping website 11st. It is operated by SK Planet Co. 1337x.org Bittorrent tracker search engine 139mail 139mail is a chinese webmail powered by China Mobile. 15min.lt Lithuanian news portal Chinese web portal 163. It is operated by NetEase, a company which 163.com pioneered the development of Internet in China. 17173.com Website distributing Chinese games. 17u.com Chinese online travel booking website. 20 minutes is a free, daily newspaper available in France, Spain and 20minutes Switzerland. This plugin classifies websites. 24h.com.vn Vietnamese news portal 24ora.com Aruban news portal 24sata.hr Croatian news portal 24SevenOffice 24SevenOffice is a web-based Enterprise resource planning (ERP) systems. 24ur.com Slovenian news portal 2ch.net Japanese adult videos web site 2Shared 2shared is an online space for sharing and storage.
    [Show full text]
  • The Transport Layer: Tutorial and Survey SAMI IREN and PAUL D
    The Transport Layer: Tutorial and Survey SAMI IREN and PAUL D. AMER University of Delaware AND PHILLIP T. CONRAD Temple University Transport layer protocols provide for end-to-end communication between two or more hosts. This paper presents a tutorial on transport layer concepts and terminology, and a survey of transport layer services and protocols. The transport layer protocol TCP is used as a reference point, and compared and contrasted with nineteen other protocols designed over the past two decades. The service and protocol features of twelve of the most important protocols are summarized in both text and tables. Categories and Subject Descriptors: C.2.0 [Computer-Communication Networks]: General—Data communications; Open System Interconnection Reference Model (OSI); C.2.1 [Computer-Communication Networks]: Network Architecture and Design—Network communications; Packet-switching networks; Store and forward networks; C.2.2 [Computer-Communication Networks]: Network Protocols; Protocol architecture (OSI model); C.2.5 [Computer- Communication Networks]: Local and Wide-Area Networks General Terms: Networks Additional Key Words and Phrases: Congestion control, flow control, transport protocol, transport service, TCP/IP 1. INTRODUCTION work of routers, bridges, and communi- cation links that moves information be- In the OSI 7-layer Reference Model, the tween hosts. A good transport layer transport layer is the lowest layer that service (or simply, transport service) al- operates on an end-to-end basis be- lows applications to use a standard set tween two or more communicating of primitives and run on a variety of hosts. This layer lies at the boundary networks without worrying about differ- between these hosts and an internet- ent network interfaces and reliabilities.
    [Show full text]
  • A Reliable Real-Time Transport Protocol for Networked Control
    AReliableReal-TimeTransportProtocolforNetworked Control Systems over Wireless Networks (Research Master) ATHESISSUBMITTEDTO THE SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE OF QUEENSLAND UNIVERSITY OF TECHNOLOGY IN FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF INFORMATION TECHNOLOGY (RESEARCH) Xiaohan Shi School of Electrical Engineering and Computer Science Queensland University of Technology December 11, 2012 Copyright in Relation to This Thesis !c Copyright 2012 by Xiaohan Shi. All rights reserved. Statement of Original Authorship The work contained in this thesis has not been previously submitted to meet requirements for an award at this or any other higher education institution. To the best of my knowledge and belief, the thesis contains no material previously published or written by another person except where due reference is made. Signature: QUT Verified Signature Date: i ii To my family iii iv Abstract Deploying wireless networks in networked control systems (NCSs) has become more and more popular during the last few years. As a typical type of real-time control systems, an NCS is sensitive to long and nondeterministic time delay and packetlosses.However,thenatureof the wireless channel has the potential to degrade the performance of NCS networks in many aspects, particularly in time delay and packet losses. Transport layer protocols could play an important role in providing both reliable and fast transmission service to fulfill NCS’s real-time transmission requirements. Unfortunately, none of the existing transport protocols, including the Transport Control Protocol (TCP) and the User Datagram Protocol (UDP), was designed for real-time control applications. Moreover, periodic data and sporadic data are two types of real-time data traffic with different priorities in an NCS.Duetothelackofsupportfor prioritized transmission service, the real-time performance for periodic and sporadic data in an NCS network is often degraded significantly, particularly under congested network conditions.
    [Show full text]
  • Moving to Ipv6(PDF)
    1 Chicago, IL 9/1/15 2 Moving to IPv6 Mark Kosters, Chief Technology Officer With some help from Geoff Huston 3 The Amazing Success of the Internet • 2.92 billion users! • 4.5 online hours per day per user! • 5.5% of GDP for G-20 countries Just about anything about the Internet Time 3 4 Success-Disaster 5 The Original IPv6 Plan - 1995 Size of the Internet IPv6 Deployment IPv6 Transition – Dual Stack IPv4 Pool Size Time 6 The Revised IPv6 Plan - 2005 IPv4 Pool Size Size of the Internet IPv6 Transition – Dual Stack IPv6 Deployment 2004 2006 2008 2010 2012 Date 7 Oops! We were meant to have completed the transition to IPv6 BEFORE we completely exhausted the supply channels of IPv4 addresses! 8 Today’s Plan IPv4 Pool Size Today Size of the Internet ? IPv6 Transition IPv6 Deployment 0.8% Time 9 Transition... The downside of an end-to-end architecture: – There is no backwards compatibility across protocol families – A V6-only host cannot communicate with a V4-only host We have been forced to undertake a Dual Stack transition: – Provision the entire network with both IPv4 AND IPv6 – In Dual Stack, hosts configure the hosts’ applications to prefer IPv6 to IPv4 – When the traffic volumes of IPv4 dwindle to insignificant levels, then it’s possible to shut down support for IPv4 10 Dual Stack Transition ... We did not appreciate the operational problems with this dual stack plan while it was just a paper exercise: • The combination of an end host preference for IPv6 and a disconnected set of IPv6 “islands” created operational problems – Protocol
    [Show full text]
  • The Internet Development Process Stockholm October 2010
    The Internet development Process Stockholm October 2010 Pål Spilling What I would talk about? • The main Norwegian contributions • Competitions between alternatives • Did Norway benefit from its participation? • Some observations and reflections • Conclusion A historical timeline 1981/82 TCP/IP accepted standard for US 1993 Web browser Mosaic Defence became available 1980 TCP/IP fully 2000 developed 1975 Start of the Internet Project; 1974 Preliminary specificaons of TCP 1977 First 3 – network Demonstration Mid 1973 ARPANET covers US, Hawaii, FFI Kjeller, and UCL London 1950 1955 ‐1960, End 1968 Ideas of resource Start of the ARPANET sharing networks project Norway and UK on ARPANET 1973 London o SATNET o Kjeller Norwegian Contributions • SATNET development – Simulations – Performance measurements • Internet performance measurements • Packet speech experiments over the Internet • Improved PRNET protocol architecture Competitions between alternatives • X.25 (ITU) • ISO standards (committee work) • DECNET (proprietary) • IBM (proprietary) • TCP/IP demonstrated its usefullness i 1977 accepted as a standard for US defence Norwegian benefits • Enabled me to create a small Norwegian internet • Got access to UNIX, with TCP/IP and user services integrated • Gave research scientists early exposure to internet and its services • Early curriculum in computer communications; Oslo University Observations and reflections • Norwegian Arpanet Committee; dissolved itself due to lack of interest • IP address space too small for todays use • TCP split in
    [Show full text]
  • Routing Loop Attacks Using Ipv6 Tunnels
    Routing Loop Attacks using IPv6 Tunnels Gabi Nakibly Michael Arov National EW Research & Simulation Center Rafael – Advanced Defense Systems Haifa, Israel {gabin,marov}@rafael.co.il Abstract—IPv6 is the future network layer protocol for A tunnel in which the end points’ routing tables need the Internet. Since it is not compatible with its prede- to be explicitly configured is called a configured tunnel. cessor, some interoperability mechanisms were designed. Tunnels of this type do not scale well, since every end An important category of these mechanisms is automatic tunnels, which enable IPv6 communication over an IPv4 point must be reconfigured as peers join or leave the tun- network without prior configuration. This category includes nel. To alleviate this scalability problem, another type of ISATAP, 6to4 and Teredo. We present a novel class of tunnels was introduced – automatic tunnels. In automatic attacks that exploit vulnerabilities in these tunnels. These tunnels the egress entity’s IPv4 address is computationally attacks take advantage of inconsistencies between a tunnel’s derived from the destination IPv6 address. This feature overlay IPv6 routing state and the native IPv6 routing state. The attacks form routing loops which can be abused as a eliminates the need to keep an explicit routing table at vehicle for traffic amplification to facilitate DoS attacks. the tunnel’s end points. In particular, the end points do We exhibit five attacks of this class. One of the presented not have to be updated as peers join and leave the tunnel. attacks can DoS a Teredo server using a single packet. The In fact, the end points of an automatic tunnel do not exploited vulnerabilities are embedded in the design of the know which other end points are currently part of the tunnels; hence any implementation of these tunnels may be vulnerable.
    [Show full text]
  • Lecture 11: PKI, SSL and VPN Information Security – Theory Vs
    Lecture 11: PKI, SSL and VPN Information Security – Theory vs. Reality 0368-4474-01, Winter 2011 Yoav Nir ©2011 Check Point Software Technologies Ltd. | [Restricted] ONLY for designated groups and individuals What is VPN ° VPN stands for Virtual Private Network ° A private network is pretty obvious – An Ethernet LAN running in my building – Wifi with access control – A locked door and thick walls can be access control – An optical fiber running between two buildings ©2011 Check Point Software Technologies Ltd. 2 What is a VPN ° What is a non-private network? – Obviously, someone else’s network. ° Obvious example: the Internet. ° The Internet is pretty fast, and really cheap. ° What do I do if I have offices in several cities – And people working from home – And sales people working from who knows where ° We could use the Internet, but… – People could see my data – People could modify my messsages – People could pretend to be other people ©2011 Check Point Software Technologies Ltd. 3 What is a VPN ° I could run my own cables around the world. ° I could buy an MPLS connection from a local telco – Bezeq would love to sell me one. They call it IPVPN, and it’s pretty much a switched link just for my company – But I can’t get that to the home or mobile users – And it’s mediocre (but consistent) speed – And Bezeq can still do whatever it wants – And it’s really expensive – The incremental cost of using the Internet is zero ° A virtual private network combines the relative low-cost of using the Internet with the privacy of a leased line.
    [Show full text]
  • Adding Enhanced Services to the Internet: Lessons from History
    Adding Enhanced Services to the Internet: Lessons from History kc claffy and David D. Clark [email protected] and [email protected] September 7, 2015 Contents 1 Introduction 3 2 Related technical concepts 4 2.1 What does “enhanced services” mean? . 4 2.2 Using enhanced services to mitigate congestion . 5 2.3 Quality of Service (QoS) vs. Quality of Experience (QoE) . 6 2.4 Limiting the use of enhanced services via regulation . 7 3 Early history of enhanced services: technology and operations (1980s) 7 3.1 Early 1980s: Initial specification of Type-of-Service in the Internet Protocol suite . 7 3.2 Mid 1980s: Reactive use of service differentation to mitigate NSFNET congestion . 10 3.3 Late 1980s: TCP protocol algorithmic support for dampening congestion . 10 4 Formalizing support for enhanced services across ISPs (1990s) 11 4.1 Proposed short-term solution: formalize use of IP Precedence field . 11 4.2 Proposed long-term solution: standardizing support for enhanced services . 12 4.3 Standardization of enhanced service in the IETF . 13 4.4 Revealing moments: the greater obstacle is economics not technology . 15 5 Non-technical barriers to enhanced services on the Internet (2000s) 15 5.1Early2000s:afuneralwakeforQoS............................ 15 5.2 Mid 2000s: Working with industry to gain insight . 16 5.3 Late 2000s: QoS becomes a public policy issue . 17 6 Evolving interconnection structure and implications for enhanced services (2010s) 20 6.1 Expansion of network interconnection scale and scope . 20 6.2 Emergence of private IP-based platforms to support enhanced services . 22 6.3 Advancing our empirical understanding of performance impairments .
    [Show full text]
  • Features of the Internet History the Norwegian Contribution to the Development PAAL SPILLING and YNGVAR LUNDH
    Features of the Internet history The Norwegian contribution to the development PAAL SPILLING AND YNGVAR LUNDH This article provides a short historical and personal view on the development of packet-switching, computer communications and Internet technology, from its inception around 1969 until the full- fledged Internet became operational in 1983. In the early 1990s, the internet backbone at that time, the National Science Foundation network – NSFNET, was opened up for commercial purposes. At that time there were already several operators providing commercial services outside the internet. This presentation is based on the authors’ participation during parts of the development and on literature Paal Spilling is studies. This provides a setting in which the Norwegian participation and contribution may be better professor at the understood. Department of informatics, Univ. of Oslo and University 1 Introduction Defense (DOD). It is uncertain when DoD really Graduate Center The concept of computer networking started in the standardized on the entire protocol suite built around at Kjeller early 1960s at the Massachusetts Institute of Technol- TCP/IP, since for several years they also followed the ogy (MIT) with the vision of an “On-line community ISO standards track. of people”. Computers should facilitate communica- tions between people and be a support for human The development of the Internet, as we know it today, decision processes. In 1961 an MIT PhD thesis by went through three phases. The first one was the Leonard Kleinrock introduced some of the earliest research and development phase, sponsored and theoretical results on queuing networks. Around the supervised by ARPA. Research groups that actively same time a series of Rand Corporation papers, contributed to the development process and many mainly authored by Paul Baran, sketched a hypotheti- who explored its potential for resource sharing were cal system for communication while under attack that permitted to connect to and use the network.
    [Show full text]
  • High Speed WAN Data Transfers for Science
    1 Breaking the 1 GByte/sec Barrier? High speed WAN data transfers for science S. Ravot, J. Bunn, H. Newman, Y. Xia, D. Nae, X. Su, California Institute of Technology 1200 E California Blvd, Pasadena CA 91125 O. Martin CERN 1211 Geneva 23, Switzerland In this paper we describe the current state of the art in when the bandwidth and the latency increase. In particular, equipment, software and methods for transferring large TCP’s additive increase policy limits its ability to use spare scientific datasets at high speed around the globe. We bandwidth. first present a short introductory history of the use of In this paper we describe experiments that illustrate TCP’s networking in HEP, some details on the evolution, limitations. We report on our measurements using the current status and plans for the LHCnet, one of the largest network testbeds available Caltech/CERN/DataTAG transAtlantic link, and a today, having 10 Gb/s links connecting CERN in Geneva, description of the topology and capabilities of the Starlight in Chicago and the Caltech campus in Pasadena. research networks between CERN and HEP institutes In light of TCP’s limitations, we then explain how we have in the USA. We follow this with some detailed material tuned the end-systems and TCP Reno parameters to achieve on the hardware and software environments we have record breaking data transfers. Finally, we present an used in collaboration with international partners experiment currently underway in our group to transfer (including CERN and DataTAG) to break several High Energy Physics data files from a disk server at CERN Internet2 land speed records over the last couple of via a 10Gb/s network path to a disk server at Caltech (a years.
    [Show full text]
  • 829 DARPA November 1982 PACKET SATELLITE TECHNOLOGY
    Network Working Group V. Cerf Request for Comments: 829 DARPA November 1982 PACKET SATELLITE TECHNOLOGY REFERENCE SOURCES Vinton G. Cerf Defense Advanced Research Projects Agency ABSTRACT This paper describes briefly the packet satellite technology developed by the Defense Advanced Research Projects Agency and several other participating organizations in the U.K. and Norway and provides a biblography of relevant papers for researchers interested in experimental and operational experience with this dynamic satellite-sharing technique. INTRODUCTION Packet Satellite technology was an outgrowth of early work in packet switching on multiaccess radio channels carried out at the University of Hawaii with the support of the Defense Advanced Research Projects Agency (DARPA). The primary difference between the earlier packet-switched ARPANET [1, 2] and the ALOHA system developed at the University of Hawaii [3] was the concept of multiple transmitters dynamically sharing a common and directly-accessible radio channel. In the ARPANET, sources of traffic inserted packets of data into the network through packet switches called Interface Message Processors (IMPs). The IMPs used high speed point-to-point full-duplex telephone circuits [4] on a store-and-forward basis. All packet traffic for a given telephone circuit was queued, if necessary, in the IMP and transmitted as soon as the packet reached the head of the queue. On such full duplex circuits there is exactly one transmitter and one receiver in each direction. The ALOHA system, on the other hand, assigned a common transmit channel frequency to ALL radio terminals. A computer at the University of Hawaii received packet bursts from the remote terminals which shared the "multi-access" channel.
    [Show full text]
  • The Impact of Transport Protocol, Packet Size, and Connection Type on the Round Trip Time
    Bachelor of Science in Computer Science with specialization in Game Programming June 2017 The impact of transport protocol, packet size, and connection type on the round trip time Tobias Kling Faculty of Computing Blekinge Institute of Technology SE–371 79 Karlskrona, Sweden i This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Degree of Bachelor of Science in Computer Science with specialization in Game Programming. The thesis is equivalent to 10 weeks of full-time studies. Contact Information: Author(s): Tobias Kling E-mail: [email protected] University Advisor: Francisco Lopez Luro Department of Creative Technologies Faculty of Computing Internet : www.bth.se Blekinge Institute of Technology Phone : +46 455 38 50 00 SE–371 79 Karlskrona, Sweden Fax : +46 455 38 50 57 Abstract While developing networking for games and applications, developers have a list of network specific requirements to be met as well as decide how to meet them. It is not always easy to decide what protocol is best suited for a given network configuration, or what is the best size of a data packet. By performing a comparative analysis, it becomes possible to identify how proto- cols, packet size, and network configuration impact the one-way travel time and throughput of a given implementation. The result shows how the different implementations compared against each other and the analysis tries to determine why they perform as they do. This gives a good overview of the pros and cons of how TCP, TCP(N), UDP, and RakNet, behave and perform over LANs and WLANs with varying packet size.
    [Show full text]