SSCC-FDEPV5.7 消息传输系统已于 2022 年 8 月上线。
新版的消息传输客户端提高了处理能力，并丰富了产品功能，具体改进点如下：
一、处理性能
1. 优化代理功能时延
二、API 新增功能
1. 新增查询通信关系接口
2. 初始化接口支持传入 UserID
3. 新增查询对端 APPID 是否在线接口
4. 限制消息接口收发文件附件的大小
三、消息客户端新增功能
1. 支持国密算法
2. 支持信创平台
3. 新增速控确认机制
4. 提供获取监控信息的接口
5. 支持 EKey 热插拔
6. 新增收发失败包查询界面
7. 新增收发包失败告警
8. 新增界面配置代理功能
四、FDEAPI 开发中需要注意的问题
1.为什么需要使用长连接？
答：用户在使用 FDEAPI 的过程中，正确的用法是应当使用长连接。即一般只在程序的初始化部分调用 MrInit 函数(建立连接)，然后进行正常的收发包的操作，在程序退出时调用 MrDestroy。而不是每次来一个请求都调用 MrInit 连接一次，处理完成后释放。
2. 关于CorrPkgID的使用约定是什么？
答：如果用户调用 MrSend 函数发送的是业务应答包，对于 STUMsgProperty 参数中的 m_szCorrPkgID 字段，统一约定填写为与对应请求包中的 m_szPkgID 字段中相同的值，以方便请求方接收到应答包后，根据该字段查找对应的请求包。对于业务请求包或者其它类型的包，该字段填写为空(即’\0’)。
接收时，如果 STUMsgProperty 中的 m_szCorrPkgID 字段的值为空，则表示是一个请求包；否则表示为一个应答包。
3. 如果是同步处理，则当发出请求后，为什么需要循环等待接收？
如果用户对于发往 FDEP 平台的包使用的是同步接收方式，即通过 MrSend发送到 FDEP 平台后，然后等着接收应答的方式。对于这种处理方式，在开发时需要注意，发送完成后，如果立即接收，基本上可以肯定第一次是接收不到应答包的，因为应答包不可能象在本机运行一样这么快的速度就可以回来，必须等待一定时间才可以收到。其伪代码如下：
4. app1 和app2 的约定是什么？
答：一般来说，用户接收请求的 appID 约定为 app1。自己使用任意一个 appID 发送请求包到对方的 app1，对方的 app1 收到请求后，进行处理，处理完成后，根据请求方的源 UserID 和 appID，将应答发回给请求方。
5. API是线程安全的，但不是进程安全的，为什么？
答：API 是线程安全的，但不是进程安全的。通过调用 MrInit 一旦创建了句柄，该句柄在调用 MrDestroy 之前不会再改变。同一个句柄可以在同一个进程内的多个不同线程间使用，但不能在不同进程间使用，例如在 Unix 下 fork 之后，在主进程中创建的句柄不能再使用。
