GNU Info

(gawkinet.info)Special File Fields

---

Next: Comparing Protocols Prev: Gawk Special Files Up: Gawk Special Files

---

Enter node , (file) or (file)node

The Fields of the Special File Name
-----------------------------------

   This node 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'.

PROTOCOL
     Determines which member of the TCP/IP family of protocols is
     selected to transport the data across the network. There are three
     possible values (always written in lowercase): `tcp', `udp', and
     `raw'. The exact meaning of each is explained later in this node.

LOCALPORT
     Determines which port on the local machine is used to communicate
     across the network. It has no meaning with `/inet/raw' and must
     therefore be `0'.  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. It has no meaning with `/inet/raw' and must
     therefore be 0.  For `/inet/tcp' and `/inet/udp', application
     level clients _must_ use a number other than `0' to indicate which
     port on the remote machine they want to connect to. Application
     level servers must not fill this field with a `0'. Instead they
     specify a local port for clients to connect to.  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 pseudo-code:

     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, the following table
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 Note: Networking With `gawk', use only the
patterns printed in bold letters.

PROTOCOL         LOCAL    HOST     REMOTE    RESULTING CONNECTION LEVEL
                 PORT     NAME     PORT      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
raw              0        x        0         Dedicated client, works
                                             only as `root'
*tcp, udp*       *x*      *x*      *x*        *Client, switches to
                                             dedicated server if
                                             necessary*
*tcp, udp*       *x*      *0*      *0*        *Dedicated server*
raw              0        0        0         Dedicated server, works
                                             only as `root'
tcp, udp, raw    x        x        0         Invalid
tcp, udp, raw    0        0        x         Invalid
tcp, udp, raw    x        0        x         Invalid
tcp, udp         0        0        0         Invalid
tcp, udp         0        x        0         Invalid
raw              x        0        0         Invalid
raw              0        x        x         Invalid
raw              x        x        x         Invalid

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