UMS系统的配置比较复杂而多变,而且随版本的变化而略有所不同,但是也有基本的规律可以寻求。
1基本分类
UMS系统配置分为三大类:单网关配置、双网关配置和多网关配置。所有的配置属性均为大小写敏感,因此配置的时候务必谨慎。
1.1单网关配置(SimulatorCenter和SingleCenter)
单网关一般是由系统内部的独立类继承而来。这类网关一般为独立的模拟网关或模拟客户端。
这类配置特点是:只有一个<gateway>标签。
<gateway>
......
</gateway>
其他的相关配置都在这个标签内。如果有其他的<gateway>标签的配置,那么其他的配置都将被忽略。这个时候有且仅有第一个网关标签有效。<enable/>标签将对系统装载没有任何影响。
启动单网关的主类有两个:SimulatorCenter和SingleCenter。SimulatorCenter主要是模拟相关的网关动作,为发送系统提供模拟的接收和收条接口。SingleCenter主要是模拟相关的客户端的简单动作,可以连接到不同的网关系统上研究对方的连接过程和状态。
1.2双网关配置(DoubleCenter)
双网关配置是最简单的应用方式,一般一个网关作为对外接口,另外一个网关作为数据接口。例如:短信应用中,一个网关负责移动短信网关的接入,而另外一个负责数据库接入。
这类配置的特显是:一个标签是<inside>,另外一个标签是<outside>。
<inside>
......
</inside>
<outside>
......
</outside>
其中<outside>主要指明对外接口的网关配置;<inside>指明对内接口的网关配置。两个网关的数据是内部直接互联,不需要任何额外的路由配置。<enable/>标签将对系统装载没有任何影响。
启动双网关的主类只有一个:DoubleCenter类。DoubleCenter为用户提供了一个实际可用的最简网关模式。
1.2多网关配置(MultiCenter)
多网关一般是由超过两个以上的通讯网关在一个Java VM上运行。这类混合运行网关的配置特点是:由一个<config>引导出多个<gateway>配置。
目前启动混合运行网关的主类是: MultiCenter。它可以同时装载多个网关系统并运行。
在这个配置中,路由和网关的排列次序对系统的装载和运行没有任何影响。<gateway>装载受<enable/>标签控制,详细的装载过程请参看<gateway>的装载过程。
2基本模式
在所有的配置项目里面,属多网关配置最为复杂,项目最多。因此下面的介绍,主要以多网关配置介绍为主。
在多网关配置里面,主要的配置项目可以分成一下几个部分:
可以看出主要的配置要求有:基础属性、后台管理配置、路由配置和网关配置。
3基础属性
基础属性是整个系统的基本设定属性。目前基础属性仅有两个:(1)日志自动清理周期(clearLog);(2)系统初次运行时的线程数目(power)。
<config clearLog="14" power="4">
3.1日志自动清理周期(clearLog)
系统每天都会记录日志文件,长期运行以后,日志文件过大。很多情况下会占用大量磁盘空间。为了防止因为磁盘空间不够导致系统运行异常,设定自动清理周期。当日志文件的时间超出设定的周期外,系统将自动删除这些文件。
一般缺省的设置为14天,可以根据实际情况进行调整。
3.2系统初次运行时的线程数目(power)
系统内部有自己的线程管理机制。目前系统是采取了独占和共享线程的混合运行模式。这里的power主要是设置共享线程的数目。共享线程越多,系统的处理能力一般会越强;共享线程越少,系统的处理能力一般会越弱。共享线程越多,CPU的占用率也会偏高;共享线程越少,CPU的占用率也就越少。
一般缺省的设置为4个,可以根据实际情况进行调整。
4后台管理配置
UMS3系统已经摒弃了以前通过桌面客户端和Telnet方式管理网关的方式。现在全面采用基于页面的远程管理模式。对后台管理的配置,也就是配置Web服务的相关参数。
需要配置的主要参数有:(1)后台URL地址(url);(2)登陆用户名(account);(3)密码(password);(4)服务端口(port)。
4.1后台URL地址(url)
后台的url主要是指定后台的登陆用的地址。
如果只想限定通过本机访问,那么可以配置为:
http://localhost:8081
如果想设定通过互联网也可以访问,那么可以用公网IP配置该连接。例如:
http:// 221.194.139.253:8081
注意:url中的端口号,要和后面<servier>中的port属性数值保持一致。不然可能会导致登陆失败。
4.2登陆用户名(account)
登陆用户名是用于登陆系统后台的管理用户名。
一般缺省为forest_luo,可以根据实际情况自行设定。
4.3密码(password)
密码是用于登陆系统后台的密码。
一般缺省为root,可以根据实际情况自行设定。
4.4服务端口(port)
服务端口是用于提供Web服务的侦听端口。
一般缺省为8081,可以根据实际情况自行设定。
注意:如果8081端口被其他应用程序占用(包括其他UMS系统),那么将会导致系统启动失败。因此配置前,请先确认端口是否被占用。
另外,如果是因为这个原因导致系统无法启动,请检查是否原运行系统是否关闭,或者被意外多次启动。
5路由管理配置
路由管理配置主要是配置网关间的数据传递关系。在单网关配置和双网关配置中,不需要对路由管理进行任何配置。
路由类属于<assistant>范畴。它的类别由属性type进行区分。不同的类别配置情况有很多差异。
5.1属性type
属性type是一个字符串,且必须指定。
目前系统内置的路由属性如下:
|
属性值
|
说明
|
|
router.dump
|
主要用于Debug网关的接收信息。
此路由如果附着在某个网关上,它会不断提取该网关接收到的信息,并打印进入日志文件。也不会把数据传递给其他网关。
|
|
router.discard
|
主要用于抛弃网关的接收信息。
此路由如果附着在某个网关上,它会不端提取改网关接收到的信息,并直接抛弃。也不会吧数据传递给其他网关。
|
|
router.direct
|
主要用于直接简单路由模式。
此路由会简单连接两个网关直接的数据通路。从来源网关(source)提取数据,并传递给目标网关(destination)。
|
|
router.mapped
|
主要用于通过路由表来决定路由模式。
此路由会通过来源号码和目标号码特征来决定路由。相关配置选择项目由路由配置项目route决定。
|
|
|
|
5.2属性source
属性source是一个字符串,且必须指定。
通过配置属性source可以定义路由所附着的网关。属性source的内容为配置文件中的网关<gateway>名称属性(name)。
如果所配置的属性source不正确,或者在配置文件中无法找到对应的网关,那么系统将无法正常启动。
5.3属性destination
属性destination是一个字符串,在某些路由类型下必须指定。
通过配置属性destination可以定义路由终端所附着的网关。属性destination的内容为配置文件中的网关<gateway>名称属性(name)。
如果所配置的属性destination不正确,或者在配置文件中无法找到对应的网关,那么系统将无法正常启动。
5.4属性copy
属性copy是一个字符串,是一个可选择的路由字段。
通过配置属性copy可以要求路由将其处理的信息完全“拷贝”一份给由属性copy所指定的网关。这种方式一般用于信息复制处理,例如:监测、计费、统计等等。该属性在常规情况下可以不用配置。
如果所配置的属性copy不正确,或者在配置文件中无法找到对应的网关,那么系统将无法正常启动。
5.5属性logMessage
属性logMessage是一个布尔类型。如果不出现,则缺省为false。
通过配置属性logMessage可以定义是否记录通过路由的消息(Message)。在某些情况下需要诊断问题的来源时,可以使用此配置。一般情况下为了缩减日志规模,可以关闭。
5.6属性count
属性count是一个整数。如果不出现,则缺省为0。
通过配置属性count可以定义所需要的路由个数。当系统比较繁忙的时候可以通过提高数目来提高数据交换的效率。
一般缺省配置为1。如果配置为0则意味着不启动此路由。
5.7路由表
路由表是一种控制路由方式的配置表。这种表在系统中会在很多地方被使用。这里简单介绍一下它的配置和使用方法。常见路由表的表现形式可以如下:
<routeMap >
<route source=”*”
destination=”130*” priority=”1”>B</route>
<route source=”*”
destination=”135*” priority=”0”>C</route>
</routeMap>
路由表的关键部分是其内部的标签<route>相关属性和配置。其中属性source一般指定和来源号码相关的配置;属性destination一般指定和目标号码相关的配置;属性priority一般指定路由配置的优先级别。
上述这张路由表的意思就是:
(1) 如果来源号码为任意,目标号码以130开头,则路由到目标地址B。
(2) 如果来源号码为任意,目标号码以135开头,则路由到目标地址C。
(3) 其中(1)的路由配置比(2)的配置优先执行。
(4) 其余无法匹配的路由返回空目标地址。
5.7.1属性source
属性source主要指定来源的匹配方式。匹配方式一般分为精准匹配和模糊匹配。
(1) 精准匹配
精准匹配就是所匹配内容需要完全一致。例如:如果设定了source=“13501026991”,那么则要求来源号码必须是这个才可以满足匹配要求。其他来源号码匹配一律失败。
(2) 模糊匹配
模糊匹配就是所匹配内容需要开头部分一致即可。例如:如果设定了source=”135*”,那么只需要来源号码是135开头的就可以满足匹配要求。其他开头不符合的来源号码匹配一律失败。
如果设定了source=”*”,那么意味着任意来源号码都可以。也就是说属性source的匹配要求可以完全被忽略。
5.7.2属性destination
属性destination主要指定目标的匹配方式。其匹配方式可以参考5.7.1部分的介绍。
路由配置中,属性source和属性destination的匹配条件必须一起满足,才可以执行路由要求;只要一个不符合或者不匹配,则不执行路由要求。
5.7.3属性priority
属性priority主要指定了路由配置的匹配优先级别。级别越高则优先匹配,级别越低则最后匹配。如果级别相同则按照进入路由表的次序有系统自行决定。一般情况下指令匹配差异比较大的情况下,优先级的影响很小。但是当指令匹配差异比较小,而且出现歧义的时候,属性priority的关键作用就体现出来了。例如如下路由配置:
<routeMap >
<route source=” *”
destination=”1*” priority=”1”>B</route>
<route source=”1*”
destination=” *” priority=”0”>C</route>
</routeMap>
上述路由配置中的意义是:优先判断目标号码,如果目标号码有1开头则路由到目标地址B;然后如果来源地址以1开头则路到目标地址C。
把上述路由表的priority交换一下:
<routeMap >
<route source=” 1*”
destination=”*” priority=”1”>C</route>
<route source=”*”
destination=” 1*” priority=”0”>B</route>
</routeMap>
修改后的路由配置中的意义是:优先判断来源号码,如果来源号码有1开头则路由到目标地址C;然后如果目标地址以1开头则路由到目标地址B。
对于请求路由的数据,如果来源号码为13501026991到目标号码10086,那么显然在修改前是去往目标地址B;修改后会去往地址C。
5.8路由配置样例
以下提供相关路由的标准配置样例。
5.8.1配置router.dump
现在假设需要将网关(bjcmcc)的相关接收信息,记录到c盘的messagelog.txt中,则配置文件应该增加如下一行:
<assistant type=”router.dump”
source=”bjcmcc” file=”c:\temp\messagelog.txt”
count=”1”/>
其中file属性指定了记录文件的位置,而且该属性必须正确指定。
配置一旦生效并运行,网关(bjcmcc)所有的接收数据都将打印至该文件中,而且不会传递给其他的网关系统。
5.8.2配置router.discard
现在假设需要将网关(bjcmcc)的相关接收信息全部抛弃。则应该在配置文件中增加一行如下配置:
<assistant type=”router.discard” source=”bjcmcc”
count=”1”/>
配置一旦生效并运行,网关(bjcmcc)所有的接收数据都将被直接抛弃,而且不会传递给其他的网关系统。
5.8.3配置router.direct
现在假设需要将网关(bjcmcc)的相关接收信息全部转给SSMP数据库接口(smsdb)进行处理。则应该在配置文件中增加一行如下配置:
<assistant type=”router.direct”
source=”bjcmcc” destination=”smsdb”
count=”1” />
其中destination指定了目标网关,而且必须正确指定。
配置一旦生效并运行,网关(bjcmcc)所有的接收数据都将传递至SSMP数据库接口(smsdb)进行处理,而且不会传递给其他的网关系统。
5.8.4配置router.mapped
现在假设需要将网关(bjcmcc)的相关接收信息(状态报告除外)转给三个SSMP数据库接口(smsdb1、smsdb2和smsdb3)进行处理。其决定条件为目标号码:如果上行服务代码为106588881则转给数据库接口(smsdb1);如果上行服务代码为106588882则转给数据库接口(smsdb2);其余的全部转给数据库接口(smsdb3)。
则应该在配置文件中增加一行如下配置:
<assistant type=”router.mapped”
source=”bjcmcc” destination=”smsdb3”
count=”1” >
<route source=”*”
destination=”106588881*” priority=”1”>smsdb1</route>
<route source=”*”
destination=”106588882*” priority=”0”>smsdb2</route>
</assistant>
其中destination指定了缺省目标网关,而且必须正确指定。
配置一旦生效并运行,网关(bjcmcc)所有的接收数据(状态报告除外)都将按照路由表的配置进行处理。
5.8.5比较复杂的路由例子
(1)配置网关A和网关B双向互通。
解答:需要增加的两个路由配置如下:
<assistant type=”router.direct”
source=”A” destination=”B”
count=”1” />
<assistant type=”router.direct”
source=”B” destination=”A”
count=”1” />
(2)配置接收数据从网关A经过网关B到网关C。
解答:需要增加的两个路由配置如下:
<assistant type=”router.direct”
source=”A” destination=”B”
count=”1” />
<assistant type=”router.direct”
source=”B” destination=”C”
count=”1” />
(3)配置网关A的自回环信息传递。
解答:需要增加的一个路由配置如下:
<assistant type=”router.direct”
source=”A” destination=”A”
count=”1” />
6网关配置
配置网关主要是通过装载<gateway>标签来完成的。一个基本的<gateway>标签可以分为以下几个部分:
这些配置的前后次序对系统的装载没有任何影响。但是为了阅读方便,建议采用上述方式排列。可以看到网关的配置部分相当复杂,下面就针对这些部分依次介绍。其实大多数实际应用情况下,都是用标准的配置模板套用新的配置。
6.1基础属性
基础属性是指网关配置的基础属性配置。目前网关的主要基础属性有三个:(1)网关名(name);(2)网关类型(type);(3)会话关闭器数目(closer)。
<gateway name="bjcmcc" type="cmpp3" closer="2">
6.1.1网关名(name)
每个网关配置必须指定一个唯一的网关名。对于网关名的命名建议使用英文字母和数字组合。不建议使用中文或者其他字符。
网关名关系到系统运行的很多方面,包括:路由、授权、数据表达等等。因此网关名一旦确定,请勿随意修改,不然可能会导致数据丢失或者系统异常。
6.1.2网关类型(type)
每个网关配置必须指定一个唯一的网关类型。这些所支持的网关类型,由系统所确定。
目前系统所支持的类型如下:
|
属性值
|
说明
|
|
mute
|
哑网关。
该网关没有任何连接或者其他操作。但是有基础的数据队列,因此可以支持数据的进入,可以作为暂存系统使用。
|
|
reflect
|
自反网关。
该网关没有任何连接,具有基础的数据队列。可以将来自接收队列的数据,完全转移到发送队列中。通过扩展这种网关可以得到一些具有特定过滤功能的网关。
|
|
ssmp
|
支持SSMP协议的网关。
SSMP协议是UMS3内部的一个通讯协议。主要以支持短信息应用为主。
|
|
ssmp2
|
支持SSMP2协议的网关。
SSMP2协议是SSMP协议的扩展通讯可以。可以支持彩信、彩e、邮件等多媒体应用为主。
|
|
jssmp
|
支持SSMP协议的数据库网关。
其中content字段要求是二进制类型。
|
|
jssmp2
|
支持SSMP协议的数据库网关。
其中content字段要求是字符串类型。
|
|
jssmp.dj
|
为南宁点津公司特别提供的SSMP协议数据库网关。
|
|
jsmil
|
支持SSMP2协议的数据库网关。
可以支持彩信、彩e、邮件等多媒体应用为主。
|
|
jcmpp
|
支持CMPP2协议的数据库网关。
使用CMPP2协议与数据库直接进行数据交互。实质功能和jssmp系列类型没什么区别。
|
|
jcmpp3
|
支持CMPP3协议的数据库网关。
使用CMPP3协议与数据库直接进行数据交互。实质功能和jssmp系列类型没什么区别。
|
|
hcmpp
|
支持CMPP3协议的HTTP网关。
使用CMPP3协议字段作为HTTP交互的主要数据。可以通过HTTP的GET/POST方式传递CMPP3协议字段数据。
|
|
parlay
|
支持Parlay协议的网关。
|
|
parlay.ctcc
|
支持中国电信Parlay协议的网关。
|
|
parlay.csapi
|
支持中国网通Parlay协议的网关。
|
|
parlay.ericsson
|
支持爱立信Parlay协议的网关。
|
|
provision
|
支持中国移动Provision协议的网关。
|
|
mm7
|
支持彩信MM7协议的网关。
|
|
mm1
|
支持彩信MM1协议的网关。
|
|
l1
|
支持联通L1协议的LBS网关。
|
|
smpp
|
支持SMPP协议的网关。
|
|
smpp.fitel
|
支持台湾Fitel运营商SMPP协议的短信网关。
|
|
smpp.mobitai
|
支持台湾Mobitai运营商SMPP协议的短信网关。
|
|
smpp.kgt
|
支持台湾KGT运营商SMPP协议的短信网关。
|
|
smpp.logica.simulator
|
支持Logica
SMPP模拟器的短信网关。
|
|
smpp.huawei
|
支持华为SMPP协议的短信网关。
|
|
smpp.utstarcom
|
支持Utstarcom
SMPP协议的短信网关。
|
|
cmpp
|
支持中国移动CMPP1.2和CMPP2.0标准协议的短信网关。
|
|
cmpp3
|
支持中国移动CMPP3.0标准协议的短信网关。
|
|
location
|
支持中国移动Le/Ls标准协议的LBS网关。
|
|
cmpp.cmpp3.asiainfo
|
支持亚信CMPP3.0协议转CMPP2.0协议的短信网关。
|
|
cmpp.tssx
|
支持清华深讯CMPP1.2和CMPP2.0协议的短信网关。
|
|
cmpp.tssx2
|
支持清华深讯CMPP1.2和CMPP2.0协议的短信网关。
|
|
cmpp3.tssx
|
支持清华深讯CMPP3.0协议的短信网关。
|
|
cmpp.asiainfo
|
支持亚信CMPP1.2和CMPP2.0协议的短信网关。
|
|
cmpp3.asiainfo
|
支持亚信CMPP3.0协议的短信网关。
|
|
cmpp.asiainfo.international
|
支持亚信CMPP3.0协议的国际短信网关。
|
|
cmpp.ipai
|
支持艾派CMPP2.0协议的短信网关。
|
|
cmpp.intrinsic
|
支持英斯克CMPP1.2协议的短信网关。
|
|
cmpp.bisp
|
支持北纬通讯CMPP1.2协议的短信网关。
|
|
cmpp.sitech
|
支持斯特奇CMPP1.2协议的短信网关。
|
|
cmpp.talkweb
|
支持湖南拓维CMPP1.2协议的短信网关。
|
|
cmpp. aspiretech
|
支持卓望CMPP1.2协议和CMPP2.0协议的短信网关。
|
|
cmpp3. aspiretech
|
支持卓望CMPP3.0协议的短信网关。
|
|
cmpp. huawei
|
支持华为CMPP2.0协议的短信网关。
|
|
cmpp3. huawei
|
支持华为CMPP3.0协议的短信网关。
|
|
cmpp. neusoft
|
支持东大阿尔派CMPP2.0协议的短信网关。
|
|
cmpp3.neusoft
|
支持东大阿尔派CMPP3.0协议的短信网关。
|
|
smias
|
支持SMIAS1.2协议的短信网关。
|
|
smias.neusoft
|
支持东大阿尔派SMIAS1.2协议的短信网关。
|
|
sgip
|
支持中国联通SIGP1.0协议的短信网关。
|
|
sgip1
|
支持中国联通SIGP1.2协议的短信网关。
|
|
sgip2
|
支持中国联通SIGP1.2协议的全网短信网关。
|
|
sigp.opnet
|
支持傲天SGIP1.2协议的短信网关。
|
|
sigp.sitech
|
支持斯特奇SGIP1.2协议的短信网关。
|
|
sigp.huawei
|
支持华为SGIP1.2协议的短信网关。
|
|
smgp
|
支持中国电信SMGP1.x和SMGP2.x协议的短信网关。
|
|
smgp3
|
支持中国电信SMGP3.x协议的短信网关。
|
|
smgp.huawei
|
支持华为SMGP1.x和SMGP2.x协议的短信网关。
|
|
smgp3.huawei
|
支持华为SMGP3.x协议的短信网关。
|
|
smgp.zte
|
支持中兴SMGP1.x和SMGP2.x协议的短信网关。
|
|
smgp.zte.hubei
|
支持湖北中兴SMGP1.x和SMGP2.x协议的短信网关。
|
|
smgp. utstarcom
|
支持Utstarcom
SMGP协议的短信网关。
|
|
http
|
支持HTTP协议的网关。
|
|
ftp
|
支持FTP协议的网关。
|
|
|
|
|
|
|
以上协议还在不断增加中,UMS系统会根据这些网关的信息特征,做到最大兼容性。并根据这些兼容性扩展出不同的接口方式。完全可以做到只需要通过配置,就可以使得不同系统间完全相互兼容。
6.1.3会话关闭器数目(closer)
会话关闭器是专用用于关闭会话用的线程。系统内部线程管理模式为共享线程和独占线程的混合管理模式,为了防止在会话关闭过程中,大量占用共享线程。因此所有的关闭过程均由专门独占线程的会话关闭器实施。
关闭器数目的多少并不影响系统的工作效率。一般会话关闭器的数目设置为2。如果没有配置该项目,系统也会自动选择为2。这个数值一般也无需修改。如果网关链接非常频繁而且不稳定,那么则需要适当增加关闭器数目。
6.2有效标签
有效标签为<enable/>,无效标签为<disable/>。
通过这两个标签的控制,可以简单地开启或者关闭该网关是否在配置文件内生效或者不生效。当然,也可以使用删除、注释等手段来达到关闭网关配置的目的。
这个标签仅对多网关配置有效,单网关配置和双网关配置中,这个标签没有任何作用。
注意:网关配置被关闭以后,要注意是否有路由与之对应。如果路由启动时无法找到对应的网关将会报错,并最终导致系统启动失败。
6.3授权配置
授权配置是软件提供者对使用者的使用进行授权的标志。一般典型的授权配置如下:
授权配置标签为<licence>;属性MD5指定了相关配置的MD5验证;属性authenticate指定了被授权用户;标签<validate>一般指定了起始时间;标签<local>一般指定了本机物理地址和IP地址;标签<remote>一般指定了远程连接地址。
所有的网关程序不会在运行时加载相关授权配置,仅仅是在发起连接或者接收连接的时候检验相关授权配置。因此即使没有授权的网关系统,也是可以运行的,但是会出现无法连接或者接收异常的情况。而且在日志中会打印有关licence的相关错误提示。
因此如果有任何复制、拷贝或者挪动软件的要求,请及时联系我们。我们仅对通过我们正规授权的软件服务,提供维护、技术咨询等相关服务。任何使用“破解”方式导致软件运行异常的,我们不会提供任何技术支持。并保留法律追诉的权利。
6.3.1属性MD5
属性MD5说明了相关配置项目的MD5验证。任何一个相关配置的修改都会导致系统无法正常运行。因此请勿随意修改或者变更任何网关以及授权参数。
6.3.2属性authenticate
属性authenticate说明了授权对象。即该授权是给予哪个链接可能。
6.3.3标签validate
标签validate指明了授权的起始时间。其中from指定了授权的开始时间,to指定了授权结束时间。如果缺少该标签,则表明授权在时间上没有限制。
开始时间和结束时间的时间格式都是标准的“YYYY-MM-DD
hh:mm:ss”,请勿使用其他格式。
6.3.4标签local
标签local指定了授权给予的机器物理地址和IP地址。其中物理地址和IP地址必须严格配对。如果机器更换了网卡、更换IP等一系列影响机器物理地址和IP地址变化的动作,都会导致授权失败。
6.3.5标签remote
标签remote指定了一组远程访问的IP地址,即经过授权所允许的访问机器的IP地址。如果未经授权允许的机器进行访问,则系统会自动关闭相关链接。
如果remote设定为“*”,则意味着不限制远程访问机器的IP地址。
6.4验证配置
验证配置是登陆客户端和服务器所需要的验证信息。这个信息一般根据不同的类型的网关会有所变化。基本模式如下:
其中的name属性十分重要,是<authenticate>被引用的标志。
一个网关下可以容纳多个<authenticate>标签,也可以重名,但是有且第一个配置有效。
6.4.1属性name
属性name指定了配置参数的名称。这个名称将会被会话建立器所引用。在多会话路由控制中,该名称也会被路由器所使用。因此这个名字一般在一个网关配置内需要保持唯一性。缺省情况下的配置都是“whoami”。
6.4.2标签enterprise_code
属性enterprise_code指定了企业代码。
此属性在大多数SP接口网关配置中可以见到。如果填写了此项目,系统会根据配置自动检测相关项目。如果下行数据中相关项目缺失或者不匹配,则系统会自动进行纠正。如果不填写,则系统不检查该项目。
6.4.3标签service_code
属性service_code指定了服务代码。
此属性在大多数SP接口网关配置中可以见到。如果填写了此项目,系统会根据配置自动检测下行号码。如果下行号码确实或者与该号码不匹配,则系统会自动进行纠正。如果不填写,则系统不检查该项目。
6.4.4标签account
属性account指定了登陆用的用户名。
此属性在大多数网关配置中可以见到。
6.4.5标签password
属性password指定了登陆用的用户名。
此属性在大多数网关配置中可以见到。
6.4.6标签url
属性url指定了链接访问或者被访问的url地址。
此属性在大多数基于http服务的网关中可以见到。
6.4.7常见网关属性配置
下面列举一些常见网关的属性配置。
6.4.6.1短信CMPP的验证配置
6.4.7.2短信SGIP的验证配置
其中标签<enterprise_code>的属性area是长途区号。例如:武汉的长途区号就是0270。这个会决定SGIP网关接入的编号。
6.4.7.3短信SMGP的验证配置
需要注意的是<enterprise_code>是SMGP网关的节点编号。一般以3开头。
6.4.7.4短信CNGP的验证配置
需要注意的是<enterprise_code>是SMGP网关的节点编号。一般以3开头。
6.4.7.5网通Parlay短信的验证配置
其中标签<src_device_id>指明了来源设备号。这个参数主要用于订购关系处理,一般由网通方面提供。
6.4.7.6电信Parlay短信的验证配置
6.4.7.7数据库网关的验证配置
数据库网关一般包括:jsmil类型、jssmp类型、jssmp2类型等等。他们的配置基本相同。
其中标签<account>和标签<password>分别对应数据库的用户名和密码。
6.4.7.8彩信MM7网关的验证配置
其中标签<version>指定了MM7所使用的版本编号。另外系统会根据用户名和密码自动生成HTTP头中的Authenticate字段。验证方式为Basic,编码方式根据HTTP协议要求进行编码。
6.4.7.9卓望Provision网关的验证配置
其中标签<misc_id>指定了MISC的网关编号。这个参数一般由卓望公司指定并提供。
6.5可选择项目配置
在网关控制中有一些可选择项目可以进行配置。这些配置项目往往涉及网关的一些特殊功能。这里只简单配置项目所涉及的功能,不具体介绍该功能以及相关影响。这些部分可以参考《UMS系统特别功能概要》。
在大多数情况不用配置这些特别功能。如果不清楚这些功能的用途和可能产生的后果,请勿随意配置这些项目。如果需要请先请专业人士评估以后再做决定。
6.5.1标签<auto_self_control>
标签<auto_self_control>主要使用在基于包传输的网关配置中。
它的主要功能是要求网关进行发送流量自适应动作。即如果对方网关应答快,则我方网关提高发送速度;如果对方网关应答慢,则我方网关降低发送速度。完全无需人工干预。
6.5.2标签<schedule_supported>
标签<schedule_supported>主要用在基于包传输的网关配置中。
它的主要功能是指明对方网关支持定时发送功能,而不需要我方网关提供支持。缺省情况下系统自身支持定时发送功能。如果对方网关支持,则可以把这个任务交给对方网关来支撑,而避免我方网关支撑力度有限。
6.5.3标签<deliver_needed_report>
标签<deliver_needed_report>主要用在基于包传输的网关配置中。
它的主要功能是表明该网关支持上行的状态报告。一般情况下发送上行是不会提供任何状态报告的。设置了这个标签以后,网关发送上行如果成功,会给信息提供方反馈状态报告。
由于是针对上行的状态报告,因此主要用途是在服务端,而不是在客户端方面。
6.5.4标签<retrieve_status_report>
标签<deliver_needed_report>主要用在基于包传输的网关配置中。
它的主要功能是表明我方网关需要主动去提取状态报告。一般情况下,状态报告由对方网关向我方网关主动提供。但是有些情况下,可能还需要我方主动去提取。在这种情况下可以设置此标签。
此标签只针对某些特定类型的网关有效(例如:Parlay协议网关),对于其他类型网关基本没什么作用。另外配置了此标记以后,还需要相关的会话支持才可以实现完整的功能。因此常规情况下不用设置此功能。
6.6存储属性配置
存储属性主要是只配置网关的一些数据存储方面的设置。
6.6.1常见配置
系统常见存储类型有:(1)数据队列;(2)数据索引;(3)属性注册表。
系统常见存储方式有:(1)内存方式;(2)文件方式;(3)目录方式;(4)混合模式;(5)直接模式;(6)安全模式;(7)其他模式。
6.6.1.1属性type
属性type指定了队列类型和存储模式。
总体来说有以下一些常见配置类型:
|
|
数据队列
|
数据索引
|
属性注册表
|
|
内存方式
|
list
list.double
queue.priority
queue.classify
|
index.hashtable
|
properties.hash
properties.hashtable
|
|
文件方式
|
queue.file
queue.file.hash
queue.file.list
queue.file.double
queue.file.priority
queue.file.hash.classify
queue.file.list.classify
|
index.file
|
properties.file
|
|
目录方式
|
queue.directory
|
index.directory
|
|
|
混合模式
|
queue.mixed
queue.mixed.priority
queue.mixed.classify
|
index.mixed
|
properties.mixed
properties.mixed.fast
|
|
直接模式
|
queue.direct
queue.direct.priority
queue.direct.classify
|
|
|
|
安全模式
|
queue.safe
queue.safe.priority
queue.safe.classify
|
|
|
|
其他模式
|
queue.para
queue.para.classify
|
|
|
6.6.1.2属性cache
属性cache指定了队列内存缓冲区的大小。
单位是被缓冲对象的个数。
6.6.1.3属性size
属性size指定了文件的基本分区大小。
对象存储时,数据不能超越此极限数值。如果超越则需要更改此数值,或者更换存储方式。
6.6.1.4属性removable
属性removable指定了存储文件是否可以被抛弃。此属性仅对数据索引类型有效。
如果设置为true则表明在系统关闭后,该存储文件可以被抛弃;如果设置为false则表明在系统关闭后,该存储文件不可以被抛弃。
如果选择了基于内存的任何存储模式,属性removable没有任何意义。
6.6.1.5属性timeout
属性timeout指定了对象在文件中允许存储的时间。此属性仅对数据索引类型有效。
如果对象超出了存储的时间,并且被相关扫描线程监测到,那么数据会被从文件中提取,并按照相关流程进行处理。
如果选择了数据队列或者属性注册表的任何存储模式,属性timeout没有任何意义。
6.6.2数据队列
数据队列是系统最常使用一种数据结构。采取先进先出(First Input
First Output,FIFO)的基本原则。
其中属性type指定了队列的类型;属性cache指定了队列内存缓冲大小;属性size指定了文件的基本分区大小;属性removable指定了存储文件是否可以抛弃。
6.6.3数据索引
数据索引也是一种十分常用的数据结构。采取通过关键字(key,value)进行唯一配对的原则管理数据。
其中属性type指定了数据索引的类型;属性cache指定了队列内存缓冲大小;属性size指定了文件的基本分区大小;属性removable指定了存储文件是否可以抛弃;timeout指定了对象在文件中允许存储的时间。
6.6.4属性注册表
属性注册表也是一种十分常用的数据结构。其管理数据的方式和数据索引类似,唯一不同就是文件的最小分区固定为256字节,而且没有超时的概念。
其中属性type指定了属性注册表的类型;属性cache指定了队列内存缓冲大小;属性removable指定了存储文件是否可以抛弃。
6.7传输项目配置
网关中的传输项目根据网关的功能复杂性配置情况有所差异。这里以包传输网关为例。
其中<transmit>标签指定了有关数据存储的配置;<assistant>标签定义了有关数据操作的配置。
6.7.1标签<transmit>
定义了网关的消息传输队列。详细情况请参考6.6.2部分。
6.7.2标签<index>
定义了网关的消息数据索引。详细情况请参考6.6.3部分。
6.7.3标签<queue>
定义了网关的消息传输队列。详细情况请参考6.6.2部分。
6.7.4标签<request>
定义了网关的数据请求包传输队列。详细情况请参考6.6.2部分。
6.7.5标签<response>
定义了网关的数据应答包传输队列。详细情况请参考6.6.2部分。
6.7.6标签<assistant>
标签<assistant>是有关辅助线程的一些定义,例如:路由、包处理、链接管理等等。在这里标签<assistant>主要是和信息包(Message)的发送处理有关系。
主要属性包括:属性type、属性action、属性count。还有一些特别的设置将在下面的部分详细介绍。
6.7.6.1属性type
负责信息包(Message)的发送处理的类型如下:
|
属性type
|
简要说明
|
|
transmitter.packet.expired
|
处理超时的发送数据包。
|
|
|
|
|
transmitter.message.normal
|
处理发送常规信息数据包。
|
|
transmitter.message.failed
|
处理发送失败的信息数据包。
|
|
transmitter.message.expired
|
处理发送超时的信息数据包。
|
|
|
|
|
transmitter.report.normal
|
处理发送常规状态报告数据包。
|
|
transmitter.report.failed
|
处理发送失败的状态报告数据包。
|
|
transmitter.report.expired
|
处理发送超时的状态报告数据包。
|
|
|
|
6.7.6.2属性action
属性action定义了可选择的工作模式。
不同类型的线程,处理模式选择会有一定的差异,请看后面的详细介绍。
6.7.6.3属性retry
属性retry定义了可选择的重发次数。
缺省情况下,重发次数均为0。如果需要重发,则需要指定数值。
6.7.6.4属性count
属性count定义了可以选择的线程数目。
一般缺省定义都为1。如果设置为0,则意味着关闭该部分的功能。如果不清楚这个部分的功能用途,请勿随便设置为关闭状态,可能会导致意向不到的结果。
6.7.6.5处理超时的发送数据包(transmitter.packet.expired)
系统会从发送超时队列中提取超时的消息数据包进行处理。这个部分是消息定时发送处理功能的一部分。
可以选择的action基本如下:
|
action类型
|
简要说明
|
|
normal
|
(1)
如果消息是因为设置了定时发送而导致的,则进入消息发送队列。
(2)
如果超时消息是普通消息,则转移到超时消息队列等待处理。
(3)
如果超时消息是状态报告,则转移到超时状态报告队列等待处理。
|
|
discard
|
消息数据包将被直接抛弃。
|
|
retry
|
不支持retry操作,请勿配置该项目。
|
|
|
|
常规情况请将action配置为nomal即可。
6.7.6.6处理发送常规信息数据包(transmitter.message.normal)
系统会从网关的消息队列中提取等待发送的消息数据包进行处理。
可以选择的action基本如下:
|
action类型
|
简要说明
|
|
normal
|
(1)
正常情况下,将相关信息送入发送队列进行处理。
(2)
如果需要发送的信息已经超时,则按照信息配置要求进行超时处理。例如:返回状态报告“EXPIRED”。
|
|
discard
|
消息数据包将被直接抛弃。
|
|
retry
|
不支持retry操作,请勿配置该项目。
|
|
|
|
常规情况请将action配置为nomal即可。
6.7.6.7处理发送失败的信息数据包(transmitter.message.failed)
系统会从发送失败队列中提取等待处理的消息数据包进行处理。
可以选择的action基本如下:
|
action类型
|
简要说明
|
|
normal
|
(1)
如果消息包要了状态报告,则将错误写入状态报告中,并反馈输出。
(2)
如果消息包未要状态报告,则打印日志信息,并直接抛弃改数据包。
|
|
discard
|
消息数据包将被直接抛弃。
|
|
retry
|
(1)
将消息的发送重试(retry)次数减一,并重新进入发送队列。
(2)
如果重试全部完毕,则按照normal模式进行处理。
|
|
|
|
常规情况请将action配置为nomal即可。
6.7.6.7.1选择根据结果采取不同处理模式
另外该配置允许通过配置来决定所采用的动作模式一般配置例子如下:
<assistant type="transmitter.message.failed"
action="normal" retry=”3” count="1">
<result
value=”1” action=”retry”/>
<result value=”2”
action=”normal”/>
<result value=”3”
action=”discard”/>
</assistant>
其中标签<result>指明了失败原因数值及其对应的处理模式。上面的例子当中,当失败原因是1的时候,采取重发机制(且重发3次);当失败原因是2的时候,采取普通机制;当失败原因是3的时候,采取是直接抛弃。如果不是以上数值,则按照缺省的action处理。
对于重发机制应当谨慎配置,否则可能会导致意向不到的结果。一般对于何种错误应该采取重发动作,应该是在弄清楚大概的原因后再决定。如果单纯的让系统自行决定重发功能将会存在一定的风险。因为很多情况下,错误状态的数据即使再重发还是错误的。
6.7.6.8处理发送超时的信息数据包(transmitter.message.expired)
系统会从发送超时队列中提取超时而且没有得到对方应答的消息数据包进行处理。
可以选择的action基本如下:
|
action类型
|
简要说明
|
|
normal
|
(1)
如果消息包需要状态报告,则返回状态报告“NRESPON”;
(2)
如果消息包没有需要状态报告,则消息包被直接抛弃,并记录日志。
|
|
discard
|
消息数据包将被直接抛弃。
|
|
retry
|
(1)
将消息的发送重试(retry)次数减一,并重新进入发送队列。
(2)
如果重试全部完毕,则按照normal模式进行处理。
|
|
|
|
常规情况请将action配置为nomal即可。
6.7.6.9处理发送常规状态报告数据包(transmitter.report.normal)
系统会从状态报告队列中提取状态报告数据包进行处理。
可以选择的action基本如下:
|
action类型
|
简要说明
|
|
normal
|
将得到的状态报告数据包转移到网关的输出队列。
|
|
discard
|
状态报告数据包将被直接抛弃。
|
|
retry
|
(1)
取消状态数据包的状态报告标记,设置为普通消息。
(3)
将消息的发送重试(retry)次数减一,并重新进入发送队列。
(2)
如果重试全部完毕,则按照normal模式进行处理。
|
|
|
|
常规情况请将action配置为nomal即可。
6.7.6.9.1选择根据结果采取不同处理模式
另外该配置允许通过配置来决定所采用的动作模式一般配置例子如下:
<assistant type="transmitter.reoprt.normal"
action="normal" retry=”3” count="1">
<result
value=”ERR0001” action=”retry”/>
<result value=”ERR0002”
action=”normal”/>
<result value=”ERR0003”
action=”discard”/>
</assistant>
其中标签<result>指明了失败原因数值及其对应的处理模式。上面的例子当中,当失败原因是“ERR0001”的时候,采取重发机制(且重发3次);当失败原因是“ERR0002”的时候,采取普通机制;当失败原因是“ERR0003”的时候,采取是直接抛弃。如果不是以上数值,则按照缺省的action处理。
对于重发机制应当谨慎配置,否则可能会导致意向不到的结果。一般对于何种错误应该采取重发动作,应该是在弄清楚大概的原因后再决定。如果单纯的让系统自行决定重发功能将会存在一定的风险。因为很多情况下,错误状态的数据即使再重发还是错误的。
6.7.6.10处理发送失败的状态报告数据包(transmitter.report.failed)
系统会从失败的状态报告队列中提取状态报告数据包进行处理。
可以选择的action基本如下:
|
action类型
|
简要说明
|
|
normal
|
数据包将被直接抛弃。
|
|
discard
|
状态报告数据包将被直接抛弃。
|
|
retry
|
(1)
将消息的发送重试(retry)次数减一,并重新进入发送队列。
(2)
如果重试全部完毕,则按照normal模式进行处理。
|
|
|
|
常规情况请将action配置为nomal即可。
6.7.6.11处理发送超时的状态报告数据包(transmitter.report.expired)
系统会从发送超时的状态报告队列中提取状态报告数据包进行处理。
可以选择的action基本如下:
|
action类型
|
简要说明
|
|
normal
|
数据包将被直接抛弃。
|
|
discard
|
状态报告数据包将被直接抛弃。
|
|
retry
|
(1)
将消息的发送重试(retry)次数减一,并重新进入发送队列。
(2)
如果重试全部完毕,则按照normal模式进行处理。
|
|
|
|
常规情况请将action配置为nomal即可。
6.8接收项目配置
网关中的传输项目根据网关的功能复杂性配置情况有所差异。这里以包传输网关为例。
其中<receiver>标签指定了有关数据存储的配置;<assistant>标签定义了有关数据操作的配置。
6.8.1标签<receiver>
定义了网关的消息传输队列。详细情况请参考6.6.2部分。
6.8.2标签<index>
定义了网关的消息数据索引。详细情况请参考6.6.3部分。
6.8.3标签<queue>
定义了网关的消息传输队列。详细情况请参考6.6.2部分。
6.8.4标签<request>
定义了网关的数据请求包传输队列。详细情况请参考6.6.2部分。
6.8.5标签<response>
定义了网关的数据应答包传输队列。详细情况请参考6.6.2部分。
6.8.6标签<assistant>
标签<assistant>是有关辅助线程的一些定义,例如:路由、包处理、链接管理等等。在这里标签<assistant>主要是和信息包(Message)的发送处理有关系。
主要属性包括:属性type、属性action、属性count。还有一些特别的设置将在下面的部分详细介绍。
6.7.6.1属性type
负责信息包(Message)的发送处理的类型如下:
|
属性type
|
简要说明
|
|
receiver.packet.expired
|
处理超时的接收数据包。
|
|
|
|
|
receiver.message.normal
|
处理接收常规信息数据包。
|
|
receiver.message.failed
|
处理接收失败的信息数据包。
|
|
receiver.message.expired
|
处理接收超时的信息数据包。
|
|
|
|
|
receiver.report.normal
|
处理接收常规状态报告数据包。
|
|
receiver.report.failed
|
处理接收失败的状态报告数据包。
|
|
receiver.report.expired
|
处理接收超时的状态报告数据包。
|
|
|
|
6.8.6.2属性action
属性action定义了可选择的工作模式。
不同类型的线程,处理模式选择会有一定的差异,请看后面的详细介绍。
6.8.6.3属性retry
属性retry定义了可选择的重发次数。
缺省情况下,重发次数均为0。如果需要重发,则需要指定数值。
6.8.6.4属性count
属性count定义了可以选择的线程数目。
一般缺省定义都为1。如果设置为0,则意味着关闭该部分的功能。如果不清楚这个部分的功能用途,请勿随便设置为关闭状态,可能会导致意向不到的结果。
6.8.6.5处理超时的接收数据包(receiver.packet.expired)
系统会从接收超时队列中提取超时的消息数据包进行处理。
可以选择的action基本如下:
|
action类型
|
简要说明
|
|
normal
|
(1)
如果是超时的消息数据包,则转移到超时消息队列。
(2)
如果是超时的状态报告,则转移到超时状态报告对立。
|
|
discard
|
消息数据包将被直接抛弃。
|
|
retry
|
不支持retry操作,请勿配置该项目。
|
|
|
|
常规情况请将action配置为nomal即可。
6.8.6.6处理接收常规信息数据包(receiver.message.normal)
系统会从消息队列中提取消息数据包进行处理。
可以选择的action基本如下:
|
action类型
|
简要说明
|
|
normal
|
将获得的信息数据包转移到网关的输出队列。
|
|
discard
|
消息数据包将被直接抛弃。
|
|
retry
|
不支持retry操作,请勿配置该项目。
|
|
|
|
常规情况请将action配置为nomal即可。
6.8.6.7处理接收失败的信息数据包(receiver.message.failed)
系统会从接收失败的消息队列中提取消息数据包进行处理。
可以选择的action基本如下:
|
action类型
|
简要说明
|
|
normal
|
消息数据包将被直接抛弃。
|
|
discard
|
消息数据包将被直接抛弃。
|
|
retry
|
将消息转移到网关的输出队列。
|
|
|
|
常规情况请将action配置为nomal即可。
6.8.6.8处理接收超时的信息数据包(receiver.message.expired)
系统会从接收超时的消息队列中提取消息数据包进行处理。
可以选择的action基本如下:
|
action类型
|
简要说明
|
|
normal
|
如果信息数据包没有能等到状态报告,则返回状态报告“NREPORT”。
|
|
discard
|
消息数据包将被直接抛弃。
|
|
retry
|
(1)
如果设置了重试次数,则将重试次数减一,并重新发送该消息。
(2)
如果重试已经完毕,则按照normal模式进行处理。
|
|
|
|
常规情况请将action配置为nomal即可。
这个部分等于是处理等待状态报告超时的信息。如果在规定时间内没有得到状态报告,那么要么返回“NREPORT”状态报告;要么重新进入发送状态,即把发送流程和等待状态报告流程再走一遍。如果已经走了N遍还是同样的结果,则只能返回“NREPORT”状态报告。
6.8.6.9处理接收常规状态报告数据包(receiver.report.normal)
系统会从接收超时的状态报告队列中提取状态报告进行处理。
可以选择的action基本如下:
|
action类型
|
简要说明
|
|
normal
|
将状态报告数据包直接转移到网关输出队列。
|
|
discard
|
状态报告数据包将被直接抛弃。
|
|
retry
|
(1)
取消该状态报告的消息标识,设置为普通消息。
(2)
如果设置了重试次数,则将重试次数减一,并重新发送该消息。
(3)
如果重试已经完毕,则按照normal模式进行处理。
|
|
|
|
常规情况请将action配置为nomal即可。
6.8.6.10处理接收失败的状态报告数据包(receiver.report.failed)
系统会从接收失败的状态报告队列中提取状态报告进行处理。
可以选择的action基本如下:
|
action类型
|
简要说明
|
|
normal
|
状态报告数据包将被直接抛弃。
|
|
discard
|
状态报告数据包将被直接抛弃。
|
|
retry
|
不支持retry操作,请勿配置该项目。
|
|
|
|
常规情况请将action配置为nomal即可。
6.8.6.11处理接收超时的状态报告数据包(receiver.report.expired)
系统会从接收超时的状态报告队列中提取状态报告进行处理。
可以选择的action基本如下:
|
action类型
|
简要说明
|
|
normal
|
将状态报告数据包转移到网关的输出队列。
|
|
discard
|
状态报告数据包将被直接抛弃。
|
|
retry
|
将状态数据包送往发送队列进行重新发送。
|
|
|
|
常规情况请将action配置为nomal即可。
6.9数据包配置
数据包的配置主要是关于系统内部数据包收集和分发机制的配置。如果没有配置这个部分,那么系统不会对数据包进行任何处理。那么相关的应答处理和发送处理等机制都会失效。
这个部分的配置相对比较简单,目前只有一个收集和一个分发类型。如果网关内部需要调整,可以从这个部分入手进行相关扩展。一般情况下,可以不用调整。
6.9.1属性type
属性type指定了数据包处理机制的线程类型。
基本类型有如下几种:
|
type属性
|
简要说明
|
|
collector.packet
|
数据包收集器。
|
|
distributor.packet
|
数据包分发器。
|
|
|
|
|
|
|
6.9.2属性count
属性count指定了数据处理线程数目。
如果不填写该属性,则缺省数值为0。一般情况下填写为4。
6.10连接器和会话器配置
连接器和会话器配置是关于网关建立连接和会话方面的配置。这个部分决定了连接配置的相关细节问题,也是经常被关注的一个部分。配置是否正确会影响网关的工作情况。
一般正常工作的网关系统会由多个连接器和会话器配置。以保证网关可以执行接收和发送任务,缺少必要的配置会使得网关无法发送或者无法接收。不过个别情况下,有的网关也只需要处理发送或者只需要处理接收,减少配置可以减少系统消耗。
6.10.1连接器配置
连接器配置主要是配置建立连接的方式和一些相关参数。
6.10.1.1属性type
属性type指定了连接器的相关类型。
基本的类型和说明如下:
|
type属性
|
简要说明
|
|
connection.stream.accepter.socket
|
基于Socket的会话接收器。
|
|
connection.stream.connecter.socket
|
基于Socket的会话连接器。
|
|
connection.jdbc.connecter.api
|
基于JDBC API的会话连接器。
|
|
connection.jdbc.connecter.api2
|
基于JDBC API的会话连接器。
|
|
|
|
现在连接器基本以Socket接入方式为主。早期的UMS2还有基于文件和串口的会话接入器,因为用处很少,基本就被放弃了。目前的会话接入器已经能覆盖绝大多数应用,将来可以根据实际情况增加可以应用的会话接入器。
6.10.1.2属性authenticate
属性authenticate指定了连接器所需要使用的验证参数。
这些参数可以在验证配置部分可以找到,如果无法找到,那么可能会系统异常。请正确配置这个属性,以保证系统可以正常运行。缺省情况下一般配置“whoami”。
6.10.1.3属性count
属性count指定了连接器的个数。
一般配置为1。如果没有填写,则缺省认为为0。配置为0等于是不启用该连接器配置。
6.10.1.4基于Socket的会话接收器
这个部分主要是配置socket的侦听端口。
标签<socket>所包含的部分是所有有关侦听端口的配置。
6.10.1.4.1属性timeout
属性timeout指定了socket的读写超时时间。单位为秒。
一般当程序进行读写操作的时候,如果数据操作在一定时间内无法完成,则该连接会抛出异常。最终将导致该连接关闭。
一般缺省设置为5。如果不设置,那么系统会自动使用缺省数值15。不建议将这个数值设置过大。如果通讯异常可能会导致系统线程进入“死锁”状态。最终会导致更多共享线程落入“死锁”陷阱,而无法正常工作。
6.10.1.4.2标签local
标签local指定了一系列和本机相关的侦听配置。
一般情况下只配置属性port。如果在多网卡情况下需要指定在哪个网卡上侦听,那么则需要增加host项目。例如:
<local host=”192.168.1.253” port=”5858”/>
6.10.1.4.3属性host
属性host用来指定所需要绑定的主机IP地址。
常规情况下不用指定,除非特别指明需要绑定特定IP地址。
6.10.1.4.4属性port
属性port用来指定所需要绑定的主机端口。
该数值应该尽量避免和其他端口相互冲突,否则会导致系统无法正常启动。
6.10.1.5基于Socket的会话连接器
这个部分主要是配置socket的连接端口。
标签<socket>所包含的部分是所有有关连接端口的配置。
6.10.1.5.1属性timeout
属性timeout指定了socket的读写超时时间。单位为秒。
一般当程序进行读写操作的时候,如果数据操作在一定时间内无法完成,则该连接会抛出异常。最终将导致该连接关闭。
一般缺省设置为5。如果不设置,那么系统会自动使用缺省数值15。不建议将这个数值设置过大。如果通讯异常可能会导致系统线程进入“死锁”状态。最终会导致更多共享线程落入“死锁”陷阱,而无法正常工作。
6.10.1.5.2标签remote
标签remote指定了一系列和远程主机相关的连接配置。
一般情况下只配置属性host和port。如果在多网卡情况下需要指定在哪个网卡上绑定连接,那么则需要增加local以及起止端口配置。
6.10.1.5.3属性host
属性host用来指定所远程主机地址或者需要绑定的主机IP地址。
6.10.1.5.4属性port
属性port用来指定所需要绑定的主机端口。
该数值应该尽量避免和其他端口相互冲突,否则会导致系统无法正常启动。
6.10.1.5.5标签local
当需要绑定特定IP出口时,则需要增加标签local的配置项目。
例如:
<local host=”192.168.0.1” startPort=”9000” endPort=”9999”/>
出现这种配置情况的主要原因是主机有多块网卡,而对方允许连接的IP只有其中一个。两块网卡均可以连接到对方,显然另外一个网卡是不可以连接运营商设备的。但是操作系统的选择往往是未知的。所以这种情况下必须指定本机绑定配置。
一般指定绑定主机IP地址的情况下,还需要指定绑定端口。而且一个端口连接断开以后,可能还会被占用一段时间。为了避免相互之间的冲突问题,因此可以选择一个区间,让程序轮训使用。
6.10.1.5.6属性startPort
属性startPort用来指定所需要绑定的主机端口。
该数值应该尽量避免和其他端口相互冲突,否则会导致系统无法正常启动。
6.10.1.5.7属性endPort
属性endPort用来指定所需要绑定的主机端口。
该数值应该尽量避免和其他端口相互冲突,否则会导致系统无法正常启动。
6.10.1.6基于JDBC API的会话连接器
基于JDBC API的会话连接器主要是配置有关数据库连接参数。
目前系统可以直接支持的数据库包括:My SQL、SQL Server、Oracle、DB2等等。以上的配置是一个常见的简化配置方式。
6.10.1.6.1属性type
属性type指定了JDBC API的数据库类型。
目前系统支持的数据库类型如下:
|
type属性
|
简要说明
|
|
odbc
|
采用JDBC和ODBC桥连接。
|
|
mysql
|
MySQL
|
|
mysql.4
|
MySQL4
|
|
mysql.5
|
MySQL5
|
|
mysql.6
|
MySQL6
|
|
mssqlserver
|
MS SQL Server
采用TwFreeTds连接。
|
|
mssqlserver.6.5
|
MS SQL Server 6.5
采用TwFreeTds连接。
|
|
mssqlserver.7
|
MS SQL Server 7
采用TwFreeTds连接。
|
|
mssqlserver.2000
|
MS SQL Server 2000
采用TwFreeTds连接。
|
|
mssqlserver.7.ms
|
MS SQL Server 7
采用MS官方JDBC连接。
|
|
mssqlserver.2000.ms
|
MS SQL Server 7
采用MS官方JDBC连接。
|
|
oracle
|
Oracle
|
|
oracle.7
|
Oracle 7
|
|
oracle.8i.thin
|
Oracle 8i
采用Oracle官方JDBC连接(瘦客户端)。
|
|
oracle.9i.thin
|
Oracle 9i
采用Oracle官方JDBC连接(瘦客户端)。
|
|
oracle.10g
|
Oracle 10g
|
|
db2
|
DB 2
|
|
sybase
|
Sybase
|
|
postgresql
|
Postgresql
|
|
access
|
Access
|
|
access.97
|
Access 97
|
|
access.2000
|
Access 2000
|
|
foxpro
|
Foxpro
|
|
foxpro.97
|
Foxpro 97
|
|
foxpro.2000
|
Foxpro 2000
|
|
jdatastore
|
JDatastore
|
|
jdatastore.3.51
|
JDatastore 3.51
|
|
jdatastore.4
|
JDatastore 4
|
|
jdatastore.5
|
JDatastore 5
|
|
javadb
|
JavaDB
|
|
javadb.embedded
|
JavaDB Embedded
|
|
javadb.network
|
JavaDB Network
|
|
|
|
6.10.1.6.2标签parameters
标签parameters指定了连接数据库所需要的一系列参数。包括属性host,属性port以及数据库名称。
6.10.1.6.3属性host
属性host指明了数据库主机的地址。如果不指明则认为是本机。
6.10.1.6.4属性port
属性port指明数据库主机地址的端口。如果不指明,系统将根据数据库类型自行选择数据库服务器最常用的端口。
6.10.1.6.5标签driver
如果系统内建的JDBC驱动无法满足需要,或者需要外部使用JDBC驱动的时候,则需要指定此标签。
6.10.1.6.6标签url
如果系统内建的JDBC驱动无法满足需要,或者需要外部使用JDBC驱动的时候,则需要指定此标签。
如果配置中指定了此标签,则parameters相关配置自动失效。
6.10.1.6.7属性timeout
标签<jdbc>的属性timeout指定了JDBC连接的超时时间。单位为秒。
这个超时时间主要是设定JDBC连接在执行SQL语句所允许的最大时间。一般不指定的情况下,系统会自行使用缺省数值15。如果所执行的SQL语句超过这个最大设定,那JDBC将自动抛出异常,并放弃相关操作。
这样配置的最主要原因是防止系统的相关线程落入“死锁”陷阱,以保证系统可以正常工作。这种情况一般出现在,数据库中的数据量非常大,或者与某些应用程序形成了相互死锁。系统的主动放弃可能能给数据库一些恢复的机会。
6.10.1.6.8属性charset
标签<jdbc>的属性charset指定了JDBC连接所使用字符集。
例如:GB2312、UTF8、ISO8859-1等等。
如果此属性没有配置,系统会缺省选择GB2312。因此一般情况不需要特别指定。
6.10.2会话器配置
会话器的配置是配置有关连接会话的具体参数。即连接建立以后,如果与对方通讯的细节。
一般来说协议不同,会话的细节配置也会差异很多。这里就对常见的会话配置进行介绍。
6.10.2.1属性type
标签<session>的属性type指定了会话的基本类型。
不同的网关这个属性配置需要仔细选择。如果出现配置错误,会导致网关不会建立连接。
常见的会话基本类型如下:
|
|
server
|
client
|
|
|
transmitter
|
server.transmitter
|
client.transmitter
|
|
|
receiver
|
server. receiver
|
client. receiver
|
|
|
transceiver
|
server. transceiver
|
client. transceiver
|
|
|
|
|
|
|
(1) transmitter是发送处理。
一个连接上一方负责发送,另外一方负责接收。方向是从客户端到服务端。
(2) receiver是接收处理。
一个连接上一方负责发送,另外一方负责接收。方向是从服务端到客户端。
(3) transceiver是双向处理。
一个连接上双方可以同时进行(1)和(2)的操作。
6.10.2.2属性sync
标签<session>的属性sync用于指定会话是同步会话方式。
即一方发起操作后,需要等待对方应答了,才可以进行下一个步骤的操作。这种方式常见于一些类似Console操作方面的协议。例如:HTTP、SMTP、POP、FTP等等。
6.10.2.3属性async
标签<session>的属性async用于指定会话是异步会话方式。
即一方发起操作以后,没有必要等待对方应答,就可以进入下一个步骤的操作。这种方式常见与一些短信息网关的协议。例如:SMPP、CMPP、SGIP、SMGP、CNGP等等。
6.10.2.4属性count
标签<session>的属性count是指定会话建立的个数。
一般缺省为1。如果不填写,则系统会认为该数值为0。也就不会建立相关连接。
对于发送方来说,增加count数目,等于是增加发送连接数,也是等于增加发送能力;对于接收方来说,增加count数据,等于是增加接收连接数,也就是等于增加接收能力。
如果发送方实际连接数未达到设置数值,系统会自动增加连接,直到所有的连接均已成功建立为止。如果接收方连接数未达到设置数值,系统则会允许更多连接,否则会不理会任何请求。
6.10.2.5标签packet
目前标签paket主要是用于设置和数据包相关的配置。
目前仅有一个属性max和这个相关。
6.10.2.6属性max
标签<packet>的属性max用于指定数据包的缺省包大小。
通讯过程中,数据包不能超过此数据包大小。如果此数值不指定,则系统使用2048字节大小的数据包进行通讯。对于个别比较大的数据包需要设置此字段。例如:彩信通讯。
6.10.2.6标签timeout
标签timeout用于指定会话超时的条件。
目前是两个主要属性是:属性packet和属性message。任何一个超时条件满足,都会导致系统关闭连接。
6.10.2.7属性packet
标签<timeout>的属性packet用于指定最大无数据包超时的时间间隔。单位为秒。
这个属性的意义是:如果会话连接中,超过此时间仍然无数据包通过,则必须关闭此连接。
如果此数值设置为-1,则表示不检测该超时;如果此数值设置为0,则表示立即超时;如果此数值设置为n,那么意味着n秒后,如果连接中没有数据包,那么连接将自动关闭。
6.10.2.8属性message
标签<timeout>的属性message用于指定最大无消息包(即有实际意义的载荷)超时的时间间隔。单位为秒。
这个属性的意义是:如果会话连接中,超过此时间仍然无消息包通过,则必须关闭此连接。
如果此数值设置为-1,则表示不检测该超时;如果此数值设置为0,则表示立即超时;如果此数值设置为n,那么意味着n秒后,如果连接中没有消息包,那么连接将自动关闭。
6.10.2.9标签enquire
标签enquire用于指定会话的连接测试方式和时间间隔。
6.10.2.10属性initiative
标签<enquire>的属性initiative定义了主动活动测试的时间间隔。单位为秒。
如果此数值设置为-1,则表示不检测;如果此数值设置为0,则表示立即检测;如果此数值设置为n,那么意味着n秒后检测。
如果活动测试检测失败超过3次,系统则自动关闭此连接。
6.10.2.11属性passive
标签<enquire>的属性passive定义了主动活动测试的时间间隔。单位为秒。
如果此数值设置为-1,则表示不检测;如果此数值设置为0,则表示立即检测;如果此数值设置为n,那么意味着n秒内对方必须进行活动测试,否则认为被动活动测试失败。
如果被动活动测试检测失败超过3次,系统则自动关闭此连接。
6.10.2.12属性flux
标签<session>的属性flux用于控制会话的流量。单位为每秒数据包的个数。
如果不配置该属性,则意味着流量不受限制,系统将以最大的速度进行数据包发送;如果配置该属性,则意味这该会话的流量上限不能超过此数值。系统会将流量均衡到其他连接上,或者降低处理速度。
6.10.2.13标签build_when_data_available
这个标签定义了会话是在有数据的情况下才发起连接。在没有数据的时候,将会处于半开启状态。实际连接的建立要等到有数据以后才进行。
这个配置项目为兼容短连接和长连接创造了方便。一般在SGIP协议、MM7协议以及HTTP通讯协议中会用到这个通讯配置。去掉此标签,则表明会话是长连接方式。
6.10.2.14标签directory
这个标签定义了彩信多媒体数据存储的目录。这个配置项目仅对JSMIL类型网关的会话器配置才有效。
一般情况下系统会自动选择当前目录为工作目录,但是这种方式在实施彩信多媒体内容读取控制方面会比较麻烦。彩信的多媒体内容往往被集中存储在其他地方,需要单独指定。这种情况下就需要标签<directory>来指定路径。
注意:在配置此项目前,相关的子目录必须存在且已经创建。系统不会自动创建该配置目录。