关于RSL的一段翻译

为了找出可以从代码中解决RSL服务端更新后,客户端必须手动清空浏览器缓存的问题,尝试翻译部分adobe的相关文档,希望能找到答案吧。。。

原文地址:

http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7add.html


 

为了克服这些限制,Flex提供了框架的运行时共享库,这些由Flex类库组成的包能被任何由Flex构建出来的应用所使用。框架运行时共享库预编译了框架的类和组件。

框架运行时共享库有两个版本:签名的和未签名的

 

  • 签名的运行时共享库呗缓存在一个特殊的Player缓存中,并且也在浏览器缓存中。他们能被任何应用读取,无论应用的域是什么。他们仅需要被客户端下载一次。当浏览器缓存被清空后,签名的框架运行时共享库任保留在特殊的Player缓存中。
  • 未签名的框架运行时共享库被缓存在浏览器缓存中,只能被此RSL下载时的域中的应用所读取。当浏览器缓存被清空后,未签名的框架RSL会呗移出,就像缓存中的其他文件一样。

默认情况下,框架运行时共享库会动态的连接到你的应用中去。当客户端读取一个应用时,如果客户端缓存中没有找到RSL,就会尝试去下载。通常,客户端会先读取Adobe域下签名的框架运行时共享库。RSL读取的位置和顺序是定义在一个叫做flex-config.xml的文件中的。你可以通过命令行方式或者使用Flash Builder中Flex Build Path properties面板中的 Library Path 面板来重写他们。

 

 

Flash Player 9.0.115或者起后的版本支持读取签名的框架运行时共享库。这些RSL能被不同域下的应用读取。这些框架运行时共享库被签名并且后缀是SWZ。

只有Adobe能创建签名的RSL,并且只有签名的RSL能被存储到Player的缓存中。如果你自己创建了一个包含自定义类库的RSL,是不能被签名的。如果用一个较先版本的Flash Player去尝试读取框架RSL,结果会跳过并读取到一个失效的RSL。

(Flex 4的应用需要Player10.0以上,所以这个不会成为你的问题。)

只有使用Flex 3或者更高版本的编译器,才能编译签名的框架运行时共享库,较早的版本是不能使用的。

 

