02
Sat, Nov
2 New Articles

Not Your Typical TCP/IP Overview

Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

A solid grasp of TCP/IP fundamentals is essential to everything from effective workstation operation to systems management. Why then, with so many TCP/IP primers written to
“jump-start” us, is the goal of a broad understanding of TCP/IP still elusive?

TCP/IP is complex in its simplicity. That is to say, this popular, easy-to-understand protocol suite that enables millions of computers worldwide to communicate with one another is made complex only when attempts to explain this relatively unpretentious communications medium become needlessly long-winded.

For instance, writers paid by the word are compelled to explain in depth the development of the protocol. They describe how it began as a paranoiac reaction to the Soviet Union’s launch of Sputnik I in 1957, when the Department of Defense designed the Advanced Research Projects Agency Network. ARPANET, the Internet’s progenitor, was designed to survive a nuclear attack on any of its adjoining networks. I won’t do that here! Other TCP/IP writers of “introductory tutorials” forgo the 50,000-foot view altogether and haul out the electron microscope to, presumably, authenticate their own qualifications. In those “high-level” discussions of TCP/IP connections, you might expect to see irrelevant and distracting minutia like the fact that a 10Base5 Thick Ethernet cable’s maximum transmission length is 500 meters and its maximum operating speed is 10 Mb. I won’t do that either.

This is not your father’s TCP/IP overview!

Protocols

Everywhere we turn, we’re surrounded by “behavior expectations,” or protocols. Protocols ensure operations are carried out predictably, consistently, and orderly. In a LAN environment, for instance, literally thousands of transactions may be in flight at any given instant. Without some semblance of order, chaos would ensue, compromising the integrity of the network and making reliable data transmission impossible.

To achieve order, networks make extensive use of protocols. Requests that don’t honor the protocol du jour are routinely rejected or simply discarded. Popular network protocols include the SNA and the Open Systems Interconnection (OSI) models. Both are “layered” protocols: separate layers are responsible for designated functionality and interact with each other accordingly. One layer, for instance, may interface with a user or an

application, and another layer may interface with the physical network. SNA has, of course, been implemented on the OS/400 and the OS/390 (as VTAM).

Because the OSI model, which has no popular implementation, bears some similarity to the TCP/IP model, the two are often referred to as being analogous to one another. They are not. TCP/IP is more than just a protocol. In fact, it is an entire protocol suite specifying not only how various layers will intercommunicate but also how popular applications such as Web browsers, FTP clients, and Telnet implementations will behave.

The TCP/IP Protocol Stack

No discussion of interprocess communications can commence without a brief description of the TCP/IP protocol stack, illustrated in Figure 1. Traditionally represented with four layers, the stack is quite a bit easier to understand when its functions are distilled to the bare minimum.

At the Application Layer, various TCP/IP applications communicate with their cross-network counterparts via sockets in the Transport Layer, which is below the Application Layer. A socket is really nothing more than a port connecting two stacks. An FTP client application might connect to its local TCP port and then request a connection with a target computer’s port. You can almost imagine TCP/IP acting as an old-fashioned telephone operator as it makes a physical connection between your application (client) and the target application (server). At that point, data can flow along the created pipeline in accordance with the rules of application communication (i.e., a protocol).

The Transport Layer supports two types of sockets that the Application Layer may exploit: TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). Little needs to be said except that TCP is the more reliable protocol because of its provision for error checking. UDP, on the other hand, is leaner and meaner and makes no guarantees as to the delivery or integrity of the data. Telnet and FTP, for example, depend on TCP to guarantee the delivery and integrity of the data, while the Simple Network Management Protocol (SNMP) sends traffic through UDP because of its low overhead. A custom- designed client/server application could choose either protocol.

The Internet Layer is responsible for determining the location of the partner system as well as actually dispatching the data. To ship data, the Internet Layer uses IP and a “send and forget” mantra, which presumes a combination of application tracking and network availability will ensure successful transmission. Reliability is not the responsibility of the Internet Layer. Rather, reliability is the chore of TCP in the two Transport Layers. In addition to shipping the data, the Internet Layer is responsible for determining where the data needs to be shipped. For instance, if a client requests a connection to 192.168.0.2, it is the responsibility of the client’s Address Resolution Protocol (ARP) on the network where the target IP address resides to resolve the target system’s MAC address (i.e., the hardware address of its Ethernet card). In short, a higher level may address an envelope simply with the name juliet, but it is the Internet Layer that must add the street address, city, state, and zip code in preparation for mailing.

