fyi
Tom.Kessler@eng.sun.com Fri, 26 March 1993 01:39 UTC
Received: from ietf.nri.reston.va.us 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 1993 17:31:48 -0800
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tom.Kessler@eng.sun.com
Message-Id: <9303260131.AA03720@hacketorium.Eng.Sun.COM>
To: ip-encaps@sunroof.eng.sun.com
Subject: fyi
Content-Length: 6316
From: Keith Sklower <sklower@vangogh.CS.Berkeley.EDU> To: tuba@lanl.gov 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) NAME getconninfo, freeconninfo - get parameters to exploit or offer service SYNOPSIS #include <conninfo.h> struct conninfo * getconninfo(char *host, char *service, struct conninfo *in_or_old); void freeconninfo(struct conninfo *nuked); DESCRIPTION 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 aliasing. 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 AF_INET. 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''. FILES /etc/hosts /etc/services DIAGNOSTICS 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. SEE ALSO resolver(3), hosts(5), hostname(7), named(8) 4.4BSD March 25, 1993 2 ------- End of forwarded message -------
- fyi Tom.Kessler