已完成 用户现在需要理解从 ACS Server 到 TR143D 的整个流程,以及 RDP、RSL 这些组件的角色,结合之前的 rsl 代码分析。首先得先理清每个组件的含义和流程步骤。 首先,先拆解每个组件: ACS Server:Auto - Configuration Server,自动配置服务器,是 TR - 069(CWMP)协议里的管理端,负责远程管理终端设备(比如路由器),发起配置、诊断等操作。 HTTP Server:这里可能是设备(CPE,客户前置设备,比如路由器)上的 HTTP 服务,TR - 069 协议底层是基于 HTTP/HTTPS 传输 SOAP 消息的,所以设备上的 HTTP Server 负责处理 ACS 发来的 HTTP 请求,解析 SOAP 消息。 RDP:Remote Device Protocol?或者在 TR - 069 上下文里,RDP 是设备内部的 “Remote Device Proxy” 或者数据模型(DM)的访问层?实际上,TR - 069 中设备内部有数据模型(DM),RDP 可能是RDP(Remote Device Protocol)层,负责数据模型的读写操作,对接上层的 CWMP 协议和下层的业务模块(比如 RSL)。简单说,RDP 是设备内部处理 “如何读取 / 设置数据模型节点” 的中间层,把 ACS 的请求转化为对设备内部对象的操作。 RSL:结合之前的代码,RSL 是设备内部的一个模块,比如 “Router System Layer”(路由系统层),负责处理网络相关的业务逻辑,这里具体是 TR143 诊断功能的实现(TR143 是 TR - 069 的扩展,用于网络诊断)。 TR143D:TR143 Daemon,TR143 诊断后台进程,负责实际执行诊断操作(比如 ping、traceroute、nslookup 等)。 现在梳理流程: ACS Server → HTTP Server → RDP → RSL → TR143D 的流程解释: ACS Server 发起请求:ACS 作为管理端,通过 TR - 069 协议(基于 HTTP/HTTPS)向 CPE(路由器)发送诊断请求(比如要求执行 ping 诊断,设置DiagnosticsState=Requested)。 HTTP Server 接收请求:CPE 上的 HTTP Server 监听端口(通常是 7547),接收 ACS 的 HTTP 请求,解析其中的 SOAP 消息,提取出对设备数据模型(DM)的操作请求(比如修改Device.Diagnostic.IPPing.DiagnosticsState节点)。 RDP 处理数据模型操作:RDP 层负责数据模型的读写逻辑。当 HTTP Server 解析出请求后,RDP 会定位到对应的 DM 节点(比如 IPPing 的诊断对象节点),处理 “设置” 操作。RDP 要确保数据模型的一致性,处理参数验证、状态管理等。 RSL 处理业务逻辑:RSL 模块是 TR143 诊断的业务层。当 RDP 完成数据模型的设置后(比如把DiagnosticsState从 None 改成 Requested),RSL 会感知到状态变化,开始准备诊断所需的资源: 调用getTr143Interface获取诊断用的网络接口(比如 WAN 口、指定的 LAN 口); 调用getIppingRequestParm/getTraceRequestParm等函数,封装诊断参数(目标地址、数据包大小、超时等); 通过消息通信(比如CMSG_DIAG_START)通知 TR143D 执行诊断。 TR143D 执行诊断:TR143D 是后台进程,收到 RSL 的消息后,执行实际的诊断操作(比如发送 ICMP echo 请求实现 ping,或者发送 UDP 包实现 traceroute),收集诊断结果(丢包率、延迟、路由 hops 等)。诊断完成后,TR143D 把结果回传给 RSLRSL 再更新数据模型的状态(比如DiagnosticsState=Complete,并填充结果字段),最终通过 RDP、HTTP Server 把结果上报给 ACS。 各组件详细解释(针对初学者): ACS Server:可以想象成运营商的 “管理中心”,能远程管理千家万户的路由器。比如运营商想测试你家路由器到某个服务器的网络质量,ACS 就会发指令让路由器执行 ping 诊断。 HTTP Server(CPE 上的):路由器里专门用来 “接收 ACS 命令” 的服务。就像你家的 “快递收件员”,收到 ACS 寄来的 “命令包裹(HTTP 请求)”,然后拆包看里面的内容(SOAP 消息)。 RDP:路由器内部的 “翻译官 + 管家”。它把 ACS 的命令(比如 “去 ping 百度”)翻译成路由器内部数据模型能理解的操作,同时管理这些数据模型(比如记录 “现在要 ping 百度,参数是包大小 100,超时 1 秒”)。 RSL:路由器里的 “网络诊断专家”。它拿到 RDP 翻译后的诊断任务,去准备网络资源(比如选哪个网卡发数据包),然后指挥 TR143D 去做实际的 ping/traceroute。看之前的 rsl 代码,里面全是和诊断参数准备、接口选择、消息发送相关的函数,比如getTr143Interface选接口,rsl_setDev2DiagIppingObj处理 ping 诊断的参数和状态。 TR143D:路由器里的 “实干家” 进程。RSL 说 “去 ping 百度”,TR143D 就真的发 ICMP 包,记录每个包的延迟、是否丢包,然后把结果反馈给 RSL。 结合 rsl 代码看 RSL 的角色: 看之前提供的 rsl 代码,里面全是和 TR143 诊断相关的函数: 接口选择:getTr143Interface函数负责确定诊断用的网络接口(是选 WAN 口?还是根据默认网关选接口?还是处理 DS - Lite 这样的特殊接口?)。比如代码里: c Copy static CMM_RET getTr143Interface(...) { // 检查host是地址还是域名 // 处理interface非空的情况 // 从默认网关获取接口 // 处理DS-Lite等特殊场景 } 这部分是 RSL 在 “准备诊断资源”—— 选好出口,才能发诊断流量。 参数封装:getIppingRequestParm、getTraceRequestParm这些函数,把设备数据模型里的诊断参数(比如 ping 的包大小、超时)封装成 TR143D 能理解的消息结构体。比如: c Copy static CMM_RET getIppingRequestParm(DEV2_DIAG_IPPING_OBJ *pDiagIppingObj, IPPING_PARAM_MSG *pIppingParam) { // 获取协议版本、接口、DNS // 填充pIppingParam的各个字段(数据块大小、DSCP、超时等) } 这是 RSL 在 “把诊断任务翻译成 TR143D 的执行指令”。 消息发送与状态管理:rsl_tr143_startDiag函数向 TR143D 发启动消息;rsl_setDev2DiagIppingObj处理诊断状态的变更(比如从 Requested 到 Running 到 Complete),并在完成后上报结果。比如: c Copy CMM_RET rsl_tr143_startDiag() { CMSG_FD msgFd; CMSG_BUFF msgBuff; msgBuff.type = CMSG_DIAG_START; // 诊断启动消息 msg_connCliAndSend(CMSG_ID_COS, &msgFd, &msgBuff); // 发给TR143D } 这是 RSL 在 “指挥 TR143D 干活,并管理整个诊断流程的状态”。 整个流程的通俗比喻: 把路由器比作 “快递站”,ACS 是 “总部”: 总部(ACS)给快递站(路由器)发指令:“去测试下到百度的快递速度(ping 诊断)”。 快递站的前台(HTTP Server)收到总部的快递(HTTP 请求),拆开看里面的指令(SOAP 消息)。 前台把指令交给 “翻译室(RDP)”,翻译室把总部的指令转换成快递站内部的任务单(数据模型操作,比如 “诊断任务:ping 百度,包大小 100,超时 1 秒”)。 翻译室把任务单交给 “业务部(RSL)”,业务部负责准备资源:选哪个快递员(网络接口)去送?准备好快递单(诊断参数)。 业务部把任务交给 “快递员(TR143D)”,快递员实际去送包裹(发 ICMP 包),记录每个包裹的送达时间、是否丢失,然后把结果反馈给业务部。 业务部把结果更新到任务单上,翻译室再把任务单结果通过前台反馈给总部(ACS)。 这样整个流程就串起来了。RDP 是数据模型的中间处理层,负责指令的翻译和数据模型管理;RSL 是诊断业务的处理层,负责资源准备、任务下发、结果处理;TR143D 是实际执行诊断的后台进程。通过这样的分层,设备能高效处理 ACS 的远程诊断请求,完成从 “接收指令” 到 “执行诊断” 再到 “上报结果” 的闭环。 要理解 ACS Server → HTTP Server → RDP → RSL → TR143D 这个流程,需先明确每个组件的角色,再结合代码看 RSL 的具体作用。下面用 “分层拆解 + 通俗类比” 的方式讲解: 一、流程中各组件的含义 可以把整个流程理解为 “运营商远程让路由器做网络诊断” 的全链路,每个组件是链路中的 “分工角色”: 组件 全称 / 含义 类比(把路由器当 “快递站”,ACS 当 “总部”) ACS Server Auto - Configuration Server(自动配置服务器),是 TR - 069(CWMP)协议的管理端 快递公司 “总部”,远程给各个 “快递站(路由器)” 发指令(如 “测网速”) HTTP Server 路由器上的 HTTP 服务,TR - 069 协议基于 HTTP 传输 SOAP 消息 快递站的 “前台”,负责接收总部的 “指令包裹(HTTP 请求)” RDP Remote Device Protocol(远程设备协议层),负责数据模型(DM)的读写 快递站的 “翻译室”,把总部的指令翻译成内部能理解的 “任务单” RSL 结合代码,是处理 TR143 诊断业务 的模块(如 “路由系统层 Router System Layer”) 快递站的 “业务部”,负责准备资源、调度执行诊断 TR143D TR143 Daemon(TR143 诊断后台进程),负责实际执行诊断操作(ping/traceroute 等) 快递站的 “快递员”,实际去执行 “测网速” 的任务 二、全流程拆解:从 ACS 发请求到 TR143D 执行 整个流程是 “ACS 下诊断指令 → 路由器逐层解析并执行 → 结果回传 ACS” 的闭环,每一步的核心动作如下: 1. ACS Server 发起诊断请求 ACS 作为 “管理中心”,通过 TR - 069(CWMP)协议 向路由器(CPE,客户前置设备)发送诊断指令。 例:要求路由器执行 ping www.baidu.com,并把结果回传。 2. HTTP Server 接收并解析请求 路由器上的 HTTP Server 监听端口(如 7547),接收 ACS 发来的 HTTP 请求,并解析其中的 SOAP 消息(TR - 069 协议的载体)。 作用:把 “网络请求” 转化为 “路由器内部能理解的指令”(如修改数据模型节点 Device.Diagnostic.IPPing.DiagnosticsState 为 Requested)。 3. RDP 处理数据模型(DM)操作 RDP 是路由器内部的数据模型中间层,负责: 定位到对应的 数据模型节点(比如 “ping 诊断” 对应的 DEV2_DIAG_IPPING_OBJ 对象); 处理 “读 / 写数据模型” 的逻辑(如验证参数、更新状态)。 类比:“翻译室” 把总部的 “模糊指令” 翻译成快递站内部的 “明确任务单”(比如 “任务:ping 百度,包大小 100,超时 1 秒”)。 4. RSL 协调诊断资源与流程 RSL 是 TR143 诊断的业务层,核心职责是 “准备资源 + 调度诊断 + 处理结果”。结合你提供的 rsl 代码,它的关键动作包括: 资源准备: 调用 getTr143Interface 确定诊断用的网络接口(是走 WAN 口?还是 LAN 口?或 DS - Lite 隧道?); 调用 getIppingRequestParm/getTraceRequestParm 封装诊断参数(目标地址、数据包大小、超时、DSCP 等)。 调度诊断: 通过消息通信(如 rsl_tr143_startDiag 发送 CMSG_DIAG_START 消息),通知 TR143D 执行诊断。 结果处理: 诊断完成后,更新数据模型的状态(如 DiagnosticsState=Complete),并触发结果上报(通过 RDP、HTTP Server 回传 ACS)。 5. TR143D 执行实际诊断 TR143D 是路由器后台的诊断进程,收到 RSL 的消息后,执行实际的网络诊断操作: 若为 ping:发送 ICMP Echo 请求,统计延迟、丢包率; 若为 traceroute:发送带 TTL 的数据包,追踪路由 hops; 若为 nslookup:发起 DNS 查询,记录解析结果。 诊断完成后,TR143D 把结果回传给 RSL,由 RSL 完成后续的 “状态更新 + 结果上报”。 三、结合 rsl 代码看 RSL 的核心逻辑 你提供的 rsl 代码,正是 RSL 模块处理 TR143 诊断的核心实现,重点看以下函数的作用: 1. 接口选择:getTr143Interface c Copy static CMM_RET getTr143Interface(...) { // 1. 检查参数有效性(host、interface、proto 非空) // 2. 判断 host 是地址还是域名(调用 checkIfHostIsAddr) // 3. 若 interface 非空,校验接口的 IPv6 状态(支持双栈场景) // 4. 若 interface 为空,从“默认网关”自动获取接口 // 5. 处理 DS-Lite(IPv6 过渡技术)等特殊网络场景的接口 } 作用:确定诊断流量的出口接口,确保诊断包从正确的网卡发出(比如 WAN 口连运营商,必须从 WAN 口发诊断包)。 2. 参数封装:getIppingRequestParm/getTraceRequestParm 以 getIppingRequestParm(处理 ping 诊断)为例: c Copy static CMM_RET getIppingRequestParm(DEV2_DIAG_IPPING_OBJ *pDiagIppingObj, IPPING_PARAM_MSG *pIppingParam) { // 1. 检查 host 非空 // 2. 获取协议版本(IPv4/IPv6) // 3. 调用 getTr143Interface 获取诊断接口 // 4. 获取接口的 DNS 信息(IPv4/IPv6) // 5. 填充 ping 参数(数据块大小、DSCP、超时、诊断状态等) } 作用:把 “数据模型里的诊断配置” 转化为 “TR143D 能执行的参数”,让后台进程知道 “要 ping 哪个地址?用多大的包?超时多久?” 3. 诊断启动:rsl_tr143_startDiag c Copy CMM_RET rsl_tr143_startDiag() { CMSG_FD msgFd; CMSG_BUFF msgBuff; msgBuff.type = CMSG_DIAG_START; // 诊断启动消息类型 msg_connCliAndSend(CMSG_ID_COS, &msgFd, &msgBuff); // 发送给 TR143D return CMM_OK; } 作用:向 TR143D 发送 “启动诊断” 的消息,触发后台进程执行实际的诊断操作。 4. 状态与结果处理:rsl_setDev2DiagIppingObj c Copy CMM_RET rsl_setDev2DiagIppingObj(...) { // 1. 处理“仅修改配置,不触发诊断”的场景 // 2. 若诊断未完成: // - 状态变更时(如 DiagnosticsState 从 None→Requested),调用 getIppingRequestParm 准备参数 // - 发送“ping 配置消息”给 TR143D // 3. 若诊断完成: // - 发送“诊断完成消息”给 CWMP(TR069)上报结果 // - 更新数据模型的结果字段(如 IPAddressUsed) } 作用:协调诊断的全生命周期(从 “收到请求” 到 “执行中” 再到 “结果上报”),确保状态和结果的一致性。 四、总结:流程的核心目的 整个 ACS → HTTP → RDP → RSL → TR143D 流程,本质是 “运营商远程指挥路由器做网络体检,并回收体检报告” 的自动化过程: ACS 是 “指挥中心”,发指令; HTTP/RDP 是 “传令兵”,把指令翻译成内部任务; RSL 是 “指挥官”,协调资源、调度诊断; TR143D 是 “执行者”,实际完成 ping/traceroute 等诊断。 而 rsl 代码,就是 “指挥官” 的 “作战手册”—— 定义了如何选接口、封参数、发指令、收结果,确保诊断流程高效、准确地执行~ 如果对某段代码(如 getTr143Interface 或 rsl_setDev2DiagIppingObj)的细节还有疑问,可以指定函数,我再针对性拆解!
10-01
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值