xmpp_resolve

项目背景与战略目标

xmpp_resolve 是一个为 OpenHarmony 平台提供的 XMPP（Extensible Messaging and Presence Protocol）服务发现库，用于自动解析目标域名的连接端点信息，包括 DNS SRV 记录查询和备用 HTTP 路径探测。该项目属于后端网络基础设施的关键组件，是构建高可用 XMPP 客户端或网关的前置依赖。依托仓颉编程语言（Cangjie Language）1.0.0+ 的内存安全特性（杜绝因字符串处理或缓冲区操作引发的 CVE 漏洞）、强类型系统（确保解析结果结构正确）、轻量级异步模型（高效并发执行多源解析）以及 CJNative 高性能 FFI 能力（无缝调用系统 DNS API 或 HTTP 客户端），本项目旨在打造一个低延迟、高可靠、符合 RFC 标准的服务发现引擎，支撑仓颉生态在即时通信、物联网设备寻址等场景下的自动连接能力。

核心功能需求与技术规格

2.1 功能模块分解

2.2 非功能性需求规范

• 性能指标：单次解析 P99 延迟 < 300ms（含 DNS 超时回退），吞吐量 ≥5,000 解析/秒。

• 安全要求：所有域名输入经合法性校验；解析结果字段受强类型约束，杜绝注入风险。

• 可靠性：支持 DNS 超时自动回退至 HTTP 探测；网络异常路径全覆盖，无 panic。

• 可维护性：模块解耦清晰（DNS/HTTP 可插拔）；接口简洁，符合仓颉惯用法。

2.3 核心接口设计示例 (伪代码)

interface XmppResolver {
    // 解析 XMPP 服务端点（如 "example.com", "xmpp-client"）
    async fn resolve(self, domain: String, service: String) -> Result<Vec<Endpoint>, ResolveError>;
}

enum ResolveSource {
    DnsSrv,
    HttpWellKnown,
}

struct Endpoint {
    host: String,
    port: u16,
    priority: u16,
    weight: u16,
    source: ResolveSource,
}

enum ResolveError {
    DnsFailure(DnsError),
    HttpFailure(HttpError),
    NoRecordsFound,
    InvalidDomain(String),
}

项目交付物与实施路线图

3.1 阶段性交付物清单

• 第一阶段：DNS SRV 解析核心 + 单元测试（覆盖率≥95%） + 接口文档

• 第二阶段：HTTP 路径探测集成 + 多源调度逻辑 + 与 cj-xmpp-client_core 对接测试

• 第三阶段：性能调优报告 + 超时与重试策略 + 发布至 cjpm 仓库

3.2 项目实施路线图

技术实现规范与质量认证体系

4.1 仓颉语言专项质量规范

• 编码规范：100% 通过 cjfmt 格式校验；禁止动态字符串拼接构造 DNS 查询。

• 类型安全：所有网络输入经 Uri::parse 或 Domain::validate 校验；泛型用于结果聚合。

• 错误处理：所有 I/O 操作返回 Result<T, E>；错误类型枚举覆盖 DNS/HTTP 所有失败情形。

4.2 测试与验证标准

• 单元测试：覆盖 NXDOMAIN、空响应、多记录排序等边界场景，行覆盖率 ≥95%。

• 互操作测试：与公共 XMPP 服务（如 jabber.org）及私有部署（ejabberd）验证发现流程。

• 安全扫描：通过 cjpm lint --deny-unsafe 和输入验证静态检查。

4.3 文档与可维护性

• 所有 public 接口包含 Doc Comments，说明 DNS 与 HTTP 的 fallback 行为。

• 记录 SRV 记录优先级/权重处理逻辑、HTTP 探测路径选择等关键决策（ADR）。

• 提供 .cjpmrc 与贡献指南，明确构建与测试流程。

4.4 持续集成质量门禁

# PR 自动化流水线
cjpm fmt --check
cjpm build --release
cjpm lint --deny-warnings --deny-unsafe
cjpm test --all-features --coverage
cjpm bench

技术栈与开发环境

• 核心语言：仓颉编程语言（Cangjie Language）1.0.0+

• 构建与包管理：CJPM (Cangjie Package Manager)

• 依赖组件：系统 DNS resolver（通过 CJNative）、轻量级 HTTP 客户端（如 cj-http）

• 测试框架：@cangjie/test + mock DNS/HTTP 服务

• 环境要求：仓颉 1.0.0+ 标准工具链；CI 使用 cangjie-lang/cj-builder:1.0 官方 Docker 镜像

交付件

验收标准

1.功能

1. 三方库必须有明确的功能；

2. 如果参考对标库移值开发，功能与参考三方库保持一致。

2.资料

1. Readme：包含简介，软件架构，目录结构，下载安装（编译构建），接口说明，使用示例，约束限制，开源协议，参与贡献等内容；

2. Changelog，三方库版本需包含基本的修改说明。

3.标准遵从性（可选），三方库实现需满足对应协议或行业标准，举例

1. appquth：支持对OAuth 的PKCE扩展；

2. icu4j：支持unicode标准库，通用字符集ISO/IEC 10646。

4.性能目标

1. 性能敏感三方库接口运行性能持平对标三方库

5.开源协议遵从，必须包含License文件

1. 放置合适的开源License协议，建议Apache License Version 2.0；

2. 引用或参考开源三方库，需遵从开源协议。

6.网络安全要求

1. 满足基础的网络安全红线及隐私要求，符合安全编码规范。

过程质量要求