fyi Fri, 26 March 1993 01:39 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa20148; 25 Mar 93 20:39 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20144; 25 Mar 93 20:39 EST
Received: from Sun.COM by CNRI.Reston.VA.US id aa02313; 25 Mar 93 20:39 EST
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA22861; Thu, 25 Mar 93 17:31:45 PST
Received: from sunroof2.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA04037; Thu, 25 Mar 93 17:31:53 PST
Received: from bigriver.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02222; Thu, 25 Mar 93 17:34:42 PST
Received: from hacketorium.Eng.Sun.COM by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA25842; Thu, 25 Mar 93 17:31:27 PST
Received: by hacketorium.Eng.Sun.COM (5.0/SMI-SVR4) id AA03720; Thu, 25 Mar 93 17:31:48 PST
Date: Thu, 25 Mar 93 17:31:48 PST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
Message-Id: <9303260131.AA03720@hacketorium.Eng.Sun.COM>
Subject: fyi
Content-Length: 6316

From: Keith Sklower <sklower@vangogh.CS.Berkeley.EDU>
Subject: some thoughts about a gethostbyname replacement
Date: Thu, 25 Mar 1993 16:50:55 -0800

Eric Allman and I were discussing this, and we have a very preliminary
design.  We **think** the following does everything we want,
and I've put together an extremely drafty manual page.
Nothing about this interface is cast in stone . . .
(and probably a whole lot has been left unsaid, but it's been a long day).

GETCONNINFO(3)              BSD Programmer's Manual             GETCONNINFO(3)

     getconninfo, freeconninfo - get parameters to exploit or offer service

     #include <conninfo.h>

     struct conninfo *
     getconninfo(char *host, char *service, struct conninfo *in_or_old);

     freeconninfo(struct conninfo *nuked);

     If an application makes use of or offers a service over a network, that
     is commonly specified by a pair of identifiers, one describing the  loca-
     tion or system, and the other specifying the service.  The getconninfo()
     function returns a pointer to a link list of objects with the following
     structure describing a host referenced by name or by address, respective-
     ly.  This structure contains either the information obtained from the
     name server, named(8),  and/or broken-out fields from a line in
     /etc/hosts, and /etc/services. If the local name server is not running
     these routines do a lookup in those static files and possibly others.

     The ``in_or_old'' parameter may be ommitted, in which case all possible
     matches in all address families are returned; or it may be used to limit
     the queries to return a prespecified set of protocols, with or without

     The ``host'' parameter may be null or "", meaning allow connections on
     any interface in the case of active open or connect to the local host on
     active opens.  This currently works for all implementations.  For future
     protocols where this cannot be made to work, extensions could be either
     permitting "*passive*" for the host name in the passive case, or requir-
     ing a flag on a supplied third parameter (chain).

     struct conninfo {
             int     ci_flags;
     #define CI_NOALIAS      0x01    /* no mx agents, or aliases */
     #define CI_THISAF       0x02    /* only retrieve in this AF */
     #define CI_THISTYPE     0x04    /* only retrieve this socktype */
     #define CI_THISPROTO    0x08    /* only retrieve this proto */
     #define CI_REUSE        0x10    /* overwrite this entry */
     #define CI_DYNADDR      0x20    /* can free or re-malloc sockaddr */
     #define CI_DYNSTRUCT    0x40    /* can free or re-malloc this struct */
     #define CI_PASSIVE      0x80    /* intended for bind() + listen() */
     #define CI_CANONICAL    0x100   /* request canonical version of name */
             int     ci_af;
             int     ci_socktype;
             int     ci_proto;
             int     ci_namelen;
             char    *ci_canon;
             struct  sockaddr *ci_name;
             struct  conninfo *ci_next;

     The members of this structure are:

     ci_flags           This modifies the behavior of getconninfo in ways de-
                        scribed above();

     ci_af              The type of address being returned; currently always


     ci_socktype        The socket type required as the second argument in a
                        call to socket(2).

     ci_proto           The specific protocol required as the third argument
                        in a call to socket(2).

     ci_name            The binary address, suitable for use as an argument to
                        connect() or bind().

     ci_namelen         The length, in bytes, of the address.

     ci_canon           The canonical name for the host.  (Supplied by
                        getconninfo(), and only on specific request).

     When using the nameserver, getconninfo() will search for the named host
     in the current domain and its parents unless the name ends in a dot.  If
     the name contains no dot, and if the environment variable ``HOSTALIASES''
     contains the name of an alias file, the alias file will first be searched
     for an alias matching the input name.  See hostname(7) for the domain
     search procedure and the alias file format.  getconninfo() will also
     translate hosts specified in internet dotted-quad notation according to
     the syntax ``[a.b.c.d]'', and will accept ascii renditions of integers
     for service names, eg. ``6''.


     Error return status from getconninfo() is indicated by return of a null
     pointer.  h_errno may then be checked to see whether this is a temporary
     failure or an invalid or unknown host.  The routine herror() can be used
     to print an error message describing the failure.  If its argument string
     is non-NULL, it is printed, followed by a colon and a space.  The error
     message is printed with a trailing newline.

     The variable h_errno can have the following values:

     HOST_NOT_FOUND  No such host is known.

     TRY_AGAIN       This is usually a temporary error and means that the lo-
                     cal server did not receive a response from an authorita-
                     tive server.  A retry at some later time may succeed.

     NO_RECOVERY     Some unexpected server failure was encountered.  This is
                     a non-recoverable error.

     NO_DATA         The requested name is valid but does not have an IP ad-
                     dress; this is not a temporary error.  This means that
                     the name is known to the name server but there is no ad-
                     dress associated with this name.  Another type of request
                     to the name server using this domain name will result in
                     an answer; for example, a mail-forwarder may be regis-
                     tered for this domain.

     resolver(3),  hosts(5),  hostname(7),  named(8)

4.4BSD                          March 25, 1993                               2

------- End of forwarded message -------
  • fyi  Tom.Kessler