The lowest level in the stack is the Network Layer. It is here that data is physically shuttled between two points via the local medium (e.g., coax, twisted pair, or telephone line) and network connection (e.g., Token-Ring, Ethernet, or Point-to-Point Protocol [PPP]).

Stack-to-Stack Communication

Ultimately, what permits two applications to communicate via sockets and a virtual pipeline are the sophisticated address-lookup protocols and network topologies provided by TCP/IP. Though this framework is purposefully transparent to the applications programmer, it is necessary to understand it before pursuing in-depth knowledge of other specific TCP/IP topics.

As I mentioned, when one TCP/IP application needs to establish a session with another TCP/IP application (a client with a server, for example), the specified TCP/IP address is used to locate the physical MAC address of the target host. As a result, the Network Layer knows where to send the data. For clarity, two assumptions are made in this explanation:

• An address, rather than a hostname, was specified.
• The address resolved to the same network. If a hostname (a computer’s alias—e.g., juliet) or a domain name (e.g., mycompany. com) is specified, the IP address must first be ascertained. This check is done in one of two ways. First, the local computer’s host file is queried. The host file is a somewhat archaic name server with records of the format “ipaddress hostname.” For instance, the host file entry for Computer A in Figure 2 would include the entry
“192.168.0.2 juliet” indicating that a request for resolution for the hostname juliet would return 192.168.0.2.

If an entry is not located in the local host file, the computer’s name server (designated via configuration parameters) is queried. A name server is typically on a LAN server or other central machine. In Figure 2, the name server is located on Computer C. (It is worth mentioning that in the illustration, Computer C’s name server is part of a Domain Name System (DNS), which implies that network name resolution is distributed among several networked hosts. The Internet is the best example of a DNS. Fundamentally, the DNS and a network of backbone servers are all that differentiate the Internet from smaller networks.)

A request by romeo (Computer A) to open an FTP connection with juliet (Computer
B) resolves to a request for romeo’s ARP to affect a connection from 192.168.0.1 to
192.168.0.2. This request is formally made when the Network Layer passes the data packet to the corresponding MAC address. If the target server (the FTP server, or daemon, in this case) is available to accept connections, it will respond in turn and the pipeline between the stacks will be established.

Applications and the TCP/IP Stack

Although you may not be aware of it, many of your applications communicate directly with the TCP/IP protocol stack within your computer to communicate with a counterpart application on another computer via its corresponding TCP/IP stack. This process is illustrated in Figure 2. (One exception is the earliest permutations of Serial Line Internet Protocol [SLIP], in which a local computer merely connected to a remote TCP/IP protocol stack for services; there was no local stack. SLIP has been supplanted by SLIP/PPP, often referred to simply as PPP.)

As I mentioned, applications send data through TCP/IP to their counterparts via a pipeline. The endpoints of this pipeline are called sockets, which are simply aliases of the IP address and a port number. A TCP/IP application can use any port number from 0 to 65535 to communicate. However, some of these numbers (0 to 1023) are reserved for preordained functions such as FTP, Telnet, DNS, and SNMP. Others, 1024 to 49151, are registered with an organization called the Internet Assigned Numbers Authority (IANA) in much the same way that domain names are registered. The remaining ports are free for local “private use.”

Well-known and registered ports are necessary to maintain order on the network. Without them, whenever you wanted to make a connection to an FTP server (daemon) on a target machine, you would not only need to know the hostname or IP address, but also the port on which the server was waiting to accept connections (or on which the server was
“listening”). Instead, you simply do a quick search using one of the many references available on the Web (e.g., www.iana.org) and learn that the FTP server always connects to its local TCP/IP port 21. Of course, in many cases, the user is insulated from this sort of information. The designers of the client application may dynamically allocate any available

local port, and they will typically ensure that the application makes the correct request to connect to the appropriate port of the target host. The programmers of Netscape’s Navigator and Microsoft’s Internet Explorer Web browsers, for instance, append the well- known port for the HTTP server to any request a user makes. That well-known port is 80. For Telnet, TN3270, and TN5250, the well-known port is 23; for SNMP, it is 161. In most cases, you’ll never know the well-known port through which your applications communicate, nor do you need to know. However, for the truly curious, a NETSTAT command will reveal the port, thereby adding dimension to the client-server relationship. NETSTAT displays protocol statistics and current TCP/IP network connections. On a Windows workstation, you can execute the command from a DOS prompt; execution on other platforms varies with the TCP/IP implementation.

