📄 x3381.htm
字号:
><P
><PRE
CLASS="SCREEN"
><service id='conf.a-domain'>
<host>conference.a-domain.com</host>
<load><conference>./conference-0.4.1/conference.so</conference></load>
<conference xmlns="jabber:config:conference">
<public/>
<vCard>
<FN>a-domain Chatrooms</FN>
<DESC>This service is for public chatrooms.</DESC>
<URL>http://www.a-domain.com/chatrooms</URL>
</vCard>
<history>10</history>
<notice>
<join> is here</join>
<leave> has left</leave>
<rename> is now known as </rename>
</notice>
<room jid="bar@conference.a-domain.com">
<name>The Bar</name>
</room>
</conference>
</service></PRE
></P
><P
>Similar to the <TT
CLASS="FILENAME"
>./config/a-domain/sessions.xml</TT
>
content, here we see a-domain.com specific definitions - crucially
the service identification as
<TT
CLASS="LITERAL"
>conf.a-domain</TT
> and the
<TT
CLASS="LITERAL"
><host/></TT
> tag
declaring the hostname that this service serves under.</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-4-SECT-4.5.2.2"
>Configuration for b-domain.com</A
></H3
><P
>Now that we've seen the a-domain specific XML, let's have a look at
the b-domain specific XML:</P
><P
><PRE
CLASS="SCREEN"
><service id="sessions.b-domain">
<host>b-domain.com</host>
<jsm xmlns="jabber:config:jsm">
...
<vCard>
<FN>b-domain Jabber Server</FN>
<DESC>Jabber 1.4.1 on b-domain.com</DESC>
<URL>http://www.b-domain.com/</URL>
</vCard>
<browse>
<conference type="public" jid="conference.b-domain"
name="b-domain Conferencing"/>
<service type="jud" jid="jud.b-domain" name="b-domain JUD">
<ns>jabber:iq:search</ns>
<ns>jabber:iq:register</ns>
</service>
</browse>
<register notify="yes">
<instructions>
Choose a username and password to register with this server.
</instructions>
<name/>
</register>
<welcome>
<subject>Welcome!</subject>
<body>Welcome to the Jabber server at b-domain</body>
</welcome>
<admin>
<read>info@b-domain</read>
<write>service@b-domain</write>
<reply>
<subject>Auto Reply</subject>
<body>This is a special administrative address.</body>
</reply>
</admin>
</jsm>
<load main="jsm">
<jsm>./jsm/jsm.so</jsm>
<mod_echo>./jsm/jsm.so</mod_echo>
<mod_roster>./jsm/jsm.so</mod_roster>
<mod_time>./jsm/jsm.so</mod_time>
<mod_vcard>./jsm/jsm.so</mod_vcard>
<mod_last>./jsm/jsm.so</mod_last>
<mod_version>./jsm/jsm.so</mod_version>
<mod_announce>./jsm/jsm.so</mod_announce>
<mod_agents>./jsm/jsm.so</mod_agents>
<mod_browse>./jsm/jsm.so</mod_browse>
<mod_admin>./jsm/jsm.so</mod_admin>
<mod_filter>./jsm/jsm.so</mod_filter>
<mod_offline>./jsm/jsm.so</mod_offline>
<mod_presence>./jsm/jsm.so</mod_presence>
<!--
zero-knowledge authentication only
<mod_auth_plain>./jsm/jsm.so</mod_auth_plain>
<mod_auth_digest>./jsm/jsm.so</mod_auth_digest>
-->
<mod_auth_0k>./jsm/jsm.so</mod_auth_0k>
<mod_log>./jsm/jsm.so</mod_log>
<mod_register>./jsm/jsm.so</mod_register>
<mod_xml>./jsm/jsm.so</mod_xml>
</load>
</service>
</PRE
></P
><P
>We can see here that we've fulfilled our requirements of the virtual
server for b-domain - registration is open but authentication is limited
to zero-knowledge, and the services offered in the
<TT
CLASS="LITERAL"
><browse/></TT
> list are unique to
b-domain.
<A
NAME="JABTDG-CH-4-FOOTNOTE-24"
HREF="#FTN.JABTDG-CH-4-FOOTNOTE-24"
>[3]</A
> </P
><P
>The <I
CLASS="EMPHASIS"
>Conferencing</I
> and JUD services associated with
the b-domain.com hostname will be configured in a similar way to how the
<I
CLASS="EMPHASIS"
>Conferencing</I
> service was configured in
<TT
CLASS="FILENAME"
>./config/a-domain/conference.xml</TT
> for a-domain -
crucially again the service ids will be unique and the
<TT
CLASS="LITERAL"
><host/></TT
> tags will be specific
to b-domain.com. </P
><P
>As long as each component instance is uniquely identified and you have
used separate hostname definitions, 'real' virtual Jabber servers
<I
CLASS="EMPHASIS"
>all listening to the same Jabber standard client port of
5222 on a single host</I
> can be, er, a reality. </P
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="JABTDG-CH-4-SECT-4.5.3"
>Splitting up the Jabber Server Processes</A
></H2
><P
>As well as being possible to lump multiple Jabber server identities in
the form of virtual hosting onto a single Jabber server and its
corresponding monolithic process, it is also possible to go
in the opposite direction and split up a single Jabber server into
multiple processes. These processes interact through TCP socket connections
and so it's possible for them to run on the same or different physical hosts.</P
><P
>How is this achieved? Well, revisiting the ideas from the start of this
chapter, we consider that a Jabber server is a daemon
(<B
CLASS="COMMAND"
>jabberd</B
>) and a set of components that provide the
services. Taking one step away from the 'classic' Jabber server model which
contains components such as the ones described in
<A
HREF="x1234.htm"
>the section called <I
>An Overview of the Server Architecture</I
></A
> we can imagine a Jabber server where
<B
CLASS="COMMAND"
>jabberd</B
> controls just one component, say the
<I
CLASS="EMPHASIS"
>Conferencing</I
> component.</P
><P
>How much use is a Jabber server with a single <I
CLASS="EMPHASIS"
>Conferencing</I
>
component? Not much. But <I
CLASS="EMPHASIS"
>linked together with another</I
>
Jabber server, we can see that this is a way to split off components and run
them independently.</P
><P
>Taking the <I
CLASS="EMPHASIS"
>Conferencing</I
> component as an example
candidate for ostracism, let's have a look at
what we need to do.</P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-4-SECT-4.5.3.1"
>Define the Configuration for the Satellite Server</A
></H3
><P
>This is very straightforward - we've seen <I
CLASS="EMPHASIS"
>Conferencing</I
>
configuration before so we'll shorten it a bit here:</P
><P
><PRE
CLASS="SCREEN"
><jabber>
<service id='conf.yak'>
<host>conference.yak</host>
<load><conference>./conference-0.4.1/conference.so</conference></load>
<conference xmlns="jabber:config:conference">
...
</conference>
</service>
</jabber></PRE
></P
><P
>This is the entirety of the configuration file so far for the satellite
server - there's only one component instance - with an id of "conf.yak".
Notice that the only other tag pair is the file-wide
<TT
CLASS="LITERAL"
><jabber> ... </jabber></TT
>.
Let's call it <TT
CLASS="FILENAME"
>jabber_conf.xml</TT
>.</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-4-SECT-4.5.3.2"
>Open a Connection Point in the Main Server</A
></H3
><P
>We've already seen a mechanism earlier in this chapter in
<A
HREF="x1234.htm#JABTDG-CH-4-SECT-4.1.3"
>the section called <I
>Component Connection Methods</I
></A
> that allows external components
to connect
into the Jabber server backbone by exchanging XML streams in the
<TT
CLASS="LITERAL"
>jabber:component:accept</TT
> namespace. This is the
TCP socket connection method.</P
><P
>We can prepare a connection point to the main Jabber server by specifying
a component connection like this:</P
><P
><PRE
CLASS="SCREEN"
><service id="conflinker">
<host>conference.merlix</host>
<accept>
<ip>127.0.0.1</ip>
<port>9001</port>
<secret>confsecret</secret>
</accept>
</service></PRE
></P
><P
>in the configuration for the main Jabber server.</P
><P
>There's no real difference between this XML and the XML shown in the
<TT
CLASS="LITERAL"
><accept/></TT
> example earlier
in this Chapter. The clue lies in the service id, which has been defined
as "conflinker". There's nothing special about the name; it simply gives
the administrator a hint that there's some sort of link to a conference
service from this point. </P
><P
>We're specifying acceptance of connections on IP address 127.0.0.1 - the
same host as this main server, but it could just as easily be the IP
address assigned to a network card, so that the connection could be
made from a satellite server on a separate host. </P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-4-SECT-4.5.3.3"
>List the Service Definition in
<TT
CLASS="LITERAL"
><browse/></TT
></A
></H3
><P
>While we're editing the main server's XML, we should add an entry
for our satellite conference service:</P
><P
><PRE
CLASS="SCREEN"
><browse>
...
<TT
CLASS="USERINPUT"
><B
> <conference type="public" jid="conference.yak" name="yak Conferencing"/>
</B
></TT
>
...
</browse></PRE
></P
><P
>The jid defined here must match the host defined in the
<I
CLASS="EMPHASIS"
>Conferencing</I
> component instance definition in the
satellite server configuration.</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-4-SECT-4.5.3.4"
>Add a Connector Mechanism to the Satellite Server</A
></H3
><P
>Now we've opened up a connection point in the main server, we need to
add some corresponding configuration to the satellite server's XML
- the 'plug' that will attach to the connection point on the main server:</P
><P
><PRE
CLASS="SCREEN"
><jabber>
<TT
CLASS="USERINPUT"
><B
><service id="conflinker">
<uplink/>
<connect>
<ip>127.0.0.1</ip>
<port>9001</port>
<secret>confsecret</secret>
</connect>
</service></B
></TT
>
<service id='conf.yak'>
<host>conference.yak</host>
<load><conference>./conference-0.4.1/conference.so</conference></load>
<conference xmlns="jabber:config:conference">
...
</conference>
</service>
</jabber></PRE
></P
><P
>This new service - the 'plug' - with an id of "conflinker"
(to match the id of the corresponding 'socket' in the main server)
contains two elements -
the <TT
CLASS="LITERAL"
><connect/></TT
> tag which
corresponds to the <TT
CLASS="LITERAL"
><accept/></TT
>
tag in the main server's configuration, and the
<TT
CLASS="LITERAL"
><uplink/></TT
> tag, which
serves as a conduit for all types of packets - those handled by each
of the three delivery trees <I
CLASS="EMPHASIS"
>log</I
>,
<I
CLASS="EMPHASIS"
>xdb</I
> and <I
CLASS="EMPHASIS"
>service</I
>.
<A
NAME="JABTDG-CH-4-FOOTNOTE-25"
HREF="#FTN.JABTDG-CH-4-FOOTNOTE-25"
>[4]</A
> </P
><P
>While we're looking at the satellite server's configuration again, it's
worth pointing out that even in a situation where the satellite server
process would be running on a separate host (we're running it here on the
same host - hence the localhost IP address of 127.0.0.1 in the
<TT
CLASS="LITERAL"
><accept/></TT
> tag), the value
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -