Add Book to My BookshelfPurchase This Book Online

Chapter 15 - Networking with TLI

UNIX Systems Programming for SVR4
David A. Curry
 Copyright © 1996 O'Reilly & Associates, Inc.

Network Selection
The advantage of the TLI is its ability to work, without changes, over different transport providers (network protocols). For example, a program that requires a virtual circuit connection doesn't really care if this connection is made via TCP/IP or ISO/OSI, as long as it can get the job done. When a programmer writes a program with sockets, he must decide which protocol he wants to use, and write the program accordingly. When a programmer writes a program with TLI, however, she only has to decide what type of service she wants—virtual circuit, datagram, etc. The program will work on any system that provides a transport provider (any transport provider) that offers that type of service. (Obviously, for processes on two machines to communicate, both machines must speak the same networking protocol.)
The network selection function in TLI is driven by the /etc/netconfig file:
#
# NetID   Semantics    Flags Proto  Proto Network        Directory Lookup
#                            Family  Name Device         Libraries
#
udp       tpi_clts      v   inet     udp  /dev/udp       switch.so,tcpip.so
tcp       tpi_cots_ord  v   inet     tcp  /dev/tcp       switch.so,tcpip.so
rawip     tpi_raw       -   inet     -    /dev/rawip     switch.so,tcpip.so
ticlts    tpi_clts      v   loopback -    /dev/ticlts    straddr.so
ticotsord tpi_cots_ord  v   loopback -    /dev/ticotsord straddr.so
ticots    tpi_cots      v   loopback -    /dev/ticots    straddr.so
This file contains one entry for every network protocol installed on the system. Each entry has seven fields: the first field is a unique name for the network. The second field, called the network “semantics,” describes the type of service provided by the network. There are currently four legal values for this field:
tpi_clts
Connectionless Transport Service (datagrams).
tpi_cots
Connection-Oriented Transport Service (virtual circuits).
tpi_cots_ord
Connection-Oriented Transport Service with Orderly Release. This differs from tpi_cots in what happens when a connection is terminated. If the transport provider discards any outstanding data (data that has been sent by the local end but not yet delivered over the network to the remote end), it is said to have abortive release. If, on the other hand, the transport provider reliably delivers any outstanding data to the other side before tearing down the connection, it is said to have an orderly release.
tpi_raw
A “raw” (low-level) interface to the networking protocols.
The next field in the entry is a flags word; the only flag currently defined is v, which indicates that the entry is visible to the NETPATH routines, described below. A dash may be used to make a network temporarily (or permanently) invisible to these routines.
The fourth field describes a name for the protocol family; all the Internet protocols, for example, are grouped under the name “inet.” The fifth field specifies the name of the protocol itself; a dash may be used if the protocol has no name.
The sixth field provides the pathname of the device to use when accessing the network and the protocol. The last field is a comma-separated list of shared libraries that contain the network protocol's name-to-address translation functions.
There are two sets of functions for reading the /etc/netconfig file, described in the following sections. Both of them use a struct netconfig structure to describe an entry:
    #include <netconfig.h>
    struct netconfig {
        char              *nc_netid;
        unsigned long      nc_semantics;
        unsigned long      nc_flag;
        char              *nc_protofmly;
        char              *nc_proto;
        char              *nc_device;
        unsigned long      nc_nlookups;
        char             **nc_lookups;
    };
The nc_netid, nc_protofmly, nc_proto, and nc_device elements of the structure contain the network identifier, protocol family, protocol name, and network device name, as described above. The nc_lookups element contains the names of the name-to-address translation libraries; nc_nlookups indicates how many of these there are. The nc_semantics field of the structure contains one of NC_TPI_CLTS, NC_TPI_COTS, NC_TPI_COTS_ORD, or NC_TPI_RAW, as described above. The nc_flag element will contain either NC_NOFLAG or NC_VISIBLE.
The network selection functions described in the following two sections are part of the SVR4 TLI implementation, and are not provided in HP-UX 10.x.
The Network Configuration Library
The simplest way to read the /etc/netconfig file is one entry at a time, or by looking for a specific entry by its network identifier. The functions to do this are contained in the network configuration library:
    #include <netconfig.h>
    void *setnetconfig(void);
    int endnetconfig(void *handlep);
    struct netconfig *getnetconfig(void *handlep);
    struct netconfig *getnetconfigent(const char *netid);
    void freenetconfigent(struct netconfig *netconfigp);
    void nc_perror(const char *msg);
    char *nc_sperror(void);
