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.

Name-to-Address Translation
As explained in Chapter 14, host names are a useful way for people to refer to hosts, but network protocols prefer to use addresses. So, as in the case of the socket interface, TLI must provide a way to translate between hosts and addresses, and port names and port numbers:
    #include <netdir.h>
    int netdir_getbyname(const struct netconfig *config,
            const struct nd_hostserv *service,
            struct nd_addrlist **addrs);
    int netdir_getbyaddr(const struct netconfig *config,
            struct nd_hostservlist **service,
            const struct netbuf *netaddr);
    int netdir_options(const struct netconfig *netconfig,
            const int opt, const int fd, char *argp);
    void netdir_free(void *ptr, const int struct_type);
    void netdir_perror(char *s);
    char *netdir_sperror(void);
Rather than treating host addresses and services (port numbers) independently as the socket interface does, TLI views them as integrated. Thus, an address is a tuple of (host address, port number).
The netdir_getbyname function looks up a host name and service name as given in the service argument, which is a pointer to type struct nd_hostserv:
    struct nd_hostserv {
        char    *h_host;
        char    *h_serv;
    };
The h_host field contains the name of the host, and the h_serv field contains the name of the service. For services that do not have names (e.g., some arbitrarily selected port number), h_serv should point to a character-string representation of the port number. The h_host element may contain some special values instead of a host name:
HOST_SELF
Represents the address by which local programs may refer to the local host. This address is not meaningful outside the local host.
HOST_ANY
Represents any host accessible by this transport provider. This is equivalent to the INADDR_ANY value in the socket interface.
HOST_SELF_CONNECT
Represents the host address that can be used to connect to the local host.
HOST_BROADCAST
Represents the address for all hosts reachable by this transport provider. Network requests to this address will be sent to all machines on the network.
The netdir_getbyname function returns a list of all valid addresses for the host and service in the addrs parameter, which points to an array of structures of type struct nd_addrlist:
    struct nd_addrlist {
        int               n_cnt;
        struct netbuf    *n_addrs;
    };
Each element of n_addrs contains one address; the n_cnt element indicates how many addresses there are.
The netdir_getbyaddr function looks up a host address and port number, as given in netaddr, and returns a list of host and service names in service, which is a pointer to an array of type struct nd_hostservlist:
    struct nd_hostservlist {
        int                    h_cnt;
        struct nd_hostserv    *h_hostservs;
    };
Both netdir_getbyname and netdir_getbyaddr return 0 on success, or non-zero on failure. If they fail, the netdir_perror and netdir_sperror functions can be used to learn why.
The memory used by these functions can be freed by calling netdir_free. The first argument is a pointer to the memory, and the second is a constant indicating the type of structure to be freed:
ND_ADDR
Free a struct netbuf structure.
ND_ADDRLIST
Free a struct nd_addrlist structure.
ND_HOSTSERV
Free a struct hostserv structure.
ND_HOSTSERVLIST
Free a struct nd_hostservlist structure.
The netdir_options function allows the programmer to set or check various options on the address he chooses. The fd parameter is the transport endpoint, defined later. The opt parameter specifies the option, which may be one of the following:
ND_SET_BROADCAST
If the transport provider supports broadcast, set the program up to send broadcast packets. The argp parameter is ignored.
ND_SET_RESERVEDPORT
If the concept of a reserved port exists for the transport provider, allow the caller to bind a reserved port. If argp is NULL, an arbitrary reserved port will be chosen. If argp points to a struct netbuf structure, an attempt will be made to bind to the reserved port it describes.
ND_CHECK_RESERVEDPORT
Checks whether or not the address contained in the struct netbuf structure pointed to by argp is on a reserved port or not.
ND_MERGEADDR
Converts a “local” address to a “real” address that may be used by other clients. The argp parameter should point to a structure of type struct nd_mergearg:
    struct nd_mergearg {
        char    *s_uaddr;
        char    *c_uaddr;
        char    *m_uaddr;
    };
The s_uaddr element should point to the server's (local machine) address, and the c_uaddr element should point to the client's (remote machine) address. After the call completes, m_uaddr will contain an address that the client can use to contact the server. (It's not really clear that this option is useful for anything, since this information is all available through other means.)
The netdir_options function returns 0 on success, non-zero on failure.
The name-to-address translation functions are part of the SVR4 TLI library, and are not available in HP-UX 10.x.
Name-to-Address Translation in HP-UX 10.x
As mentioned in the beginning of the chapter, SVR3, where TLI was first introduced, did not provide a network transport. Thus, vendors who adopted SVR3 as their base operating system had to “graft” their existing transport layers onto TLI. Most vendors did this the same way—they made use of the existing data structures and library routines provided by their socket interface (described in Chapter 14, Networking With Sockets), making only minor changes to support the differences between sockets and TLI.
As with network selection, this method of implementing things is inherently less portable. The data structures needed to deal with 32-bit TCP/IP addresses are different from those needed to deal with 160-bit ISO addresses. To make a program written for one transport provider work with another one would require some significant changes. From a practical standpoint, though, it probably doesn't matter. Almost every system that is connected to a network at all is connected to a TCP/IP network, and 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