aboutsummaryrefslogtreecommitdiffstats
path: root/lib/liblwres/man/lwres.3
diff options
context:
space:
mode:
authorMartin Willi <martin@strongswan.org>2006-04-28 07:14:48 +0000
committerMartin Willi <martin@strongswan.org>2006-04-28 07:14:48 +0000
commit997358a6c475c8886cce388ab325184a1ff733c9 (patch)
tree27a15790e030fc186d00cd710d2a3540f4defe69 /lib/liblwres/man/lwres.3
parent52923c9acb349adec3d1cc039e7a74c2e822da6e (diff)
downloadstrongswan-997358a6c475c8886cce388ab325184a1ff733c9.tar.bz2
strongswan-997358a6c475c8886cce388ab325184a1ff733c9.tar.xz
- import of strongswan-2.7.0
- applied patch for charon
Diffstat (limited to 'lib/liblwres/man/lwres.3')
-rw-r--r--lib/liblwres/man/lwres.3158
1 files changed, 158 insertions, 0 deletions
diff --git a/lib/liblwres/man/lwres.3 b/lib/liblwres/man/lwres.3
new file mode 100644
index 000000000..f2393912d
--- /dev/null
+++ b/lib/liblwres/man/lwres.3
@@ -0,0 +1,158 @@
+.\"
+.\" 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 INTERNET SOFTWARE CONSORTIUM
+.\" DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL
+.\" INTERNET SOFTWARE CONSORTIUM 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.
+.\"
+.TH "LWRES" "3" "Jun 30, 2000" "BIND9" ""
+.SH NAME
+lwres \- introduction to the lightweight resolver library
+.SH SYNOPSIS
+\fB#include <lwres/lwres.h>\fR
+.SH "DESCRIPTION"
+.PP
+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
+\fBlwresd\fR
+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.
+.SH "OVERVIEW"
+.PP
+The lwresd library implements multiple name service APIs.
+The standard
+\fBgethostbyname()\fR,
+\fBgethostbyaddr()\fR,
+\fBgethostbyname_r()\fR,
+\fBgethostbyaddr_r()\fR,
+\fBgetaddrinfo()\fR,
+\fBgetipnodebyname()\fR,
+and
+\fBgetipnodebyaddr()\fR
+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
+lwres_.
+To define the standard names, applications must include the
+header file
+\fI<lwres/netdb.h>\fR
+which contains macro definitions mapping the standard function names
+into
+lwres_
+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.
+.PP
+The library also provides a native API consisting of the functions
+\fBlwres_getaddrsbyname()\fR
+and
+\fBlwres_getnamebyaddr()\fR.
+These may be called by applications that require more detailed
+control over the lookup process than the standard functions
+provide.
+.PP
+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
+\fBlwres_getaddrsbyname()\fR
+function.
+.PP
+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
+\fBlwresd\fR
+resolver daemon. The use of this low-level API in clients
+and servers is outlined in the following sections.
+.SH "CLIENT-SIDE LOW-LEVEL API CALL FLOW"
+.PP
+When a client program wishes to make an lwres request using the
+native low-level API, it typically performs the following
+sequence of actions.
+.PP
+(1) Allocate or use an existing \fBlwres_packet_t\fR,
+called pkt below.
+.PP
+(2) Set \fBpkt.recvlength\fR 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
+\fIlwres.h\fR: LWRES_RECVLENGTH = 4096.
+.PP
+(3) Set \fBpkt.serial\fR
+to a unique serial number. This value is echoed
+back to the application by the remote server.
+.PP
+(4) Set \fBpkt.pktflags\fR. Usually this is set to 0.
+.PP
+(5) Set \fBpkt.result\fR to 0.
+.PP
+(6) Call \fBlwres_*request_render()\fR,
+or marshall in the data using the primitives
+such as \fBlwres_packet_render()\fR
+and storing the packet data.
+.PP
+(7) Transmit the resulting buffer.
+.PP
+(8) Call \fBlwres_*response_parse()\fR
+to parse any packets received.
+.PP
+(9) Verify that the opcode and serial match a request, and process the
+packet specific information contained in the body.
+.SH "SERVER-SIDE LOW-LEVEL API CALL FLOW"
+.PP
+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.
+.PP
+Note that the same \fBlwres_packet_t\fR is used
+in both the \fB_parse()\fR and \fB_render()\fR 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.
+.PP
+(1) When a packet is received, call \fBlwres_*request_parse()\fR to
+unmarshall it. This returns a \fBlwres_packet_t\fR (also called pkt, below)
+as well as a data specific type, such as \fBlwres_gabnrequest_t\fR.
+.PP
+(2) Process the request in the data specific type.
+.PP
+(3) Set the \fBpkt.result\fR,
+\fBpkt.recvlength\fR as above. All other fields can
+be left untouched since they were filled in by the \fB*_parse()\fR call
+above. If using \fBlwres_*response_render()\fR,
+\fBpkt.pktflags\fR will be set up
+properly. Otherwise, the LWRES_LWPACKETFLAG_RESPONSE bit should be
+set.
+.PP
+(4) Call the data specific rendering function, such as
+\fBlwres_gabnresponse_render()\fR.
+.PP
+(5) Send the resulting packet to the client.
+.PP
+.SH "SEE ALSO"
+.PP
+\fBlwres_gethostent\fR(3),
+\fBlwres_getipnode\fR(3),
+\fBlwres_getnameinfo\fR(3),
+\fBlwres_noop\fR(3),
+\fBlwres_gabn\fR(3),
+\fBlwres_gnba\fR(3),
+\fBlwres_context\fR(3),
+\fBlwres_config\fR(3),
+\fBresolver\fR(5),
+\fBlwresd\fR(8).