diff options
Diffstat (limited to 'contrib/bind9/lib/lwres/man/lwres.html')
| -rw-r--r-- | contrib/bind9/lib/lwres/man/lwres.html | 332 |
1 files changed, 167 insertions, 165 deletions
diff --git a/contrib/bind9/lib/lwres/man/lwres.html b/contrib/bind9/lib/lwres/man/lwres.html index 02af1f7..e4bbc09 100644 --- a/contrib/bind9/lib/lwres/man/lwres.html +++ b/contrib/bind9/lib/lwres/man/lwres.html @@ -1,5 +1,5 @@ <!-- - - Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC") + - Copyright (C) 2004, 2005, 2007 Internet Systems Consortium, Inc. ("ISC") - Copyright (C) 2000, 2001 Internet Software Consortium. - - Permission to use, copy, modify, and distribute this software for any @@ -14,15 +14,15 @@ - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - PERFORMANCE OF THIS SOFTWARE. --> -<!-- $Id: lwres.html,v 1.4.2.1.4.12 2006/06/29 13:02:31 marka Exp $ --> +<!-- $Id: lwres.html,v 1.5.18.18 2007/01/30 00:23:45 marka Exp $ --> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <title>lwres</title> -<meta name="generator" content="DocBook XSL Stylesheets V1.70.1"> +<meta name="generator" content="DocBook XSL Stylesheets V1.71.1"> </head> <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en"> -<a name="id2482688"></a><div class="titlepage"></div> +<a name="id2476275"></a><div class="titlepage"></div> <div class="refnamediv"> <h2>Name</h2> <p>lwres — introduction to the lightweight resolver library</p> @@ -32,185 +32,187 @@ <div class="funcsynopsis"><pre class="funcsynopsisinfo">#include <lwres/lwres.h></pre></div> </div> <div class="refsect1" lang="en"> -<a name="id2549397"></a><h2>DESCRIPTION</h2> -<p> -The BIND 9 lightweight resolver library is a simple, name service -independent stub resolver library. It provides hostname-to-address -and address-to-hostname lookup services to applications by -transmitting lookup requests to a resolver daemon -<span><strong class="command">lwresd</strong></span> -running on the local host. The resover daemon performs the -lookup using the DNS or possibly other name service protocols, -and returns the results to the application through the library. -The library and resolver daemon communicate using a simple -UDP-based protocol. -</p> +<a name="id2543348"></a><h2>DESCRIPTION</h2> +<p> + The BIND 9 lightweight resolver library is a simple, name service + independent stub resolver library. It provides hostname-to-address + and address-to-hostname lookup services to applications by + transmitting lookup requests to a resolver daemon + <span><strong class="command">lwresd</strong></span> + running on the local host. The resover daemon performs the + lookup using the DNS or possibly other name service protocols, + and returns the results to the application through the library. + The library and resolver daemon communicate using a simple + UDP-based protocol. + </p> </div> <div class="refsect1" lang="en"> -<a name="id2549410"></a><h2>OVERVIEW</h2> -<p> -The lwresd library implements multiple name service APIs. -The standard -<code class="function">gethostbyname()</code>, -<code class="function">gethostbyaddr()</code>, -<code class="function">gethostbyname_r()</code>, -<code class="function">gethostbyaddr_r()</code>, -<code class="function">getaddrinfo()</code>, -<code class="function">getipnodebyname()</code>, -and -<code class="function">getipnodebyaddr()</code> -functions are all supported. To allow the lwres library to coexist -with system libraries that define functions of the same name, -the library defines these functions with names prefixed by -<code class="literal">lwres_</code>. -To define the standard names, applications must include the -header file -<code class="filename"><lwres/netdb.h></code> -which contains macro definitions mapping the standard function names -into -<code class="literal">lwres_</code> -prefixed ones. Operating system vendors who integrate the lwres -library into their base distributions should rename the functions -in the library proper so that the renaming macros are not needed. -</p> -<p> -The library also provides a native API consisting of the functions -<code class="function">lwres_getaddrsbyname()</code> -and -<code class="function">lwres_getnamebyaddr()</code>. -These may be called by applications that require more detailed -control over the lookup process than the standard functions -provide. -</p> -<p> -In addition to these name service independent address lookup -functions, the library implements a new, experimental API -for looking up arbitrary DNS resource records, using the -<code class="function">lwres_getaddrsbyname()</code> -function. -</p> -<p> -Finally, there is a low-level API for converting lookup -requests and responses to and from raw lwres protocol packets. -This API can be used by clients requiring nonblocking operation, -and is also used when implementing the server side of the lwres -protocol, for example in the -<span><strong class="command">lwresd</strong></span> -resolver daemon. The use of this low-level API in clients -and servers is outlined in the following sections. -</p> +<a name="id2543361"></a><h2>OVERVIEW</h2> +<p> + The lwresd library implements multiple name service APIs. + The standard + <code class="function">gethostbyname()</code>, + <code class="function">gethostbyaddr()</code>, + <code class="function">gethostbyname_r()</code>, + <code class="function">gethostbyaddr_r()</code>, + <code class="function">getaddrinfo()</code>, + <code class="function">getipnodebyname()</code>, + and + <code class="function">getipnodebyaddr()</code> + functions are all supported. To allow the lwres library to coexist + with system libraries that define functions of the same name, + the library defines these functions with names prefixed by + <code class="literal">lwres_</code>. + To define the standard names, applications must include the + header file + <code class="filename"><lwres/netdb.h></code> + which contains macro definitions mapping the standard function names + into + <code class="literal">lwres_</code> + prefixed ones. Operating system vendors who integrate the lwres + library into their base distributions should rename the functions + in the library proper so that the renaming macros are not needed. + </p> +<p> + The library also provides a native API consisting of the functions + <code class="function">lwres_getaddrsbyname()</code> + and + <code class="function">lwres_getnamebyaddr()</code>. + These may be called by applications that require more detailed + control over the lookup process than the standard functions + provide. + </p> +<p> + In addition to these name service independent address lookup + functions, the library implements a new, experimental API + for looking up arbitrary DNS resource records, using the + <code class="function">lwres_getaddrsbyname()</code> + function. + </p> +<p> + Finally, there is a low-level API for converting lookup + requests and responses to and from raw lwres protocol packets. + This API can be used by clients requiring nonblocking operation, + and is also used when implementing the server side of the lwres + protocol, for example in the + <span><strong class="command">lwresd</strong></span> + resolver daemon. The use of this low-level API in clients + and servers is outlined in the following sections. + </p> </div> <div class="refsect1" lang="en"> -<a name="id2549474"></a><h2>CLIENT-SIDE LOW-LEVEL API CALL FLOW</h2> -<p> -When a client program wishes to make an lwres request using the -native low-level API, it typically performs the following -sequence of actions. -</p> -<p> -(1) Allocate or use an existing <span class="type">lwres_packet_t</span>, -called <code class="varname">pkt</code> below. -</p> -<p> -(2) Set <em class="structfield"><code>pkt.recvlength</code></em> to the maximum length we will accept. -This is done so the receiver of our packets knows how large our receive -buffer is. The "default" is a constant in -<code class="filename">lwres.h</code>: <code class="constant">LWRES_RECVLENGTH = 4096</code>. -</p> -<p> -(3) Set <em class="structfield"><code>pkt.serial</code></em> -to a unique serial number. This value is echoed -back to the application by the remote server. -</p> -<p> -(4) Set <em class="structfield"><code>pkt.pktflags</code></em>. Usually this is set to 0. -</p> -<p> -(5) Set <em class="structfield"><code>pkt.result</code></em> to 0. -</p> -<p> -(6) Call <code class="function">lwres_*request_render()</code>, -or marshall in the data using the primitives -such as <code class="function">lwres_packet_render()</code> -and storing the packet data. -</p> -<p> -(7) Transmit the resulting buffer. -</p> -<p> -(8) Call <code class="function">lwres_*response_parse()</code> -to parse any packets received. -</p> -<p> -(9) Verify that the opcode and serial match a request, and process the -packet specific information contained in the body. -</p> +<a name="id2543425"></a><h2>CLIENT-SIDE LOW-LEVEL API CALL FLOW</h2> +<p> + When a client program wishes to make an lwres request using the + native low-level API, it typically performs the following + sequence of actions. + </p> +<p> + (1) Allocate or use an existing <span class="type">lwres_packet_t</span>, + called <code class="varname">pkt</code> below. + </p> +<p> + (2) Set <em class="structfield"><code>pkt.recvlength</code></em> to the maximum length + we will accept. + This is done so the receiver of our packets knows how large our receive + buffer is. The "default" is a constant in + <code class="filename">lwres.h</code>: <code class="constant">LWRES_RECVLENGTH = 4096</code>. + </p> +<p> + (3) Set <em class="structfield"><code>pkt.serial</code></em> + to a unique serial number. This value is echoed + back to the application by the remote server. + </p> +<p> + (4) Set <em class="structfield"><code>pkt.pktflags</code></em>. Usually this is set to + 0. + </p> +<p> + (5) Set <em class="structfield"><code>pkt.result</code></em> to 0. + </p> +<p> + (6) Call <code class="function">lwres_*request_render()</code>, + or marshall in the data using the primitives + such as <code class="function">lwres_packet_render()</code> + and storing the packet data. + </p> +<p> + (7) Transmit the resulting buffer. + </p> +<p> + (8) Call <code class="function">lwres_*response_parse()</code> + to parse any packets received. + </p> +<p> + (9) Verify that the opcode and serial match a request, and process the + packet specific information contained in the body. + </p> </div> <div class="refsect1" lang="en"> -<a name="id2549689"></a><h2>SERVER-SIDE LOW-LEVEL API CALL FLOW</h2> -<p> -When implementing the server side of the lightweight resolver -protocol using the lwres library, a sequence of actions like the -following is typically involved in processing each request packet. -</p> -<p> -Note that the same <span class="type">lwres_packet_t</span> is used -in both the <code class="function">_parse()</code> and <code class="function">_render()</code> calls, -with only a few modifications made -to the packet header's contents between uses. This method is recommended -as it keeps the serial, opcode, and other fields correct. -</p> -<p> -(1) When a packet is received, call <code class="function">lwres_*request_parse()</code> to -unmarshall it. This returns a <span class="type">lwres_packet_t</span> (also called <code class="varname">pkt</code>, below) -as well as a data specific type, such as <span class="type">lwres_gabnrequest_t</span>. -</p> -<p> -(2) Process the request in the data specific type. -</p> -<p> -(3) Set the <em class="structfield"><code>pkt.result</code></em>, -<em class="structfield"><code>pkt.recvlength</code></em> as above. All other fields can -be left untouched since they were filled in by the <code class="function">*_parse()</code> call -above. If using <code class="function">lwres_*response_render()</code>, -<em class="structfield"><code>pkt.pktflags</code></em> will be set up -properly. Otherwise, the <code class="constant">LWRES_LWPACKETFLAG_RESPONSE</code> bit should be -set. -</p> -<p> -(4) Call the data specific rendering function, such as -<code class="function">lwres_gabnresponse_render()</code>. -</p> -<p> -(5) Send the resulting packet to the client. -</p> -<p> -</p> +<a name="id2543573"></a><h2>SERVER-SIDE LOW-LEVEL API CALL FLOW</h2> +<p> + When implementing the server side of the lightweight resolver + protocol using the lwres library, a sequence of actions like the + following is typically involved in processing each request packet. + </p> +<p> + Note that the same <span class="type">lwres_packet_t</span> is used + in both the <code class="function">_parse()</code> and <code class="function">_render()</code> calls, + with only a few modifications made + to the packet header's contents between uses. This method is + recommended + as it keeps the serial, opcode, and other fields correct. + </p> +<p> + (1) When a packet is received, call <code class="function">lwres_*request_parse()</code> to + unmarshall it. This returns a <span class="type">lwres_packet_t</span> (also called <code class="varname">pkt</code>, below) + as well as a data specific type, such as <span class="type">lwres_gabnrequest_t</span>. + </p> +<p> + (2) Process the request in the data specific type. + </p> +<p> + (3) Set the <em class="structfield"><code>pkt.result</code></em>, + <em class="structfield"><code>pkt.recvlength</code></em> as above. All other fields + can + be left untouched since they were filled in by the <code class="function">*_parse()</code> call + above. If using <code class="function">lwres_*response_render()</code>, + <em class="structfield"><code>pkt.pktflags</code></em> will be set up + properly. Otherwise, the <code class="constant">LWRES_LWPACKETFLAG_RESPONSE</code> bit should be + set. + </p> +<p> + (4) Call the data specific rendering function, such as + <code class="function">lwres_gabnresponse_render()</code>. + </p> +<p> + (5) Send the resulting packet to the client. + </p> +<p></p> </div> <div class="refsect1" lang="en"> -<a name="id2549774"></a><h2>SEE ALSO</h2> -<p> -<span class="citerefentry"><span class="refentrytitle">lwres_gethostent</span>(3)</span>, +<a name="id2543656"></a><h2>SEE ALSO</h2> +<p><span class="citerefentry"><span class="refentrytitle">lwres_gethostent</span>(3)</span>, -<span class="citerefentry"><span class="refentrytitle">lwres_getipnode</span>(3)</span>, + <span class="citerefentry"><span class="refentrytitle">lwres_getipnode</span>(3)</span>, -<span class="citerefentry"><span class="refentrytitle">lwres_getnameinfo</span>(3)</span>, + <span class="citerefentry"><span class="refentrytitle">lwres_getnameinfo</span>(3)</span>, -<span class="citerefentry"><span class="refentrytitle">lwres_noop</span>(3)</span>, + <span class="citerefentry"><span class="refentrytitle">lwres_noop</span>(3)</span>, -<span class="citerefentry"><span class="refentrytitle">lwres_gabn</span>(3)</span>, + <span class="citerefentry"><span class="refentrytitle">lwres_gabn</span>(3)</span>, -<span class="citerefentry"><span class="refentrytitle">lwres_gnba</span>(3)</span>, + <span class="citerefentry"><span class="refentrytitle">lwres_gnba</span>(3)</span>, -<span class="citerefentry"><span class="refentrytitle">lwres_context</span>(3)</span>, + <span class="citerefentry"><span class="refentrytitle">lwres_context</span>(3)</span>, -<span class="citerefentry"><span class="refentrytitle">lwres_config</span>(3)</span>, + <span class="citerefentry"><span class="refentrytitle">lwres_config</span>(3)</span>, -<span class="citerefentry"><span class="refentrytitle">resolver</span>(5)</span>, + <span class="citerefentry"><span class="refentrytitle">resolver</span>(5)</span>, -<span class="citerefentry"><span class="refentrytitle">lwresd</span>(8)</span>. + <span class="citerefentry"><span class="refentrytitle">lwresd</span>(8)</span>. -</p> + </p> </div> </div></body> </html> |
