2.1.1 The Fields of the Special File Name

This section explains the meaning of all the other fields,
as well as the range of values and the defaults.
All of the fields are mandatory. To let the system pick a value,
or if the field doesn’t apply to the protocol, specify it as ‘0’:

net-type

This is one of ‘inet4’ for IPv4, ‘inet6’ for IPv6,
or ‘inet’ to use the system default (which is likely to be IPv4).
For the rest of this document, we will use the generic ‘/inet’
in our descriptions of how gawk’s networking works.

protocol

Determines which member of the TCP/IP
family of protocols is selected to transport the data across the
network. There are two possible values (always written in lowercase):
‘tcp’ and ‘udp’. The exact meaning of each is
explained later in this section.

localport

Determines which port on the local
machine is used to communicate across the network. Application-level clients
usually use ‘0’ to indicate they do not care which local port is
used—instead they specify a remote port to connect to. It is vital for
application-level servers to use a number different from ‘0’ here
because their service has to be available at a specific publicly known
port number. It is possible to use a name from /etc/services here.

hostname

Determines which remote host is to
be at the other end of the connection. Application-level servers must fill
this field with a ‘0’ to indicate their being open for all other hosts
to connect to them and enforce connection level server behavior this way.
It is not possible for an application-level server to restrict its
availability to one remote host by entering a host name here.
Application-level clients must enter a name different from ‘0’.
The name can be either symbolic
(e.g., ‘jpl-devvax.jpl.nasa.gov’) or numeric (e.g., ‘128.149.1.143’).

remoteport

Determines which port on the remote
machine is used to communicate across the network.
For /inet/tcp and /inet/udp,
application-level clients must use a number
other than ‘0’ to indicate to which port on the remote machine
they want to connect. Application-level servers must not fill this field with
a ‘0’. Instead they specify a local port to which clients connect.
It is possible to use a name from /etc/services here.

Experts in network programming will notice that the usual
client/server asymmetry found at the level of the socket API is not visible
here. This is for the sake of simplicity of the high-level concept. If this
asymmetry is necessary for your application,
use another language.
For gawk, it is
more important to enable users to write a client program with a minimum
of code. What happens when first accessing a network connection is seen
in the following pseudocode:

if ((name of remote host given) && (other side accepts connection)) {
rendez-vous successful; transmit with getline or print
} else {
if ((other side did not accept) && (localport == 0))
exit unsuccessful
if (TCP) {
set up a server accepting connections
this means waiting for the client on the other side to connect
} else
ready
}

The exact behavior of this algorithm depends on the values of the
fields of the special file name. When in doubt, Table 2.1
gives you the combinations of values and their meaning. If this
table is too complicated, focus on the three lines printed in
bold. All the examples in
Networking With gawk,
use only the
patterns printed in bold letters.

PROTOCOL

LOCAL PORT

HOST NAME

REMOTE PORT

RESULTING CONNECTION-LEVEL BEHAVIOR

tcp

0

x

x

Dedicated client, fails if immediately connecting to a
server on the other side fails

udp

0

x

x

Dedicated client

tcp, udp

x

x

x

Client, switches to dedicated server if necessary

tcp, udp

x

0

0

Dedicated server

tcp, udp

x

x

0

Invalid

tcp, udp

0

0

x

Invalid

tcp, udp

x

0

x

Invalid

tcp, udp

0

0

0

Invalid

tcp, udp

0

x

0

Invalid

Table 2.1: /inet Special File Components

In general, TCP is the preferred mechanism to use. It is the simplest
protocol to understand and to use. Use UDP only if circumstances
demand low-overhead.