The setnetconfig function opens or rewinds the /etc/netconfig file. It returns a pointer to a “handle” that must be used with some of the other functions. The setnetconfig function must be called before any calls to getnetconfig, but it does not have to be called before getnetconfigent. The endnetconfig function closes the network configuration database; handlep should contain the value returned by a call to setnetconfig.
The getnetconfig function takes a single argument, handlep, which should have the value returned from a call to setnetconfig. It returns the next entry in the network configuration database, or NULL when there are no more entries to read. The getnetconfigent function returns the entry whose network identifier is equal to netid, or NULL if no entry is found.
The memory returned by getnetconfig and getnetconfigent is dynamically allocated. The freenetconfigent function can be called to free this memory. Note that a call to endnetconfig will also free the memory allocated by any calls to these functions; care should be taken not to call it before the program is finished with this information.
The nc_perror function can be called when an error is returned by one of the other functions in the library; it prints the string contained in msg on the standard error output, followed by an error message describing the error that occurred. The nc_sperror function returns the error message string rather than printing it.
To make a TLI program portable, call getnetconfig repeatedly looking for any network with the desired semantics. For example, a datagram application might call it as follows:
    void *handlep;
    struct netconfig *ncp;
    handlep = setnetconfig();
    while ((ncp = getnetconfig(handlep)) != NULL) {
        if (ncp->nc_semantics == NC_TPI_CLTS)
            break;
    }
    if (ncp == NULL) {
        fprintf(stderr, "cannot find acceptable transport provider.\n");
        exit(1);
    }
    /* use the network described by ncp */
A program that uses getnetconfigent, on the other hand, is by definition not portable across different transport providers, since it is requesting a specific transport provider.
The NETPATH Library
The NETPATH library provides an alternate way to read the /etc/netconfig file; this method gives the user some control over the networks chosen. To do this, the user sets the NETPATH environment variable to a colon-separated list of network identifiers in the order of preference. For example, if a user prefers TCP over ISO TP4, but prefers ISO TP0 over UDP, she would set her NETPATH environment variable as follows:
    NETPATH=tcp:iso_tp4:iso_tp0:udp
There are three functions in the NETPATH library:
    #include <netconfig.h>
    void *setnetpath(void);
    int endnetpath(void *handlep);
    struct netconfig *getnetpath(void *handlep);
The setnetpath function opens or rewinds the /etc/netconfig file, and returns a pointer to a “handle” describing the file. It must be called before any calls to getnetpath. The endnetpath function closes the file and releases all allocated resources returned by the routines.
The getnetpath function reads the network configuration file described by handlep, which should be the value returned by a call to setnetpath. However, rather than reading the file sequentially, getnetpath returns the entry for the next valid network identifier contained in the NETPATH environment variable. Thus, regardless of the order in which the networks are listed in the file, getnetpath will always return them in the order given by the environment variable. getnetpath silently ignores invalid or nonexistent network identifiers contained in NETPATH, and returns NULL when it runs out of NETPATH entries.
If the NETPATH variable is not set, then getnetpath returns the list of “default” networks; these are the networks listed as “visible” in the network configuration file. The networks will be returned in the order listed.
The use of the getnetpath function is essentially the same as that described above for getnetconfig: the program calls getnetpath repeatedly until it finds a network with the semantics it wants. However, by ordering the values in the NETPATH environment variable, the user can exert some control over which network is chosen when more than one network with the same semantics exists.
Network Selection in HP-UX 10.x
Network transport selection in HP-UX 10.x is performed at compile time, rather than at run time. There is no library of functions to let the programmer choose a network based on type of service requirements; the programmer has to know exactly what she wants and code the name of the network device directly into her program. Thus, a program that is written to use TCP as its connection-oriented transport service would have to be modified to use ISO TP4 instead.
From a technical standpoint, the solution offered by SVR4 is a better one—it is more portable, and can be moved between systems with different networking services with no modifications. From a practical standpoint, however, it probably doesn't matter. Almost every system that is connected to a network at all is connected to a TCP/IP network; thus the program is portable “by default.” For those programs that use some other network transport, it's doubtful that they are intended to be portable outside their own local environment anyway.

Previous SectionNext Section
Books24x7.com, Inc © 2000 –  Feedback