A fun and informative way to better understand sockets doesn’t even require TCP/IP access to another host. Every TCP/IP implementation includes a special loopback address that always points back to itself. That is, when this address request reaches the IP layer for MAC resolution, it is recognized as a local address and doesn’t get passed through the Network Layer. Instead, the request is passed back up through the stack to the target port. If you have an FTP daemon started on your system or a third-party FTP server, you can start an FTP session by pointing to IP address 127.0.0.1 (the loopback address). Once you have a connection, you can use the NETSTAT command to see the local address and port used by the client, as well as the target host IP address and port. You know now that the target port will be the FTP well-known port 21. Experiment with the loopback address. It’s a great way to observe how applications (whether they’re on the same host or thousands of miles apart) communicate with each other.

TCP Sockets

Practically all TCP/IP application communication, and most operations, involves socket communication. And most applications, whether they’re popular applications using well- known ports or home-grown client/server applications, use sockets in a similar manner.

As illustrated in Figure 3, a server or daemon application obtains a socket that the program uses to refer to the opened port (the server’s port must be known to all potential clients). The bind is a registration step the server must perform. When the initialization is complete, the server listens for connection requests on its open port. When a request comes in, the server accepts the connection and is ready to send or receive data based on a prearranged protocol.

The client, meanwhile, also creates a socket by specifying a local unused port. The client then attempts to connect to the known port (which is the port the server previously opened and registered) that will service it. The client might try to connect to a well-known or registered port, or, in the case of a homegrown application, the port need not be known to the entire Internet community but only to the users of the service. Again, once the connection is complete, the applications communicate with each other with simple send and receive operations. When they’re done, the tasks issue a close command to clean things up.

Let’s see how this might work in an FTP implementation. First, the FTP daemon would create a socket and bind itself to port 21, the well-known port for FTP. At that point, the server would listen for and accept all connection requests. The client, meanwhile, would also obtain a local socket, but not one from the reserved range (0 to 1023). Instead, the client might use port 1330, 1880, or some other local port that another client on the same host won’t attempt to open. Once the server accepts the connection, the client and server applications can exchange data using the prearranged protocol, in this case, the File Transfer Protocol, or FTP.

Where Do You Want to Go?

What’s next? You’ve shifted your focus from the overview of stack communication down to interprocess communication. You’ve observed that TCP/IP is not a single protocol, but a protocol suite consisting of the following:

• A set of protocols including the Transport Layer protocols TCP and UDP
• The Internet Layer protocol IP
• The various additional Network Layer protocols such as PPP and Ethernet
• The Application Layer protocols such as FTP, SNMP, Telnet, and any user- written client/server application communication protocols

You’ve also seen that, ultimately, applications communicate by establishing a pipeline via socket connections. And even with everything you’ve learned, you’re still at the threshold of TCP/IP. From this brief examination, you can glimpse the TCP/IP enigma: the complexity of the simplicity. Where you go now depends on your interest. If you’re a network planner, you’ll pursue more in-depth information on the Internet and Network Layers, perhaps from a DNS and network topology perspective. If you’re interested in applications development, you’ll pursue details of the Transport Layer—TCP and
UDP—and sockets programming. In either of these cases, you’ll find abundant information in the Request For Comment (RFC) documents that circulate among the Internet community and describe the protocols with nauseating detail. RFC791, for example, describes IP, and RFC794 describes FTP. There are more than 2,500 RFCs available by a simple Yahoo! search.

However, if your interest in TCP/IP was just a curiosity, you’re now armed with an understanding of what were previously cryptic configuration parameters and can see, at least, how applications communicate with each other across a LAN or the Internet.

So don’t just sit there; go FTP something!

Application Layer

Clients, Server/Daemons: Rexec, DNS, SNMP, Web Browser (HTTP client), FTP, Telnet/TN5250/TN3270, etc.

Transport Layer

TCP and UDP Sockets

Internet Layer

Address Resolution Protocol (ARP)

Network Layer

Ethernet, Token-Ring, FDDI, SLIP/PPP, etc.

Figure 1: Check out how the TCP/IP stack looks.

Computer C

e.g. 192.168.0.3

DNS Server

Physical Connection

e.g. SLIP/PPP Dial-Up Line (above), or, Ethernet LAN connection (below)

Figure 2: Here’s what a TCP/IP stack client/server communication model looks like.

Server

socket() bind() listen() accept()

send()/recv() close() end (or iterate)

Computer A

e.g. 192.168.0.1 Hostname: romeo

TCP/IP Protocol Stack

Computer B

e.g. 192.168.0.2 Hostname: juliet

TCP/IP Protocol Stack

TCP/IP Protocol Stack

FTP Client

Host

File

FTP Server (Daemon)

Client

socket() connect() send()/recv() close()
end

Figure 3: This diagram demonstrates how a typical client/server socket interprocess flow operates.

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: