dp2Capo Z39.50 功能增强和测试计划

[DigitalPlatform]

dp2Capo 近期增加了 Z39.50 服务功能，这部分功能需要进行测试。

安装和配置测试

• 新创建一个实例。如果没有专门修改过实例名，安装程序应该能自动给出一个实例名(实例数据子目录名)。确认后在实例列表里面会显示为正确的实例名(以前一度用过序号方式，后来改进了)

• 创建和修改实例的时候，会自动检查实例名是否和其他实例重复。

• 用 Windows 命令提示符，进入数据目录。这样 chordInstaller 中的实例配置对话框中，如果对这个实例进行了修改，最后又用“取消”退出对话框，Undo 机制就会发生作用，会把早先拷贝出去保存的目录拷贝回数据目录，这时候因为命令提示符的当前目录占据着，清除目录的操作会出错，由此可能造成 Undo 失败。需要测试发现可能出现问题，然后逐步解决

• 一个实例可以不启用 Z39.50 服务。

• 创建实例的时候，只有 dp2library 服务器参数的情况下，可以不用配置 MQ 路径。但如果同时也配置了 dp2mserver 服务器参数的情况下，会要求 dp2library 服务器参数中具有 MQ 路径。这是因为 dp2library 在推送消息给点对点服务器的时候，需要这个参数。

• 实例管理对话框可以点“取消”按钮退出，不但对实例配置的所有修改会还原，而且对全局参数的修改也会还原。请逐项检查还原的情况。

• 实例管理对话框刚进入的时候，并不会停止 dp2Capo 的服务。只是当双击某个实例打开实例对话框时，才自动停止这个实例的服务。实例对话框关闭后服务自动重新启动。

• “全局参数”按钮文字的开头会有一个加号或者减号字符，加号表示全局服务当前是处在运行状态，减少表示全局服务当前处在停止状态。点“全局参数”按钮会打开全局参数对话框，此时全局服务会自动停止。当对话框关闭后，全局服务会自动重启。

• 实例列表的上下文菜单中有命令可以启动或者停止全局服务。如果在按下“全局参数”按钮以前，全局服务本来就是停止状态，那么当全局参数对话框关闭的时候，也不会去启动全局服务。除非用实例列表的上下文菜单去专门启动一次。

Z39.50 功能测试

• 没有启用 Z39.50 服务的实例，在检索的时候应当不参与检索。应该返回报错说实例不存在。

• 一个实例虽然启用了 Z39.50 服务，但数据库一个也没有配置。检索时应当返回正确的错误码。错误码可以查 diag set 定义。

[DigitalPlatform]

关于 Search 的(结果集)替换指示符

Z39.50 Search 请求中，SearchRequestInfo 有个 m_lReplaceIndicator 成员，如果它为 true 的话表示检索时候在创建结果集之前，如果发现同名的结果集已经存在，则替换这个结果集。如果它为 false，如果同名结果集已经存在，则要返回出错，错误码为

  <item code="21" meaning="Result set exists and replace indicator off" addinfo="(unspecified)" />

目前暂时没有实现这个功能，默认是无论如何都替换。如果要实现这个功能，需要对 dp2kernel 的 Search() API 进行增强，也添加一个这样的 bool 参数。

[DigitalPlatform]

关于 chordInstaller 中 dp2Capo 实例管理界面的一些思考

目前 chordInstaller 在打开 dp2Capo 实例管理对话框的时候，还是传统的做法，即把所有 dp2Capo 实例都停止服务，然后等对话框关闭后自动重新启动所有 dp2Capo 实例。

后面考虑把这个做法改进为，在打开实例管理对话框的过程中，尽可能不要停止 dp2Capo 实例的服务。比如大部分配置操作，只涉及到对 capo.xml 和 config.xml 的修改，只需要在实例管理对话框关闭的时候，将修改涉及到的 dp2Capo 实例重新启动一次即可，修改的参数就兑现了。

但有一些配置修改，是对没有关闭的 dp2Capo 实例发生影响的。比如对 dp2Capo 所连接的 dp2library 服务器，修改了某些代理账户的密码，删除了某些账户等等。那么持续运行的 dp2Capo 实例会受到影响。对这类配置操作，可以考虑在操作进行前临时停止一下 dp2Capo 实例，然后等整个实例管理对话框关闭的时候再重新启动。

---

最终做出来的效果是，打开实例管理对话框的时候不会停止各个实例的服务。而打开某个实例对话框的时候会自动停止相关实例的服务，对话框关闭时会自动重启服务。

“全局参数”对话框也对应一个全局服务。打开和关闭的时候，会自动停止和重启全局服务。目前全局参数只影响到 Z39.50 端口和是否启用 Z39.50 服务。

[DigitalPlatform]

Z39.50 用量统计

希望增加 Z39.50 用量统计的功能

[DigitalPlatform]

用户名用法

用户名可以直接使用 dp2library 的工作人员账户。例如 public

还可以使用读者账户。不过，读者账户名前需要增加一个符号 '~' 以和工作人员账户名相区别。例如 ~R0000001

读者账户名除了可以使用证条码号以外，还可以使用下列几种形态：

1. 如果以"NB:"开头，表示姓名生日。姓名和生日之间间隔以'|'。姓名必须完整，生日为8字符形式。例如 ~NB:张三|19950101
2. 如果以"EM:"开头，表示email地址。例如 ~EM:email:xietao@dp2003.com
3. 如果以"TP:"开头，表示电话号码。例如 ~TP:13933445106
4. 如果以"ID:"开头，表示身份证号。例如 ~ID:320923198901142757
5. 如果以"CN:"开头，表示证件号码。例如 ~CN:C12345

[DigitalPlatform]

安全性、可靠性测试

• Z39.50 前端请求发送超大包测试。可以用 Initialize() 等任何一种功能来测试

• 一个 Present() 请求返回超多记录，突破 ExceptionalMessageSize 测试

[renyh]

20180921开发老师留言：

昨天我集中精力做了 dp2capo 的一些可靠性安全性方面的测试和加固工作。听到中间商用户反馈说 dp2capo 内存耗用一度达到 1G 以上，CPU 百分之九十多，我心里很纳闷。我这里做测试，100 个通道持续不断检索，dp2capo 内存耗用始终保持在 160 多M，CPU 1%（注：dplibraryxe CPU 50% 左右），没有任何那种失控的迹象。

每当遇到这种情况，就只有反求诸己，陷入深深的思考，搜寻一些蛛丝马迹。突然想到，Z39.50 请求包发给服务器的时候，服务器是有个函数负责运算看一个请求包是否到达完整。如果不完整，服务器就继续接收，不断扩大一个暂存请求包的 byte[] 对象。如果前端发来一个很大的请求包呢？我检查代码，SIP 服务器就有极限尺寸防范，Z39.50 服务器代码还没有来得及加入防范的语句。然后我就改造了代码

如何确定这个 nMaxLength。前端和服务器在 Initialize() 阶段会协商通讯包极限尺寸。在 dp2capo 代码里面这是个常量 --- 意思就是说不管前端说什么，服务器都会按照这个尺寸答复前端。Z39.50 协议本身对安全性考虑还是很周到的。这个极限尺寸，一般是要考虑正常情况下 Present() 响应能装下一批 MARC 记录，这样一种尺寸。特别是极端情况下，MARC 记录如果特别大，那么至少一个响应能包含一个完整的 MARC 记录。不然就只能用分片机制了。

除了新版本给用户使用观察以外，今天我还要着手编写一个超大请求包攻击的功能，对 dp2capo 做一下测试