intro(3N)                        UNIX System V                        intro(3N)


NAME
      intro - introduction to networking functions and libraries

DESCRIPTION
      This section describes functions found in various networking libraries.
      Function declarations can be obtained from the #include files indicated
      on each page.  Certain major collections are identified by a letter after
      the section number:

      The networking functions are contained in three libraries:  the Netowrk
      Services library, libnsl; the Sockets Interface library, libsocket; and
      the Internet Domain Name Server library, libresolv.

      The following functions constitute the libnsl library:

           cr1    cr1 authentication library

           cs     Connection Server library interface

           des    Data Encryption Standards library

           netdir Network Directory functions.  This contains look-up functions
                   and the access point to network directory libraries for
                   various network transports.

           netselect
                   Network Selection routines.  These functions manipulate the
                   /etc/netconfig file and return entries.

           nsl    Transport Level Interface (TLI).  These functions contain the
                   implementation of X/OPEN's Transport Level Interface.

           rexec  REXEC library interface

           rpc    User-level Remote Procedure Call library

           saf    Service Access Facility library

           yp     Network Information Service functions

      The libsocket library has two components: inet, containing the Inernet
      library routines, and socket, containing the Socket Interface routines.
      The libresolv library contains the resolver routines.

      The standard networking libraries are implemented as a shared object
      (libnsl.so and libsocket.so) or archive file (libresolv.a).  To link with
      these libraries, specify the cc command line with -lnsl, -lsocket, or
      -lresolv, respectively.

DEFINITIONS
      In the Network Services library, netbuf is a structure used in various
      TLI functions to send and receive data and information.  netbuf is


10/89                                                                    Page 1

intro(3N)                        UNIX System V                        intro(3N)


      defined in sys/tiuser.h, and includes the following members:

            struct netbuf {
                  unsigned int maxlen;  /* The physical size of the buffer */
                  unsigned int len; /* The number of bytes in the buffer */
                  char *buf;  /* Points to user input and/or output buffer */
            };


      If netbuf is used for output, the function will set the user value of len
      on return.  maxlen generally has significance only when buf is used to
      receive output from the TLI function.  In this case, it specifies the
      maximum value of len that can be set by the function.  If maxlen is not
      large enough to hold the returned information, an TBUFOVFLW error will
      generally result.  However, certain functions may return part of the data
      and not generate an error.

FILES
      INCDIR                  usually /usr/include
      LIBDIR                        usually /usr/ccs/lib
      LIBDIR/libsocket.so
      LIBDIR/libnsl.so
      LIBDIR/libresolv.a

SEE ALSO
      intro(3) in the Programmer's Reference Manual

NOTES
      None of the functions, external variables, or macros should be redefined
      in the user's programs.  Any other name may be redefined without
      affecting the behavior of other library functions, but such redefinition
      may conflict with a declaration in an included header file.

      The header files in INCDIR provide function prototypes (function
      declarations including the types of arguments) for most of the functions
      listed in this manual.  Function prototypes allow the compiler to check
      for correct usage of these functions in the user's program.  The lint
      program checker may also be used and will report discrepancies even if
      the header files are not included with #include statements.  Use of lint
      is highly recommended.

      In detailed definitions of components, it is sometimes necessary to refer
      to symbolic names that are implementation-specific, but which are not
      necessarily expected to be accessible to an application program.  Many of
      these symbolic names describe boundary conditions and system limits.

      In this section, for readability, these implementation-specific values
      are given symbolic names.  These names always appear enclosed in curly
      brackets to distinguish them from symbolic names of other
      implementation-specific constants that are accessible to application
      programs by header files.  These names are not necessarily accessible to
      an application program through a header file, although they may be


Page 2                                                                    10/89

intro(3N)                        UNIX System V                        intro(3N)


      defined in the documentation for a particular system.

      In general, a portable application program should not refer to these
      symbolic names in its code.  For example, an application program would
      not be expected to test the length of an argument list given to a routine
      to determine if it was greater than {ARG_MAX}.
















































10/89                                                                    Page 3