dwr的Reverse Ajax(推技术的实现之一)

本文介绍了DWR的ReverseAjax技术,包含主动模式(Polling和Comet)与被动模式(Piggyback)。详细对比了各种模式的特点及应用场景,并提供了配置示例。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

dwr的Reverse Ajax(推技术的实现之一)
----------------转载
dwr的逆向ajax其实主要包括两种模式:主动模式和被动模式。其中主动模式包括Polling和Comet两种,被动模式只有Piggyback这一种。

所谓的Piggyback指的是如果后台有什么内容需要推送到前台(即调用页面的js方法),是要等到那个页面进行下一次ajax请求的时候,将需要推送的内容附加在该次请求之后,传回到页面。

polling指的是由浏览器定时向服务端发送ajax请求,询问后台是否有什么内容需要推送,有的话就会由服务端返回推送内容。这种方式和我们直接在页面通过定时器发送ajax请求,然后查询后台是否有变化内容的实现是类似的。只不过用了dwr之后这部分工作由框架帮我们完成了。

comet模式指的的当服务端建立和浏览器的连接,将页面内容发送到浏览器之后,对应的连接并不关闭,只是暂时挂起。如果后面有什么新的内容需要推送到客户端的时候直接通过前面挂起的连接再次传送数据。




通过上面的解释我们可以看到,这三种模式都有各自的优缺点。从客户端请求次数的角度来说,当然是piggyback的模式最好。这个里面完全没有额外的网络请求,只有等到下次请求页面主动发起了,中间的变化内容才传递回页面。但是这也导致了这推送内容的延时,因为你完全没办法知道页面的下一次请求将在什么时候发起,也许页面永远都没有下一次请求。polling模式的网络请求最为频繁了,因为这时候页面不管后台有没有更新的内容,都需要发送请求询问。虽然这种模式可以通过增加请求间隔的时间来减少单位时间内的请求次数,但是这样同样会导致页面响应后台内容变化的间隔时间增长,这中间就产生了矛盾,具体的请求间隔时间还是要根据具体项目的需求来配置。比如服务器能承受的请求间隔和页面内容所需要的刷新频率。comet方式的响应速度应该是最快的,后台一旦有内容需要推送可以通过前面没有关闭的连接马上推送到前台。但是服务器所能提供的连接数目是一定的,在大量的挂起的连接没有关闭的情况下,可能造成新的连接请求不能接入,从而影响到服务质量。

配置
piggyback方式
dwr默认采用的是piggyback这种被动模式,如果需要采用这种模式的话不需要任何额外的配置就能完成。

comet方式
如果需要采用主动模式的话就需要进行一些相应的配置了,首先需要在web.xml中dwr的servlet中配置如下的参数:

<servlet>
<servlet-name>dwr-invoker</servlet-name>
<display-name>DWR Servlet</display-name>
<servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
<init-param>
<param-name>activeReverseAjaxEnabled</param-name>
<param-value>true</param-value>
</init-param>
</servlet>

在需要接受推送内容的页面body的onload事件中需要调用

dwr.engine.setActiveReverseAjax(true);

方法来启动该页面的ReverseAjax功能。这时候默认采用的将是comet的方式来完成页面内容的推送。

polling方式
如果想采用polling方式,只需要在comet方式的基础之上,在servlet参数中再加上如下的参数

<init-param>
<param-name>org.directwebremoting.extend.ServerLoadMonitor</param-name>
<param-value>org.directwebremoting.impl.PollingServerLoadMonitor</param-value>
</init-param>

其中页面默认的请求间隔时间是5秒,如果需要进行配置的话通过如下的参数来完成

<init-param>
<param-name>disconnectedTime</param-name>
<param-value>60000</param-value>
</init-param>
这就将请求间隔时间设为了60秒

调用方式
后台可以通过如下的方式来推送内容:

ScriptBuffer script = new ScriptBuffer();

script.appendScript("这里加入需要页面执行的js代码的字符串");
ServerContext sctx = ServerContextFactory.get(servletContext);
if (sctx != null){
Collection pages = sctx.getScriptSessionsByPage("这里加入待推送页面的相对路径,例如/book/list.jsp");
Iterator it = pages.iterator();
while(it.hasNext()){
ScriptSession session = (ScriptSession)it.next();
session.addScript(script);
}
}

其中的servletContext可以既可以是通过前台请求传入的,也可以是通过该类实现spring的ServletContextAware接口,由spirng注入的。并且在调用ServerContextFactory.get(servletContext)方法之前,dwr的上下文已经建立起来了。

在完成了以上工作之后就可以享受到dwr通过Reverse Ajax给你带来的惊喜体验了,你可以像cs模式中server直接操作client那样便利的操作browser了,赶紧来感受下吧。

dwr版本
本文讨论的配置都是针对在dwr3.0的环境中测试通过,按照dwr官网的说明应该在dwr2.0.4之后的版本都可以这样配置 。至于在这之前的版本需要进行的不同的配置请参考dwr官方网站的文档。
内容概要:论文提出了一种基于空间调制的能量高效分子通信方案(SM-MC),将传输符号分为空间符号和浓度符号。空间符号通过激活单个发射纳米机器人的索引来传输信息,浓度符号则采用传统的浓度移位键控(CSK)调制。相比现有的MIMO分子通信方案,SM-MC避免了链路间干扰,降低了检测复杂度并提高了性能。论文分析了SM-MC及其特例SSK-MC的符号错误率(SER),并通过仿真验证了其性能优于传统的MIMO-MC和SISO-MC方案。此外,论文还探讨了分子通信领域的挑战、优势及相关研究工作,强调了空间维度作为新的信息自由度的重要性,并提出了未来的研究方向和技术挑战。 适合人群:具备一定通信理论基础,特别是对纳米通信和分子通信感兴趣的科研人员、研究生和工程师。 使用场景及目标:①理解分子通信中空间调制的工作原理及其优势;②掌握SM-MC系统的具体实现细节,包括发射、接收、检测算法及性能分析;③对比不同分子通信方案(如MIMO-MC、SISO-MC、SSK-MC)的性能差异;④探索分子通信在纳米网络中的应用前景。 其他说明:论文不仅提供了详细的理论分析和仿真验证,还给出了具体的代码实现,帮助读者更好地理解和复现实验结果。此外,论文还讨论了分子通信领域的标准化进展,以及未来可能的研究方向,如混合调制方案、自适应调制技术和纳米机器协作协议等。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值