10. 组件
唯一的步骤是告诉服务器要加载哪些组件，如何命名它们并提供一些可选的额外参数。为此，请打开您在安装中使用的 config.tdsl 文件。
假设您现在只想添加 PubSub。您需要做的就是将以下内容添加到属性文件中：
pubsub (class: tigase.pubsub.PubSubComponent) {}
通常，这不是必需的，因为默认情况下会加载 pubsub，但这只是加载具有 DSL 格式的类的示例。
'pubsub-priv' (class: tigase.pubsub.PubSubComponent) {}
如您所见，我们可以在减速中自定义一个组件的名称，这里我们使用的是pubsub-priv。
虽然这可能很少见，但它允许广泛的兼容性和平台稳定性。
通常，我们希望加载几个不同的组件，例如 PubSub，MUC，MSN Transport 等等……。因此，我们可以加载 MUC 组件，而不是上面的第二个 PubSub：
muc (class: tigase.muc.MUCComponent) {}
pubsub (class: tigase.pubsub.PubSubComponent) {}
对 config.tdsl 文件的更改将在服务器重新启动时生效。
10.1. 高级消息处理 - AMP XEP-0079
Tigase 服务器提供对 XEP-0079: Advanced Message Processing (通常缩写为 AMP）的支持。
它默认启用，但您可以调整几个配置选项。
AMP 的配置不是很复杂，但由于它是作为 Tigase 服务器中的一个组件实现的，因此确实需要一些设置才能使其正确。
这是 AMP 配置的第一个简要概述，随后是每个参数的详细说明。
'sess-man' {
amp () {
'amp-jid' = '[email protected]'
}
message (active: false) {}
msgoffline (active: false) {}
}
'amp-security-level' = 'STRICT'
10.1.1. 首先：插件
即使整个功能是在组件内部实现的，您也需要一种将带有 AMP 有效负载的消息转发到该组件的方法。这就是 amp 插件的作用。 amp 插件拦截所有 <message/> 数据包，即使没有 AMP 有效负载，将其中一些重定向到 AMP 组件，而其他以标准方式处理。因此，您不再需要 message 插件或 msgoffline 插件。这些都是 amp 插件现在提供的所有功能。因此，您必须关闭 message 和 msgoffline 插件（默认情况下会加载 amp 插件）：
'sess-man' {
amp () {}
message (active: false) {}
msgoffline (active: false) {}
}
amp 插件需要知道将所有 amp 数据包转发到哪里。默认情况下，插件使用给定机器的主机名，因为大多数安装都是如此。但是，这是由示例配置的最后一行配置的，它将所有数据包转发到地址 amp@your-domain.tld:
'sess-man' {
amp () {
'amp-jid' = '[email protected]'
}
}
10.1.2. 第二：组件
默认情况下，Tigase 使用标准名称 amp 加载组件
10.1.3. 可选参数
组件和插件之间还共享一个参数。可连接到存储离线消息的数据库。 AMP 组件具有用于存储离线消息的专用架构，专为高流量和高负载安装而设计。它不使用 UserRepository 来存储消息。
默认情况下，使用与 UserRepository 相同的物理数据库，但您可以更改它并将消息存储在完全独立的位置，以减少系统其余部分性能的下降。您可以使用以下属性设置数据库连接字符串：
dataSource {
'default-amp' () {
uri = 'jdbc:mysql://localhost/tigasedb?user=db_usr&password=db_pwd'
}
}
XEP-0079 规范有一个 Section 9. - Security Considerations。 正如其所描述的，在某些情况下，AMP 协议可用于向未授权进行状态更新的其他用户显示用户的状态信息。有几种可能的方法可以防止这种情况。
Tigase 的实现提供了 3 种模式来处理 AMP 请求，以防止向非授权用户泄露用户的状态：
'amp-security-level' = 'STRICT'
在这种模式下，服务器执行严格的检查。 AMP 规范已完全处理。然而，这涉及到每个离线用户的名册加载，因此它可能会影响服务性能。对于具有大量 AMP 消息的高负载服务，在此模式下运行可能不可行或不可能。
在 XEP 中，这种模式是这样描述的：
仅当发送者被授权接收接收者的存在时才接受相关条件，因此如果发送者未被授权，服务器必须回复 <not-acceptable/> 错误条件；这是推荐的行为。这也是 Tigase 中的默认设置。
'amp-security-level' = 'PERFORMANCE'
只需返回错误响应即可有效地执行虚拟检查，这样每次默认操作可能会在不查看用户名册的情况下显示用户状态。这不会影响性能，但会影响 AMP 合规性。
在 XEP 中，这种模式是这样描述的：
仅当动作为 “drop” 时才接受相关条件，因此如果动作为 “alert”, “error”, 或 “notify”; 服务器必须回复<not-acceptable/>错误条件；这限制性稍小，但仍不必要地限制了系统的功能，因此不推荐。
它不做任何检查。它的作用就像所有用户都有权接收通知，即使它可能会向未经授权的用户透露用户状态。但它不会影响服务器性能，并提供完整的 AMP 合规性。
'amp-security-level' = 'NONE'
10.2. 服务器监控
与 Tigase 服务器监控相关的所有文档和资源。
10.2.1. 在服务器中设置远程监控
Tigase 服务器可以通过以下协议进行远程监控：JMX/RMI, SNMP 和 HTTP。尽管 JMX 为服务器状态提供了最大的控制和可见性，但所有监视服务都提供了相同的基本服务器统计数据集：
s2s，c2s 和 Bosh 的网络连接数
所有主要组件的最后一秒, 最后一分钟和最后一小时负载：SM, MR, c2s, s2s, Bosh, MUC 和 PubSub
系统统计信息 - 内存使用情况（堆和非堆）和服务器正常运行时间（以毫秒为单位）和人类可读的文本。
用户统计 - 注册用户数和在线用户会话数。
JMX/RMI 和 SNMP 服务器提供基本的安全性能并且可以限制访问，而 HTTP 服务器不提供任何访问限制机制。因此，建议 HTTP 监控在防火墙后运行。
在正常的 Tigase 处理要求之上，监视本身在资源和 CPU 消耗方面导致非常低的开销，因此可以保留它而不必担心性能下降。
注意 这适用于版本 4.2.0 或构建 1418 的 Tigase 服务器。
你需要什么
统计二进制文件是内置的 -dist-max ，不需要额外的文件。如果你已经下载了 -dist 文件，你需要构建 tigase-extras[https://github.com/tigase/tigase-extras] 并将其包含在 jars/ 目录中。
激活
您可以运行 Tigase 安装程序并使用配置向导来激活监控或编辑 etc/config.tdsl 文件并添加以下行：
monitoring() {
jmx() {
port = 9050
}
http() {
port = 9080
}
snmp() {
port = 9060
}
}
如您所见，您要激活的每个监控服务器都有一个单独的块。每个服务器负责激活不同的协议并采用单个参数 - 端口号。目前支持以下协议：
jmx- 通过 JMX/RMI 激活监控http- 通过 HTTP 协议激活监控snmp- 通过 SNMP 协议激活监控
您可以同时激活所有协议或它们的任意组合或不激活。
安全
JMX 和 SNMP 都可提供安全保护来限制对监控数据的访问。两者的安全配置略有不同。
JMX
服务器安装后或在 SVN 存储库中，您可以在 etc/ 目录中找到 2 个文件：jmx.access 和 jmx.password。
jmx.access是一个用户权限文件。您可以使用它来指定用户是否可以只读readonly或读写readwrite访问监控数据。文件中已有示例条目，内容可能如下所示：monitor readonly admin readwrite
jmx.password是一个用户密码文件。您可以在此处设置用户密码，格式也是非常简单，与 jmx.access 相同。为方便起见，已经提供了示例条目。该文件的内容可能类似于以下示例：admin admin_pass monitor monitor_pass
使用上述文件，您可以控制谁以及如何访问 JMX 监控服务。
SNMP
使用 ACL（访问控制列表）控制对 SNMP 监控的访问，该访问控制列表可以在位于 etc/ 目录中的文件 snmp.acl 中进行配置。它包含许多详细说明如何设置 ACL 和限制每个用户，主机的访问以及允许的访问类型。最简单的配置可能如下所示：
acl = {
{
communities = public, private
access = read-only
managers = public.host.com, private.host.com
}
{
communities = admin
access = read-write
managers = localhost, admin.host.com
}
}
您可能还需要 Tigase MIB 定义：TIGASE-MANAGEMENT-MIB.mib 以用于服务器特定的统计信息。 MIB 包含通过 SNMP 公开的所有服务器统计信息的定义。
HTTP
访问 example.com:9080 上的服务器，您将看到一个代理视图。
10.2.2. 从服务器检索统计信息
默认情况下，我们可以使用 XMPP 检索服务器统计信息，无需额外设置。
使用 XMPP 检索统计信息
通过 XMPP 协议访问统计数据需要任何 XMPP 客户端能够执行 XEP-0050: Ad-Hoc Commands。必须记住，只有管理员（其 JID 配置为管理的用户）才能访问统计信息。
Psi XMPP客户端
出于本指南的目的，将使用 Psi 客户端。成功配置并连接到具有管理权限的帐户后，我们需要从应用程序菜单或特定帐户的上下文菜单访问 Service Discovery：
在 Service Discovery 窗口中，我们需要找到 Server Statistics 组件：
我们可以访问所有组件的统计信息，也可以在展开树后选择特定组件。要执行临时命令，只需双击将打开统计窗口的特定节点：
在此窗口中，除了查看统计信息外，我们还可以通过从列表中选择所需级别来调整 Stats level，然后单击 Finish 进行确认。
使用 JMX 检索统计信息
为了通过 JMX 访问统计信息，我们需要在 Tigase 中启用对它的支持 - Monitoring Activation。之后我们可以使用一些工具来获取统计信息，例如：
JConsole
打开 JConsole 后，我们要么选择本地进程，要么提供远程进程的详细信息，包括来自 etc/jmx.\* 文件的 IP，端口和凭据：
之后我们去找到 MBeans 选项卡，从中我们可以访问 tigase.stats MBean。它提供了与 XMPP 类似的选项 - 访问所有组件的统计信息或仅访问特定组件的统计信息，以及调整我们想要获取统计信息的级别：
StatsDumper.groovy
为了收集一段时间内的统计信息，可以使用以下 groovy 脚本：StatsDumper.groovy。它是一个简单的 JMX 客户端，连接到 Tigase 并定期将所有统计信息保存到文件中。
它接受以下参数：
$ groovy StatsDumper.groovy [hostname] [username] [password] [dir] [port] [delay(ms)] [interval(ms)] [loadhistory(bool)]
hostname- 实例地址username- JMX 用户名password- JMX 用户名dir- 保存带有统计信息的文件的目录port- 建立连接的端口delay(ms) - 初始延迟（以毫秒为单位），之后应保存统计信息interval(ms) - 每次检索/保存统计信息之间的间隔loadhistory(bool) - 表明是否从服务器加载统计历史记录（如果在 Tigase 中启用）
10.2.3. 监控组件
Tigase 包含一个 Monitor Component 以帮助进行监控。这允许您为某些预定义任务设置阈值，并且当超过这些阈值时，您或其他 JIDs 可以收到一条消息。您甚至可以配置邮件程序扩展，将电子邮件发送给系统管理员，让他们知道发生了什么事情！让我们从设置和要求开始。
Monitor 组件基于 eventbus，而 eventbus 又基于有限的 PubSub 规范。事件作为普通的 PubSub 通知传递给订阅者。
每个组件或客户端都可以订阅特定类型的事件。只允许集群节点上的组件发布事件。
设置
监视器组件在 v7.1.0 b4001 及更高版本上默认启用，因此无需设置！
这个怎么工作
Eventbus 中的事件由两个元素标识：事件名称及其命名空间：
<EventName xmlns="tigase:demo">
<sample_value>1</sample_value>
</EventName>
其中事件名称是 EventName，命名空间是 tigase:demo。
侦听器可以订阅特定事件或具有特定命名空间的所有事件。因为在 pubsub 中，只有一个节点名存在，所以我们要添加一种方法，将事件名和命名空间转换为节点名：
nodename = eventname + "|" + namespace
例如，要订阅 <EventName xmlns="tigase:demo">，节点必须是：EventName|tigase:demo。如果您希望订阅具有特定命名空间的所有事件，请使用星号（*）而不是事件名称：*|tigase:demo。
可用任务
Monitor Component 有几个预定义的任务可以被监控并设置为触发。以下是任务列表，其中包含每个任务的选项。
- disk-task - 用于检查磁盘使用情况。可用选项
enabled- 启用或禁用任务，布尔值。period- 运行检查的周期，整数值。threshold- 磁盘上已用空间的百分比，浮点值。
- cpu-temp-task - 用于检查 CPU 温度。可用选项
enabled- 启用或禁用任务，布尔值。period- 运行检查的周期，整数值。cpuTempThreshold- CPU 的温度阈值，以°C 为单位。
- load-checker-task - 用于检查系统负载。可用选项
enabled- 启用或禁用任务，布尔值。period- 运行检查的周期，整数值。averageLoadThreshold- 平均百分比负载阈值，long 值。
- memory-checker-task - 用于检查内存使用情况。可用选项
enabled- 启用或禁用任务，布尔值。period- 运行检查的周期，整数值。maxHeapMemUsagePercentThreshold- 已用堆内存百分比大于此值时发出警报，此值为整数值。maxNonHeapMemUsagePercentThreshold- 已用非堆内存百分比大于此值时发出警报，此值为整数值。
- logger-task - 用于根据输入级别传输的日志条目。
enabled- 启用或禁用任务，布尔值。levelThreshold- 将成为阈值的最小日志级别。可能的值为 SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINEST 和 ALL。
- connections-task - 用于检查用户断开连接。注意：仅当满足两个阈值（数量和百分比）时才会生成事件。
enabled- 启用或禁用任务，布尔值。period- 运行检查的周期，整数值。thresholdMinimal- 生成警报所需断开连接用户的最小数量。threshold- 生成警报所需的断开连接用户的最小百分比。
配置
监视器的配置可以通过以下两种方式之一完成；通过 config.tdsl 文件中的行，或者通过将 XMPP 节发送到服务器。您也可以通过 HTTP REST 发送 XMPP 节。 XMPP 节配置将覆盖 config.tdsl 中的配置，但它们只会持续到服务器重新启动。
config.tdsl
可以在 config.tdsl 文件中配置任务。有关可以设置的任务，请参阅 可用任务。
要启用特定的监控任务，请使用以下行：
monitor {
'$TASKNAME' {
setting = value
}
}
其中 monitor 是 MonitorComponent 的组件名称，而 $TASKNAME 是 可用任务 之一。
此格式与任务的其他设置相同，最好将设置分组在一个标题下。例如：
monitor {
'connections-task' {
enabled = true
period = 1000
}
}
将检查周期设置为 1000 毫秒并启用 connections-task。
备注
一旦触发器被激活，它们就会进入休眠状态。将这些视为一次性设置。
订阅限制
要定义允许订阅事件的 JIDs 列表：
eventbus {
affiliations {
allowedSubscribers = '[email protected],[email protected]'
}
}
如果以上未指定，则所有用户都可以订阅。
通过 XMPP 配置
我们还可以使用 XMPP 节配置事件总线监视器组件。这允许我们在服务器运行时设置和更改配置。这是使用一系列发送到监视器组件的 iq 节来完成的。
我们可以使用以下节查询每个组件的当前设置。
<iq type="set" to="monitor@$DOMAIN/disk-task" id="aad0a">
<command xmlns="http://jabber.org/protocol/commands" node="x-config"/>
</iq>
服务器将返回组件当前设置，如果您想编辑它们，这将变得更容易。在这种情况下，服务器已向我们返回以下内容
<iq from="monitor@$DOMAIN/disk-task" type="result" id="aad0a" to="[email protected]/Psi+">
<command xmlns="http://jabber.org/protocol/commands" status="executing" node="x-config"
sessionid="0dad3436-a029-4082-b0e0-04d838c6c0da">
<x xmlns="jabber:x:data" type="">
<title>Task Configuration</title>
<instructions/>
<field type="boolean" label="Enabled" var="x-task#enabled">
<value>0</value>
</field>
<field type="text-single" label="Period [ms]" var="x-task#period">
<value>60000</value>
</field>
<field type="text-single" label="Disk usage ratio threshold" var="threshold">
<value>0.8</value>
</field>
</x>
</command>
</iq>
这告诉我们，disk-task 设置不活跃，有 60000ms 的周期，当磁盘使用率超过 80% 时会触发。
要将新设置发送到监视器组件，我们可以将类似的节发送回监视器组件。
<iq type="set" to="monitor@$DOMAIN/disk-task" id="aad1a">
<command xmlns="http://jabber.org/protocol/commands" node="x-config"
sessionid="0dad3436-a029-4082-b0e0-04d838c6c0da">
<x xmlns="jabber:x:data" type="submit">
<field type="boolean" var="x-task#enabled">
<value>0</value>
</field>
<field type="text-single" var="x-task#period">
<value>60000</value>
</field>
<field type="text-single" var="threshold">
<value>0.8</value>
</field>
</x>
</command>
</iq>
成功的更新将为您提供 XMPP 成功节，让您知道一切设置正确。
或者，您可以通过编辑单个字段而不添加任何其他内容来更新特定设置。例如，如果我们只想打开磁盘任务，我们可以发送以下节：
<iq type="set" to="monitor@$HOSTNAME/disk-task" id="ab53a">
<command xmlns="http://jabber.org/protocol/commands" node="x-config">
<x xmlns="jabber:x:data" type="submit">
<field type="boolean" var="x-task#enabled">
<value>1</value>
</field>
</x>
</command>
</iq>
要设置任何其他值，请不要忘记某些部分可能需要更改，特别是 <field type="boolean" var=x-task#enabled"> 字段:
获取消息
如果没有发送消息的地方，监视器只会触发并关闭。监视器有两种不同的方法来传递警报消息和相关数据； XMPP 消息并使用邮件程序扩展。
XMPP 通知
eventbus@<VHost> 用户。请记住，订阅在服务器重新启动或触发后是会变化的。eventName|eventXMLNS。由于每个监控任务都有 tigase:monitor:event 事件 XMLNS，我们只需要从任务列表中选择事件名称。所以像上面的例子一样，我们的磁盘任务事件节点将是 disk-task|tigase:monitor:event 。其用于 XMPP 节，它看起来像这样：<iq type='set'
to='eventbus@<VHost>'
id='sub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscribe node='disk-taskEvent|tigase:monitor:event' jid='$USER_JID'/>
</pubsub>
</iq>
不要忘记将 $USER_JID 替换为您想要接收这些消息的用户的裸 JID。您甚至可以将它们发送到 MUC 或任何具有 JID 的组件。
可用的事件如下：
disk-task的 DiskUsageMonitorEventlogger-task的LoggerMonitorEventmemory-checker-task的HeapMemoryMonitorEventload-checker-task的LoadAverageMonitorEventcpu-temp-task的 CPUTempMonitorEventconnections-task的UsersDisconnected
或者，您还可以使用通配符 * 代替事件 XMLNS 来订阅事件总线中的所有事件，如下例所示：
<iq type='set'
to='eventbus@<VHost>'
id='sub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscribe node='*|tigase:monitor:event' jid='$USER_JID'/>
</pubsub>
</iq>
来自 Monitor 的示例通知
<message from='eventbus.shakespeare.lit' to='[email protected]' id='foo'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='EventName|tigase:demo'>
<item>
<EventName xmlns="tigase:demo" eventSource="samplecomponent.shakespeare.lit'" eventTimestamp="1444216850">
<sample_value>1</sample_value>
</EventName>
</item>
</items>
</event>
</message>
邮件扩展
Tigase Server Monitor Mailer Extension (TSMME) 可以将消息从监视器组件发送到指定的电子邮件地址，以方便那些未登录到 XMPP 服务器的系统管理员。
对于 v7.1.0 及更高版本，TSMME 已包含在您的分发包中，无需额外安装。
配置
Tigase Mailer Extension 可以通过 config.tdsl 文件用以下方式配置：
monitor {
'mailer-from-address' = 'sender@<VHost>'
'mailer-smtp-host' = 'mail.tigase.org'
'mailer-smtp-password' = '********'
'mailer-smtp-port' = '587'
'mailer-smtp-username' = 'sender'
'mailer-to-addresses' = 'receiver@<VHost>,admin@<VHost>'
}
这是对这些变量的解释。
mailer-smtp-host- SMTP 服务器主机名。mailer-smtp-port- SMTP服务器端口。mailer-smtp-usernam- 发件人帐户的名称。mailer-smtp-password- 发件人帐户的密码。mailer-from-address- 发件人电子邮件地址。它将在电子邮件中的字段中设置。mailer-to-addresses- 逗号分隔的通知接收者电子邮件地址。
建议仅出于此目的在您的邮件服务器中创建一个特定的电子邮件地址，因为帐户设置以明文形式存储而没有加密。
10.2.4. 统计记录器的配置
可以启用和配置统计信息的自动存储。为此，您需要将以下任何统计记录器配置为 StatisticsCollector 组件子 bean：
tigase.stats.CounterDataArchivizer每次执行都会将当前的基本服务器指标（CPU 使用率，内存使用率，用户连接数，正常运行时间）放入数据库（覆盖先前的条目）。
tigase.stats.CounterDataLogger每次执行都会在数据库中插入新的行，其中包含一组新的服务器统计数据（CPU 使用率，内存使用率，每个连接器的用户连接数，已处理的不同类型的数据包数，正常运行时间等）。
tigase.stats.CounterDataFileLogger每次执行都将所有服务器统计信息存储到单独的文件中。
tigase.stats.CounterDataFileLogger 以每 60 秒将级别为 FINE 的统计数据归档到以 stat 为前缀并位于 logs/server_statistics 的文件中，以下条目是所需要的：
stats() {
'stats-file-logger' (class: tigase.stats.CounterDataFileLogger) {
'stats-directory' = 'logs/server_statistics'
'stats-filename' = 'stat'
'stats-unixtime' = false
'stats-datetime' = true
'stats-datetime-format' = 'HH:mm:ss'
'stats-level' = 'FINEST'
}
}
10.3. 服务器到服务器协议设置
Tigase 服务器到服务器通信组件促进了与其他 XMPP 服务器（联合）的通信，并允许您调整其配置以获得更好的安装性能。
默认情况下启用 S2S（或服务器到服务器）协议并选择最佳设置。但是，您可以使用一组配置参数来调整服务器行为，以在您的安装中实现最佳性能。
本文档描述了 Tigase 服务器配置的以下元素：
与外部服务器的并发连接数
连接吞吐量参数
发往外部服务器的数据包的最长等待时间和连接不活动时间
自定义插件选择连接到远程服务器
10.3.1. 并发连接数
通常只需要一个到远程服务器的连接就可以将 XMPP 节发送到该服务器。然而，在某些情况下，在高负载下，如果您打开到远程服务器的多个连接，您可以获得更好的吞吐量和性能。
当远程服务器以集群模式工作时尤其如此。理想情况下，您希望打开与远程服务器上每个集群节点的连接。这样，您可以在集群节点之间平均分配流量并提高 s2s 连接的性能。
Tigase 服务器提供 2 个不同的参数来调整并发 s2s 连接的数量：
max-out-total-conns- 此属性指定 Tigase 服务器打开到任何远程 XMPP 服务器的最大传出连接。这是 per domain 限制，这意味着此限制适用于 Tigase 连接到的每个远程域。如果设置为4，那么 Tigase 最多打开 4 个到jabber.org的连接加上最多 4 个到muc.jabber.org的连接，即使这是同一 IP 地址后面的同一物理服务器。要调整限制，您必须在
config.tdsl文件中添加以下内容：s2s { 'max-out-total-conns' = 2 }
max-out-per-ip-conns- 此属性指定 Tigase 服务器打开到任何远程 XMPP 服务器到其单个 IP 地址的最大传出连接。这也是 per domain 限制，这意味着此限制适用于 Tigase 连接到的每个远程域。如果设置为1，并且上述限制设置为4，并且远程服务器在 1 个 IP 地址后面可见，那么 Tigase 最多打开 1 个到jabber.org的连接 加上最多 1 个到muc.jabber.org和其他子域的连接。要调整限制，您必须在
config.tdsl文件中添加以下内容：s2s { 'max-out-per-ip-conns' = 2 }
10.3.2. 连接吞吐量
当然，每个人都希望他的服务器以最大吞吐量运行。这会带来资源成本，通常会增加内存使用量。如果您的安装中有大量 s2s 连接，这一点尤其重要。高吞吐量意味着每个 s2s 连接都有大量内存用于网络缓冲区。您可能很快就会用完所有可用内存。
有一个配置属性允许您调整 s2s 连接的网络缓冲区，以降低内存使用量或增加 s2s 通信的数据吞吐量。
有关更多详细信息，请参阅 net-buff-high-throughput 或 net-buff-Standard 属性描述。
10.3.3. 最大数据包等待时间和连接不活动时间
您可以为控制 s2s 通信的组件设置 2 个超时。
max-packet-waiting-time- 这设置了等待发送到某个远程服务器的数据包的最长时间。有时，由于网络问题或 DNS 问题，可能无法立即将消息发送到远程服务器。建立新连接可能需要一些时间，或者服务器之间可能存在通信问题，或者远程服务器可能已重新启动。 Tigase 在放弃之前会尝试几次连接到远程服务器。此参数指定数据包等待发送多长时间后返回给发送者并出现错误。超时以秒为单位指定：s2s { 'max-packet-waiting-time' = 420L }
max-inactivity-time- 此参数指定关闭之前的最大 s2s 连接不活动时间。如果一个连接长时间不使用，保持它打开并占用资源是没有意义的。 Tigase 在指定时间后关闭 s2s 连接，并在必要时重新连接。超时以秒为单位指定：s2s { 'max-inactivity-time' = 900L }
10.3.4. 自定义插件：选择 s2s 连接
有时对于非常大的安装，您可能希望设置更多到远程服务器的 s2s 连接，尤其是当它们在多个节点的集群中工作时。在这种情况下，您还可以控制与单个远程服务器的 s2s 连接之间的 XMPP 数据包分发。
这段代码是可插拔的，您可以编写自己的连接选择器。实现 S2SConnectionSelector 接口并使用 config.tdsl 文件中的以下参数在配置中设置您的类名就足够了：
s2s {
's2s-conn-selector' = 'YourSelectorImplementation'
}
默认选择器随机选择连接。
10.3.5. skip-tls-hostnames
s2s-skip-tls-hostnames 属性禁用 TLS 握手，以便 s2s 连接到选定的远程域。不幸的是，一些服务器（某些版本的 Openfire - [1] or [2]) 在 s2s 上进行 TLS 握手有问题，这会阻止建立可用的连接。这完全阻止了与这些服务器的任何通信。作为一种解决方法，您可以为这些域禁用 TLS 以恢复通信。可以在任何 vhost 上启用此功能，但必须在 s2s 组件下进行配置。
s2s {
'skip-tls-hostnames' = [ 'domain1', 'domain2' ]
}
10.3.6. ejabberd-bug-workaround
此属性激活 EJabberd 中的 s2s 实现中的错误的解决方法。即使回拨是预期/需要的， EJabberd 不会在 TLS 握手后在流功能中发送回拨。这会导致连接不可用，因为 EJabberd 也不接受此连接上的任何数据包。解决方法现在默认启用，直到没有错误的 EJabberd 版本足够流行。该解决方法的一个缺点是即使 SSL 证书完全受信任，也会始终执行回拨，理论上可以避免这种回拨。默认情况下，此功能未启用。
s2s {
dialback () {
'ejabbered-bug-workaround' = true
}
}
这替换了旧的 --s2s-ejabberd-bug-workaround-active 属性。
10.4. Tigase 负载均衡
Tigase 包含负载平衡功能，允许将用户重定向到最合适的集群节点。功能依赖于 see-other-host XMPP 流错误消息。该机制背后的基本原理是，如果实现返回的主机与用户当前尝试连接的主机不同，则用户将获得重定向。需要知道用户 JID 才能使重定向正常工作。
10.4.1. 可用的实现
Tigase 实现像往常一样是可扩展的，并允许实现 SeeOtherHostIfc 接口的不同的，可插入的重定向策略。
目前有三种可用的策略：
SeeOtherHost- 最基本的实现返回在config.tdsl文件中配置的单个主机或当前主机的名称；SeeOtherHostHashed（默认） - SeeOtherHostIfc 基于用户 JID 哈希值返回重定向主机的集群环境的默认实现；默认情况下，将从中进行选择的可用节点列表由所有连接的节点组成并反映所有连接的节点，或者可以在 config.tdsl 中配置主机列表；SeeOtherHostDB-SeeOtherHost 的扩展实现使用来自数据库的重定向信息，以user_id和node_id对的形式，给定的用户应该被重定向到。SeeOtherHostDualIP- 将内部 Tigase 集群节点与查找表匹配以提供相关的重定向主机名/IP（默认情况下将使用内部 Tigase tig_cluster_nodes 表）
10.4.2. 配置选项
最基本的配置是通过为每个连接器声明类来选择实际的重定向实现：
bosh {
seeOtherHost (class: <value>) {}
}
c2s {
seeOtherHost (class: <value>) {}
}
ws2s {
seeOtherHost (class: <value>) {}
}
可能的值为：
tigase.server.xmppclient.SeeOtherHosttigase.server.xmppclient.SeeOtherHostHashedtigase.server.xmppclient.SeeOtherHostDBtigase.server.xmppclient.SeeOtherHostDualIPnone- 禁用重定向
所有选项都是基于每个连接管理器配置的，因此所有选项都需要以相应的连接管理器 ID 为前缀，即 c2s、bosh 或 ws；我们将在示例中使用 c2s：
c2s {
'cm-see-other-host' {
'default-host' = 'host1;host2;host3'
'phases' = [ 'OPEN', 'LOGIN' ]
}
}
'default-host' = 'host1;host2;host3'- 用于重定向的主机的分号分隔列表。'phases' = []- 重定向应该处于活动状态的阶段数组，当前可能的值是：OPEN在打开 XMPP 流期间启用重定向；LOGIN在验证用户会话时启用重定向；
默认情况下，重定向当前仅在 OPEN 阶段启用。
SeeOtherHostDB
对于 SeeOtherHostDB 实现，还有其他选项：
c2s {
'cm-see-other-host' {
'db-url' = 'jdbc:mysqk://localhost/username?,password?'
'get-all-query-timeout' = '10'
}
}
db-url- 用于查询重定向信息的 JDBC 连接 URI；如果未配置，将使用默认的dataSource；get-host-query- 应返回重定向主机名的 SQL 查询；get-all-data-query- 一个 SQL 辅助查询，它应该从数据库返回所有重定向数据；get-all-query-timeout- 允许为执行的查询设置超时。
SeeOtherHostDualIP
这种机制将内部 Tigase 集群节点与查找表进行匹配，以提供匹配和相关的重定向主机名/IP。默认情况下，使用内部 Tigase tig_cluster_nodes 表（并且将使用适当的存储库实现）。
要启用此重定向机制，应使用配置/类。请注意，对于全局使用，所有连接管理器必须定义相同的类。您可以单独定义每个连接管理器。
bosh {
seeOtherHost (class: tigase.server.xmppclient.SeeOtherHostDualIP) {}
}
c2s {
seeOtherHost (class: tigase.server.xmppclient.SeeOtherHostDualIP) {}
}
ws2s {
seeOtherHost (class: tigase.server.xmppclient.SeeOtherHostDualIP) {}
}
它提供以下配置选项：
data-source- 重定向信息源的配置 - 默认情况下将使用内部 Tigasetig_cluster_nodes表（并将使用适当的存储库实现）；或者，可以使用eventbus源；db-url- 用于查询重定向信息的 JDBC 连接 URI；如果未配置user-db-uri其将被使用；get-all-data-query- 一个 SQL 辅助查询，它应该从数据库返回所有重定向数据；get-all-query-timeout- 允许为执行的查询设置超时；fallback-redirection-host- 如果不存在重定向信息（即未为特定节点配置辅助主机名），则不会生成重定向；这样就可以配置回退重定向地址。
所有选项均已配置或基于每个组件：
<connector> {
'cm-see-other-host' {
'data-source' = '<class implementing tigase.server.xmppclient.SeeOtherHostDualIP.DualIPRepository>'
'db-url' = 'jdbc:<database>://<uri>'
'fallback-redirection-host' = '<hostname>'
'get-all-data-query' = 'select * from tig_cluster_nodes'
'get-all-query-timeout' = 10
}
}
EventBus 作为信息源
可以利用 EventBus 和内部 Tigase 事件作为重定向数据的来源。为此，需要在 ClusterConnectionManager 中启用 eventbus-repository-notifications：
'cl-comp' {
'eventbus-repository-notifications' = true
}
10.4.3. 辅助设置选项
强制重定向
可以使用以下常规设置选项在连接管理器的特定端口上强制重定向连接，并将 force-redirect-to 设置为整数：
<connection_manager> {
connections {
<listening_port> {
'force-redirect-to' = <destination_port>
}
}
}
例如，为 c2s 连接管理器启用额外的端口 5322，并强制将所有连接重定向到端口 5222 （它将利用从 SeeOtherHost 实现中检索到的主机名，并且仅返回此类值时使用）：
c2s {
connections {
ports = [ 5222, 5322 ]
5322 {
'force-redirect-to' = 5222
socket = 'plain'
type = 'accept'
}
}
}
配置主机名
为了以自动化方式充分利用 SeeOtherHostDualIP 设置，现在可以提供主要（内部）和辅助（外部）主机名/IP（它们需要正确，InetAddress.getByName(property); 将用于验证正确性）。它可以通过 JVM 属性 tigase-primary-address 和 tigase-secondary-address 来完成。您还可以通过提供实现 tigase.util.DNSResolverIfc 接口的类作为 resolver-class 属性的值来利用DNS解析器的不同实现。这些属性可以通过 etc/tigase.conf 设置（取消注释以下行，或在环境中手动公开）：
DNS_RESOLVER=" -Dresolver-class=tigase.util.DNSResolverDefault "
INTERNAL_IP=" -Dtigase-primary-address=hostname.local "
EXTERNAL_IP=" -Dtigase-secondary-address=hostname "
或在 etc/config.tdsl 中（它们将被转换为 JVM 属性）：
'dns-resolver' {
'tigase-resolver-class' = 'tigase.util.DNSResolverDefault'
'tigase-primary-address' = 'hostname.local'
'tigase-secondary-address' = 'hostname'
}
10.5. 外部组件配置
Tigase 可以连接到外部组件，本指南将向您展示如何实现这一点。
配置遵循与所有其他组件相同的标准。它也更强大，因为单个 Tigase 实例可以控制多个 TCP/IP 端口和每个端口上的许多外部组件，甚至允许同一组件的多个连接。它支持具有协议自动检测机制的 XEP-0114 和 XEP-0225。协议是可插拔的，因此可以支持更多协议，或者可以添加对现有协议的自定义扩展。
该实现还支持脚本 API，并且可以在运行时使用 ad-hoc 命令添加带有密码的新域。可以加载新脚本以进一步控制所有连接的外部组件。
本指南中的页面详细描述了设置和管理外部组件的所有管理方面。
10.5.1. 外部组件配置
对于所有 Tigase 组件，您可以通过 DSL 配置 部分中详细描述的 config.tdsl 文件加载和配置外部组件。本文档描述了如何启用组件并设置初始配置以接受或启动外部组件的连接。
首先要做的是指定组件类和组件名称，这在 Tigase 安装中必须是唯一的。最常用的名称是 ext ，类是 tigase.server.ext.ComponentProtocol （使用默认名称时不必指定类）。
config.tdsl 中的以下行将在服务器启动期间加载组件：
ext (class: tigase.server.ext.ComponentProtocol) {}
虽然这会加载组件，但没有提供任何额外的配置，该组件实际上是无用的。有必要在运行时通过 ad-hoc 命令配置外部组件的虚拟主机域以使用该组件。
您可以另外配置 bind-ext-hostnames 属性。
要使用 Admin UI 配置外部组件连接，您需要打开 Admin UI 网页（如果您登录到默认情况下运行 Tigase XMPP 服务器的同一台计算机上，它应该在 http://localhost:8080/admin/ 可用）。然后您应该单击管理 UI 网页左侧的 Configuration，然后在 ext 组件上选择 Add new item 或在 ext 上使用具有 ad-hoc 能力的 XMPP 客户端的组件执行相应的 ad-hoc 命令 ，即 Psi。
您将看到一个表单，您应该填写该表单以配置外部组件连接详细信息：
域名 - 外部组件域名（
muc.devel.tigase.org）域密码 - 用于验证外部组件连接的密码 (
muc-pass)连接类型 -
accept使组件等待连接或connect强制组件连接到服务器（connect）端口号 - 组件应等待连接或尝试连接的端口（
5270）远程主机 - 连接到的主机（
devel.tigase.org）(如果组件只接受连接，可以留空)Protocol - 用于建立连接的协议 ID
如果连接类型是
connect:XEP-0114: Jabber Component Protocol (accept)- 用于 XEP-0114：Jabber 组件协议XEP-0225: Component Connections- 用于 XEP-0225：组件连接
如果连接类型是
accept:Autodetect- 用于自动检测传入连接使用的协议(推荐)XEP-0114: Jabber Component Protocol (accept)- 用于 XEP-0114：Jabber 组件协议XEP-0225: Component Connections- 用于 XEP-0225：组件连接
其他选项可能会保留默认值。
稍后，如果您想修改此值，可以使用管理 UI 通过单击在 ext 组件里的 Configuration 和 Remove an item 或 Update item configuration 或者通过使用具有 ad-hoc 能力的 XMPP 客户端在 ext 组件上执行相应的 ad-hoc 命令，即 Psi。
10.5.2. Tigase 作为外部组件
在某些情况下，您希望将一个或多个 Tigase 组件与主服务器分开部署，或者您可能希望运行一些连接到不同 XMPP 服务器的 Tigase 组件，或者您可能正在处理一个组件并且您不想重新启动每次进行更改时的主服务器。
有一种方法可以在 外部组件模式 下运行 Tigase 服务器。事实上，您可以将 Tigase 的任何组件作为外部组件运行，并通过 XEP-0114 或 XEP-0225 将它们连接到主 XMPP 服务器。
让我们看看例子……
与共享数据库一起使用（自 8.0.0 版起）
当您在 “external component mode” 下使用 Tigase 服务器 8.0.0 或更高版本，同时使用共享默认的 “user repository” 并且您的主服务器也运行 Tigase XMPP Server 8.0.0 或更高版本时，您可以从远程管理中受益来自主服务器的组件连接。要使用它，您需要通过在配置文件中添加以下行来在主服务器上启用外部组件和外部组件管理器：
'ext' () {}
'ext-man' () {}
有了它，您可以使用主服务器的 ext-man 组件中可用的管理 UI 或临时命令来配置 component 模式下运行的服务器的连接详细信息。
在管理 UI 中，您单击 Configuration 部分并在 ext-man 组件中选择 Add new item，这将显示以下表单以填写外部组件连接详细信息：
一个简单的案例 - MUC 作为外部组件
几个假设：
我们想为一个域运行一个 MUC 组件：
muc.devel.tigase.org和密码muc-pass主服务器工作在一个地址：devel.tigase.org 和相同的虚拟域
我们想使用 XEP-0114 协议和端口
5270连接到服务器。
这种情况有一种特殊的配置类型，它简化了将 Tigase 作为外部组件运行所需的设置：
'config-type' = 'component'
知道我们现在可以为 Tigase XMPP 服务器创建简单的配置文件：
admins = [ '[email protected]' ]
'config-type' = 'component'
debug = [ 'server' ]
'default-virtual-host' = [ 'devel.tigase.org' ]
dataSource {
default () {
uri = 'master_server_default_database_url'
}
}
userRepository {
default () {}
}
authRepository {
default () {}
}
muc (class: tigase.muc.MUCComponent) {}
ext () {
}
其中 master_server_default_database_url 与主服务器上用于默认数据源的 URL 相同。
有了这些，我们可以在主服务器上使用 ad-hoc 命令或管理 UI 来配置 Tigase XMPP 服务器以接受外部组件连接并从外部组件连接到主服务器。
使用管理 UI 将外部组件连接设置添加到管理器 (ext-man)。
你需要通过：
域名 - 外部组件域名（
muc.devel.tigase.org）域密码 - 用于验证外部组件连接的密码 (
muc-pass)连接类型 -
accept使组件等待连接或connect强制组件连接到服务器（connect）端口号 - 组件应该等待连接或尝试连接的端口（
5270）远程主机 - 要连接的主机（
devel.tigase.org）协议 - 用于建立连接的协议 ID
XEP-0114：Jabber 组件协议（接受） - 使用 XEP-0114：Jabber 组件协议 建立连接
XEP-0225: Component Connections- 使用 XEP-0225: Component Connections 建立连接
其他选项可能会保留默认值。
更多组件
假设您想在一个 Tigase 实例中运行多个组件作为外部组件。让我们在上面的配置中添加另一个 - PubSub 组件，看看如何设置它。
最直接的方法就是为组件域添加另一个组件到以组件模式运行的服务器
admins = [ '[email protected]' ]
'config-type' = 'component'
debug = [ 'server' ]
'default-virtual-host' = [ 'devel.tigase.org' ]
dataSource {
default () {
uri = 'jdbc:derby:/tigasedb'
}
}
userRepository {
default () {}
}
authRepository {
default () {}
}
muc (class: tigase.muc.MUCComponent) {}
pubsub (class: tigase.pubsub.PubSubComponent) {}
ext () {}
然后将新的连接域添加到主服务器外部组件设置和外部组件管理器设置。在只添加 MUC 组件作为外部组件时，您基本上做了同样的事情。
但是请注意，我们正在打开到同一服务器的两个连接。这会浪费资源并使系统过于复杂。例如，如果我们想运行更多的组件怎么办？为每个组件打开一个单独的连接有点矫枉过正。
事实上，有一种方法可以为作为外部组件运行的所有组件域重复使用相同的连接。属性 bind-ext-hostnames 包含一个逗号分隔的所有主机名（外部域）列表，这些主机名应该可以重复使用现有的连接。
然而，有一个问题。由于您正在重复使用连接（主机名绑定仅在 XEP-0225 中定义），因此您必须使用此协议来实现功能。
这是一个示例配置，通过两个外部域使用的 XEP-0225 协议进行单个连接：
admins = [ '[email protected]' ]
'bind-ext-hostnames' = [ 'pubsub.devel.tigase.org' ]
'config-type' = 'component'
debug = [ 'server' ]
'default-virtual-host' = [ 'devel.tigase.org' ]
dataSource {
default () {
uri = 'jdbc:derby:/tigasedb'
}
}
ext () {
}
userRepository {
default () {}
}
authRepository {
default () {}
}
muc (class: tigase.muc.MUCComponent) {}
pubsub (class: tigase.pubsub.PubSubComponent) {}
使用此配置，您无需在 ext-man 中为 PubSub 组件配置条目，只需为 MUC 组件配置条目，但您需要使用 client 作为协议字段的值。
使用单独的数据库
一个简单的案例 - MUC 作为外部组件
几个假设：
我们想为一个域运行一个 MUC 组件：
muc.devel.tigase.org和密码muc-pass主服务器工作在一个地址：devel.tigase.org 和相同的虚拟域
我们想使用 XEP-0114 协议和端口
5270连接到服务器。
这种情况有一种特殊的配置类型，它简化了将 Tigase 作为外部组件运行所需的设置：
'config-type' = 'component'
这会为 Tigase 生成一个配置，默认情况下只加载一个组件 - 用于外部组件连接的组件。如果您使用这种配置类型，您的 config.tdsl 文件可能如下所示：
admins = [ '[email protected]' ]
'config-type' = 'component'
debug = [ 'server' ]
'default-virtual-host' = [ 'devel.tigase.org' ]
dataSource {
default () {
uri = 'jdbc:derby:/tigasedb'
}
}
userRepository {
default () {}
}
authRepository {
default () {}
}
muc (class: tigase.muc.MUCComponent) {}
ext () {
}
要使这个新实例连接到 Tigase XMPP 服务器，您需要在 etc/externalComponentItems 处再创建一个具有外部连接配置的文件，该文件将被加载到本地数据库然后删除。
muc.devel.tigase.org:muc-pass:connect:5270:devel.tigase.org:accept
警告
虽然支持从 etc/externalComponentItems 文件加载配置，但我们建议尽可能使用共享数据库。将来可能会弃用此方法。
更多组件
假设您想在一个 Tigase 实例中运行多个组件作为外部组件。让我们在上面的配置中添加另一个 - PubSub 组件，看看如何设置它。
最直接的方法是在主服务器上使用 Admin UI 或 ad-hoc 命令为组件域添加另一个外部组件连接到主服务器。
然后我们可以在以 component 模式运行的服务器上使用以下配置：
admins = [ '[email protected]' ]
'config-type' = 'component'
debug = [ 'server' ]
'default-virtual-host' = [ 'devel.tigase.org' ]
dataSource {
default () {
uri = 'jdbc:derby:/tigasedb'
}
}
userRepository {
default () {}
}
authRepository {
default () {}
}
muc (class: tigase.muc.MUCComponent) {}
pubsub (class: tigase.pubsub.PubSubComponent) {}
ext () {
}
我们需要创建一个包含外部组件连接配置的文件，该文件将加载到内部数据库：
muc.devel.tigase.org:muc-pass:connect:5270:devel.tigase.org:accept
pubsub.devel.tigase.org:pubsub-pass:connect:5270:devel.tigase.org:accept
但是请注意，我们正在打开到同一服务器的两个连接。这会浪费资源并使系统过于复杂。例如，如果我们想运行更多的组件怎么办？为每个组件打开一个单独的连接有点矫枉过正。
事实上，有一种方法可以为作为外部组件运行的所有组件域重复使用相同的连接。属性 bind-ext-hostnames 包含一个逗号分隔的所有主机名（外部域）列表，这些主机名应该可以重复使用现有的连接。
然而，有一个问题。由于您正在重复使用连接（主机名绑定仅在 XEP-0225 中定义），因此您必须使用此协议来实现功能。
这是一个示例配置，通过两个外部域使用的 XEP-0225 协议进行单个连接：
admins = [ '[email protected]' ]
'bind-ext-hostnames' = [ 'pubsub.devel.tigase.org' ]
'config-type' = 'component'
debug = [ 'server' ]
'default-virtual-host' = [ 'devel.tigase.org' ]
dataSource {
default () {
uri = 'jdbc:derby:/tigasedb'
}
}
ext () {
}
userRepository {
default () {}
}
authRepository {
default () {}
}
muc (class: tigase.muc.MUCComponent) {}
pubsub (class: tigase.pubsub.PubSubComponent) {}
以及外部连接配置文件的示例：
muc.devel.tigase.org:muc-pass:connect:5270:devel.tigase.org:client
10.6. 集群模式下的外部组件负载均衡
本文档描述了如何使用 Tigase XMPP Server 对任何外部组件进行负载平衡，以及如何使 Tigase 的组件在集群模式下作为外部组件工作。
请注意，此处描述的所有配置选项都适用于 Tigase XMPP 服务器版本 8.0.0 或更高版本。
这些实际上是 2 个独立的主题：
一种是将负载分布在单个组件的多个实例上以处理更大的流量，或者可能实现高可用性。
第二是让 Tigase 的组件作为外部组件工作，使其工作在集群模式下，即使组件本身不支持集群模式。
以下是分步说明和配置示例，教您如何实现这两个目标。
10.6.1. 负载平衡外部组件
第一个也是最简单的场景是将外部组件的多个实例连接到单个 Tigase XMPP 服务器以分配负载。
至少有两个原因表明这将是最佳解决方案：一个是将负载分散到更多实例/机器上，第二个是提高可靠性，以防一个组件发生故障，另一个组件可以接管工作。
所以这里有一张显示用例的简单图片。
我们有一台运行 Tigase XMPP 服务器的机器和两个连接到 Tigase 的 MUC 组件实例。
在服务器端，我们将启用 ComponentProtocol 组件，因为我们需要在不支持集群的情况下启用外部组件。
然后使用 Admin UI，我们将在网页的 Configuration 部分中使用 Add item 位置为 ext 组件添加新的外部组件连接设置，就像在 External Component Configuration 部分描述的那样。
这里唯一的变化是我们将为字段 Load balancer class 指定值，我们将使用 ReceiverBareJidLB 作为值。
MUC 组件的两个实例的配置（两者相同）可以按照与 MUC 组件的单个实例相同的方式完成。这里没有什么可以改变的。
区别是服务器配置中的一个小元素。在 Add item 表单中的 Load balancer class 字段的值设置为 ReceiverBareJidLB。
这是负载平衡插件类。负载平衡插件决定流量如何在不同组件连接（即不同组件实例）之间分配。对于 MUC 组件，基于接收者裸 JID 分配流量是有意义的，因为这是 MUC 房间地址。这样，我们只需在不同的 MUC 组件实例上分配 MUC 房间和流量。
然而，这种分配策略并不总是适用于所有可能的组件。例如，对于传输，这根本行不通。为传输分配负载的更好方法是基于源裸 JID。如果你使用类名的插件这是可能的：SenderBareJidLB。
这是现在可用的两种基本负载分配策略。对于某些用例，它们都不够好。如果您有 PubSub，那么您可能希望基于 PubSub 节点分配负载。目前还没有插件，但很容易编写一个并将类名放入配置中。
10.6.2. 外部组件和集群
如果您想在没有实现集群的集群模式下使用 Tigase 的组件，有一种方法可以使其具有集群能力。在上一节中，我们将许多 MUC 组件连接到单个 Tigase 服务器。现在我们想将单个 MUC 组件连接到许多 Tigase 服务器（或许多 Tigase 集群节点）。
假设我们有 Tigase XMPP 服务器为域工作：xmpp-test.org 并且服务器安装在三个集群节点上：red.xmpp-test.org, green.xmpp-test. org 和 blue.xmpp-test.org.
我们希望能够将 MUC 组件连接到所有节点。为此，我们将 Tigase XMPP 服务器配置为在集群模式下运行，并且在每个集群节点上我们需要启用 ComponentProtocol 组件。
这可以通过在服务器配置文件中添加以下行来简单地完成：
ext () {}
完成此操作后，我们需要在网页的 Configuration 部分中使用 Add item 位置为 ext 组件添加新的外部组件连接设置，正如 外部组件配置 部分中所述。
如您所见，这里没有什么特别之处。最有趣的部分来自 MUC 方面，但从组件配置到与单节点 Tigase XMPP 服务器安装一起使用，这只是一个很小的变化。
当您使用管理 UI 添加/配置外部组件设置时（为 ext-man 组件 Add item 或 Update item configuration ）或使用单独的配置文件（当您不使用共享数据库时) 那么您需要将分号分隔的所有集群节点列表作为 Remote host 字段的值传递，外部组件应连接到这些节点。
在我们的例子中，它将是：
red.xmpp-test.org;green.xmpp-test.org;blue.xmpp-test.org
如您所见，远程主机名不是一个简单的域，而是一个带有几个逗号分隔部分的字符串。第一部分是我们的远程域，其余部分是要连接的主机地址。这可以是域名或 IP 地址列表。
当然，可以将多个外部组件连接到所有集群节点，这样整个安装将真正在集群中工作并且负载均衡。
10.7. 客户端到服务器通信
客户端到服务器的通信是 XMPP 通信的一个组成部分。 C2S 处理与服务器的所有客户端通信，并负责过滤和处理远程通信。可以禁用 C2S，但是这样做只会允许内部组件的通信和 S2S 通信。
10.7.1. 配置
要禁用 C2S，请在 config.tdsl 文件夹中使用以下行。
c2s (active: false) {}
否则，默认激活 C2S 组件。
10.7.2. 连接
连接容器包含与组件连接相关的所有配置。每个端口都可以单独配置。
c2s {
connections {
5222 {
<configuration>
}
5080 {
<configuration>
}
}
}
new-connections-throttling
该属性允许您限制服务器在特定端口上每秒接受的新用户连接数。在限制范围内建立的连接被正常处理，所有其他连接都被简单地断开。这使您可以避免服务器过载，以防有大量用户同时尝试连接。这通常发生在服务器重新启动后。
c2s {
connections {
5222 {
'new-connections-throttling' = 150L
}
}
}
在这里，这将连接尝试数限制为每秒 150 个连接，然后连接尝试被丢弃。
这取代了旧的 --new-connections-throttling 属性。
10.7.3. 恢复超时
现在可以设置服务器使用的默认流恢复超时。这允许控制服务器等待客户端重新连接的时间。这对于管理连接到您的服务器的移动客户端特别有用，因为它们可能没有完全覆盖，并且您不想立即关闭流。默认情况下，Tigase 将此值设置为 60 秒。
c2s {
'urn:xmpp:sm:3' {
'resumption-timeout' = 90
}
}
这会将默认超时设置为 90 秒。如果您愿意，您可以指定最大超时时间，这将允许服务器在连接关闭之前在默认值和最大值之间等待。
c2s {
'urn:xmpp:sm:3' {
'max-resumption-timeout' = 900
}
}
备注
如果未设置 max-resumption-timeout，它将始终等于 resumption-timeout 数，或者默认为 none 设置。
从 v7.1.0 开始可用
10.7.4. 数据包重新投递
通常数据包由 C2S 处理，并且通常在第一次运行时处理，但是如果发送失败，将在 60 秒后重试发送该数据包。如果第二次尝试失败，延迟将增加 1.5 倍。这意味着下一次重试将发生在 90，135 ..，直到达到重试计数。默认情况下，此计数为 15，但可以使用以下设置进行更改：
c2s {
'packet-deliver-retry-count' = '20'
}
此设置可防止数据包重新传递尝试持续到无穷大（或当主机内存不足时）。
10.8. Tigase 外部服务发现
欢迎使用 Tigase 外部服务发现组件用户指南。组件提供对 XEP-0215: External Service Discovery 的支持，它允许发现使用 XMPP 协议无法访问的外部服务。
10.8.1. 设置和配置
组件（在类 tigase.server.extdisco.ExternalServiceDiscoveryComponent 中实现）默认注册在名称 ext-disco 下并禁用。要启用它，您需要在配置中启用它。例子：
DSL 格式：
ext-disco () { }
此外，您需要通过以下方式在 SessionManager 中激活 urn:xmpp:extdisco:2 XMPP 处理器:
在 DSL 中 - 启用
sess-man的子 bean：sess-man { 'urn:xmpp:extdisco:2'() {} }
服务器返回的外部服务列表可以使用为此组件提供的临时命令进行配置。只有使用支持 AdHoc 命令的 XMPP 客户端或使用 Tigase Admin UI 的服务器管理员才能访问 AdHoc 命令。 AdHoc 命令的使用提供了简单和灵活的方法来添加，修改或删除将由发现返回的服务条目。