diff options
| author | Martin Nagy <mnagy@redhat.com> | 2009-02-11 20:37:59 +0100 |
|---|---|---|
| committer | Martin Nagy <mnagy@redhat.com> | 2009-02-11 20:37:59 +0100 |
| commit | f50ae72ec3417cae55dd4e085991c01af9fdc5f1 (patch) | |
| tree | 0e36c9a3320f6d068df93d3ff6d84b821d23db40 /lib/lwres/man/lwres.html | |
| download | bind_dynamic-f50ae72ec3417cae55dd4e085991c01af9fdc5f1.tar.gz bind_dynamic-f50ae72ec3417cae55dd4e085991c01af9fdc5f1.tar.xz bind_dynamic-f50ae72ec3417cae55dd4e085991c01af9fdc5f1.zip | |
Initial commitstart
Diffstat (limited to 'lib/lwres/man/lwres.html')
| -rw-r--r-- | lib/lwres/man/lwres.html | 218 |
1 files changed, 218 insertions, 0 deletions
diff --git a/lib/lwres/man/lwres.html b/lib/lwres/man/lwres.html new file mode 100644 index 0000000..70d7856 --- /dev/null +++ b/lib/lwres/man/lwres.html @@ -0,0 +1,218 @@ +<!-- + - 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 + - purpose with or without fee is hereby granted, provided that the above + - copyright notice and this permission notice appear in all copies. + - + - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH + - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY + - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, + - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM + - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE + - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR + - PERFORMANCE OF THIS SOFTWARE. +--> +<!-- $Id: lwres.html,v 1.23 2007/01/30 00:24:59 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.71.1"> +</head> +<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en"> +<a name="id2476275"></a><div class="titlepage"></div> +<div class="refnamediv"> +<h2>Name</h2> +<p>lwres — introduction to the lightweight resolver library</p> +</div> +<div class="refsynopsisdiv"> +<h2>Synopsis</h2> +<div class="funcsynopsis"><pre class="funcsynopsisinfo">#include <lwres/lwres.h></pre></div> +</div> +<div class="refsect1" lang="en"> +<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="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="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="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="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_getnameinfo</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_gnba</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">resolver</span>(5)</span>, + + <span class="citerefentry"><span class="refentrytitle">lwresd</span>(8)</span>. + + </p> +</div> +</div></body> +</html> |