?? x1581.htm
字號:
<HTML
><HEAD
><TITLE
>Server Configuration</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.64
"><LINK
REL="HOME"
TITLE="Programming Jabber"
HREF="book1.htm"><LINK
REL="UP"
TITLE="Server Architecture and Configuration"
HREF="c1223.htm"><LINK
REL="PREVIOUS"
TITLE="An Overview of the Server Architecture"
HREF="x1234.htm"><LINK
REL="NEXT"
TITLE="A Tour of jabber.xml"
HREF="x1740.htm"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Programming Jabber</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x1234.htm"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 4. Server Architecture and Configuration</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x1740.htm"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="JABTDG-CH-4-SECT-4.2"
>Server Configuration</A
></H1
><P
>At this stage, we should be fairly comfortable with the notion of a
<B
CLASS="COMMAND"
>jabberd</B
> backbone and a set of components that combine
to provide the features needed for a complete messaging system.
We've looked at fragments of configuration in the previous section; now
it's time to examine the configuration directives in more detail. </P
><P
>It's not uncommon for people installing a Jabber server for the first time
to be daunted (I was terrified!) by the contents of the
<TT
CLASS="FILENAME"
>jabber.xml</TT
> configuration file. But really, for the
most part, it's just a collection of component descriptions—what those
components are, how they're connected, what packets they are to process,
and what their individual configuration is. </P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="JABTDG-CH-4-SECT-4.2.1"
>Component instances</A
></H2
><P
>There's a concept that encompasses Jabber's configuration approach that
is taken from the object-oriented (OO) world—the concept of objects
(and classes) and instances thereof. In Jabber server configuration,
specifically
the description of the components that are to make up a particular Jabber
server, we talk about <I
CLASS="EMPHASIS"
>instances</I
> of components, not
components directly.</P
><P
>In other words, a component is something generic that is written to provide
a specific service or set of services; when we put that component to use
in a Jabber server, we customize the characteristics of that component by
specifying detailed configuration pertaining to how that component will
<I
CLASS="EMPHASIS"
>actually</I
> work. We're creating an "instance" of that
component.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="JABTDG-CH-4-SECT-4.2.2"
>A typical component instance description</A
></H2
><P
>Each component instance description follows the same approximate pattern:</P
><P
></P
><UL
><LI
><P
>Declaration of the component type</P
></LI
><LI
><P
>Identification (name) of the component</P
></LI
><LI
><P
>Specification of the host filter for packet reception</P
></LI
><LI
><P
>Definition of how the component is connected</P
></LI
><LI
><P
>Custom configuration for the component</P
></LI
></UL
><P
>Of course, for any generalized rule, there's always an exception.
The <I
CLASS="EMPHASIS"
>log</I
> component
type, as mentioned earlier in this chapter, is defined slightly differently
—while there is a host filter defined, a component connection
definition is not relevant nor present, and the custom configuration is
limited—
we'll see this later when we take a tour of the <TT
CLASS="FILENAME"
>jabber.xml</TT
>.</P
><P
>Let's have a closer look at the <I
CLASS="EMPHASIS"
>Client (to Server)
Connections</I
>
(c2s) component and how an instance of it is specified in the
<TT
CLASS="FILENAME"
>jabber.xml</TT
>. We're going to use the one which
comes delivered in the Jabber 1.4.1 server
distribution tarball. <A
HREF="x1581.htm#JABTDG-CH-4-EX-7"
>Example 4-7</A
>
shows how the c2s is defined. The definition includes details of how
the component code is connected (using the <I
CLASS="EMPHASIS"
>library load</I
>
method), and
contains some custom configuration covering authentication timeout (the
<TT
CLASS="LITERAL"
><authtime/></TT
> tag), traffic flow control
(the <TT
CLASS="LITERAL"
><karma/></TT
> section), and what port
c2s is to listen on (the <TT
CLASS="LITERAL"
><ip/></TT
> tag).
We'll look at these custom configuration tags in detail later.</P
><DIV
CLASS="EXAMPLE"
><A
NAME="JABTDG-CH-4-EX-7"
></A
><P
><B
>Example 4-7. The <TT
CLASS="LITERAL"
>c2s</TT
> instance configuration in
<TT
CLASS="FILENAME"
>jabber.xml</TT
></B
></P
><P
><PRE
CLASS="SCREEN"
><service id="c2s">
<load>
<pthsock_client>./pthsock/pthsock_client.so</pthsock_client>
</load>
<pthcsock xmlns='jabber:config:pth-csock'>
<authtime/>
<karma>
<init>10</init>
<max>10</max>
<inc>1</inc>
<dec>1</dec>
<penalty>-6</penalty>
<restore>10</restore>
</karma>
<ip port="5222"/>
</pthcsock>
</service></PRE
></P
></DIV
><P
>Now let's arrange this instance configuration in diagram form.
<A
HREF="x1581.htm#JABTDG-CH-4-FIG-4.2"
>Figure 4-3</A
>
highlights the pattern we're expecting to see.</P
><DIV
CLASS="FIGURE"
><A
NAME="JABTDG-CH-4-FIG-4.2"
></A
><P
><B
>Figure 4-3. A diagram of the <TT
CLASS="LITERAL"
>c2s</TT
> instance
configuration in <TT
CLASS="FILENAME"
>jabber.xml</TT
></B
></P
><PRE
CLASS="SCREEN"
> +-----+
| c2s |
+-----+-------------------------------------------+
| service |
| |
|--> host |
| (none specified) |
| |
|--> connect |
| load ./pthsock/pthsock_client.so |
| |
|--> config |
| | |
| +--> authtime |
| | |
| +--> karma |
| | |
| +--> ip |
| |
+-------------------------------------------------+ </PRE
></DIV
><P
>If we look at the component instance descriptions in this way, it's easy
to understand how the configuration is put together, and we can begin to
see the pattern emerging. Taking each of the elements of the pattern in
turn let's examine what the XML tells us.</P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-4-SECT-4.2.2.1"
>Component type</A
></H3
><P
>The component type is <I
CLASS="EMPHASIS"
>service</I
>. We know that from
looking at the outermost tag in the XML:</P
><P
><PRE
CLASS="SCREEN"
><<TT
CLASS="USERINPUT"
><B
>service</B
></TT
> id="c2s">
...
</<TT
CLASS="USERINPUT"
><B
>service</B
></TT
>></PRE
></P
><P
>So we know that this component instance will handle
<TT
CLASS="LITERAL"
><message/></TT
>,
<TT
CLASS="LITERAL"
><presence/></TT
>,
<TT
CLASS="LITERAL"
><iq/></TT
> and
<TT
CLASS="LITERAL"
><route/></TT
> packets.</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-4-SECT-4.2.2.2"
>Identification</A
></H3
><P
>Each component instance must be uniquely identified within the space of
a single Jabber server (configuration). <B
CLASS="COMMAND"
>jabberd</B
> uses
this identification to address the components and deliver packets to the
right place. In this case,
the identification of this component instance is <I
CLASS="EMPHASIS"
>c2s</I
>;
it's taken from the <TT
CLASS="OPTION"
>id</TT
> attribute of the component type tag:</P
><P
><PRE
CLASS="SCREEN"
><service id="<TT
CLASS="USERINPUT"
><B
>c2s</B
></TT
>"></PRE
></P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-4-SECT-4.2.2.3"
>Host filter</A
></H3
><P
>The diagram shown in <A
HREF="x1581.htm#JABTDG-CH-4-FIG-4.2"
>Figure 4-3</A
>
states <I
CLASS="EMPHASIS"
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -