Welcome to TCP/IP for QNX

Welcome to TCP/IP for QNX! This chapter covers the following topics:

What is a network?

A network is a series of interconnected computers. Every network involves two fundamental connection ``layers'':

Admittedly, this is a bit of an oversimplification - some data communications models (e.g. the OSI Reference Model) describe as many as seven layers within a network. But for our purposes here, the main distinction between hardware and software layers will suffice.

In order to communicate, both the hardware and software layers of a network must use the same ``language'' or protocol. And each computer on a network must have a unique ``name'' or address.

A QNX network natively supports a variety of network hardware (e.g. Arcnet, Ethernet, Token Ring, FDDI, etc.). Whatever the type of hardware, a QNX network communicates via the FLEET protocol. Although FLEET is fast, reliable, and transparent, this protocol has one major disadvantage - it's proprietary. Using FLEET alone, a QNX network is ``closed'' and can't communicate to non-QNX networks.

Why TCP/IP?

The TCP/IP protocols enable computers to share computing resources through multiple networks. Implemented on many operating systems, over a variety of network media, these widely accepted protocols have become a de facto standard.

Regardless of the platform, a system that supports TCP/IP can access resources located on any other system that supports TCP/IP. With appropriate configuration, this access can be to distant sites or simply to the computer on your neighbor's desk.

Over the years, many popular TCP/IP services have evolved, such as file transfer, remote login capability, and electronic mail. You can install all of these services on QNX.

The book on TCP/IP network administration

For all its benefits, TCP/IP requires skillful configuration. Fortunately, because TCP/IP networking has become so popular, many books have been written on the subject. We've found that Craig Hunt's TCP/IP Network Administration provides a clear description of the current state of TCP/IP, and we've included it as part of the documentation set for TCP/IP for QNX.

For the most part, you can rely on TCP/IP Network Administration to understand what's involved in using TCP/IP. Where the QNX implementation differs from the one described in that book, alternative approaches are outlined in this guide.


Note: We recommend that you now review chapters 1 to 4 in TCP/IP Network Administration. Those chapters will help you become familiar with the basic concepts and terms of TCP/IP.

QNX and TCP/IP - two different network models

The networking model used by TCP/IP differs from the inherent networking model of QNX. But as you'll see, these networking models can coexist with each other - even on the same cable.

Note that if you're familiar with traditional QNX networking, this guide will help you configure TCP/IP on your existing networks. If you're familiar with TCP/IP in other environments, this guide will help you identify those issues that are unique to the QNX implementation of TCP/IP.

QNX networking

QNX's inherent network support implements a local area network that's optimized to provide a fast, seamless interface between QNX workstations. We refer to computers connected with this form of network simply as a QNX network.


fig: ./images/qnxnet.gif


QNX workstations on a QNX network.


In a QNX network, a program can transparently access any resource - whether it's a file, a device, or a process - on any other node in the network. A program can also transparently execute on other nodes. Nevertheless, a QNX workstation can communicate only with computers that are running QNX and that are directly connected to the workstation.

For information on configuring a QNX network, see the QNX Installation & Configuration guide.

TCP/IP networking

TCP/IP can send information across multiple intermediate hops to reach its destination - TCP/IP isn't limited to local area networks. These hops can span many physical networks, wide or local area.

About hosts and gateways, clients and servers

Hosts and gateways

In TCP/IP terminology, we always refer to network-accessible computers as hosts. There's a distinction between a regular host and a special form of host called a gateway:

In general, people refer to a computer running TCP/IP software as a host, with the understanding that a gateway is equally capable of any operation that can be performed by a regular host.

The steps you need to follow to configure a computer to be a host or gateway are described in Chapter 2, Basic Configuration.

Clients and servers

There are actually two types of TCP/IP hosts: clients and servers. Simply put, a client is the host requesting a TCP/IP service; the server is the host providing that service.

As you'll see in Chapter 2, servers need to run daemon processes in order to respond to clients' requests. Therefore, it's advisable to determine during the planning stage which of your computers will provide services (servers) and which will consume those services (clients).

The next section gives some examples to help you decide on your network layout.

Planning your network

Before you start to configure your network, you should plan what you want to accomplish. In particular, you should determine:

The following examples let you see at a glance the different approaches you can take. While these examples don't imply any client or server capabilities, they do show how you could set up your site. You'll know how you should distribute your server computers once you've decided on a layout for your network.

Single QNX TCP/IP host

In the following example, there's no QNX network. You simply have a QNX TCP/IP host coexisting on the same media with other hosts that may or may not be running QNX.


fig: ./images/1qnxhost.gif


A single QNX TCP/IP host.


QNX network and TCP/IP hosts

In the following example, a QNX network and a TCP/IP network share a common Ethernet.


fig: ./images/qnettnet.gif


A QNX network and a TCP/IP network share a common Ethernet.


In this example, any workstation or terminal on the QNX network could access the TCP/IP network through the QNX workstation that's also a TCP/IP host. For example, if a workstation on the QNX network ran an rlogin to the Sun machine, the rlogin would happen transparently through the QNX host. Effectively, the entire QNX network becomes a single, logical TCP/IP host.

Multiple QNX TCP/IP hosts

In the following example, multiple QNX network nodes are acting as TCP/IP hosts. All the computers reside on the same media as the hosts that aren't running QNX.


fig: ./images/2qnxhost.gif


Multiple QNX network nodes acting as TCP/IP hosts.


You may wish to set up multiple TCP/IP hosts on the same QNX network in order to have each host provide a different service or to distribute the processing load across several hosts.

QNX gateway with separate networks

In the following example, the configuration enables a QNX host to act as a gateway between two separate TCP/IP networks.


fig: ./images/gatether.gif


A QNX host acts as a gateway between two separate Ethernet networks.


The gateway will forward IP packets from any TCP/IP host on one network to any TCP/IP host on the other network. So, for example, a Sun machine can access services on the NT machine.

With such a configuration, you'll have to assign a different subnet to each network (see TCP/IP Network Administration).

This example shows a QNX host connected to two separate networks, but note that a QNX workstation can actually support more than two networking cards.

Single QNX TCP/IP host (serial)

In the following example, a QNX TCP/IP host resides on a serial line. Except for the networking media being used, this is very similar to the ``Single QNX TCP/IP host'' example described earlier.


fig: ./images/1hostser.gif


A QNX TCP/IP host resides on a serial line.


Many people use this type of setup to gain access to a wide area TCP/IP network that they don't have any local area network access to - the Internet, for example. Many people also set up their home computers in this way so they can dial into a remote TCP/IP host with a modem - more on this in the Configuration chapters.