- 浏览: 2488539 次
- 性别:
- 来自: 杭州
-
文章分类
- 全部博客 (574)
- Book (62)
- Architecture (6)
- Java (39)
- Taobao (41)
- Distributed (4)
- Life (72)
- Database (7)
- Spring (16)
- Photography (15)
- Bicycle (41)
- Test (20)
- jBPM (8)
- Business (12)
- Movie (3)
- Ajax (15)
- Code (7)
- Eclipse (96)
- VIM (2)
- Music (6)
- Groovy (10)
- AutoHotKey (3)
- Dorado (10)
- Maven (7)
- Scrum (5)
- English (20)
- Financial (12)
- OSGi (3)
- Other (4)
- Tool (6)
- Browser (1)
- PPT (1)
- Project Management (4)
- Agile (6)
- Nosql (1)
- Search engine (6)
- Shell (2)
- Open Source (4)
- Storm (10)
- Guava (3)
- Baby (1)
- netty (1)
- Algorithm (1)
- Linux (1)
- Python (2)
最新评论
-
roy2011a:
https://github.com/ebottabi/sto ...
storm的序列化问题及与spring的结合方式 -
roy2011a:
能抗能打 写道哥们儿,你好!能共享下那个storm与sprin ...
storm的序列化问题及与spring的结合方式 -
Alick1:
兄弟,你之前是不是在深圳的正阳公司呆过啊?
storm的ack和fail -
liuleixwd:
先点个赞,写的非常好!有个问题请教下,如果我再bolt里不用e ...
storm的ack和fail -
yao-dd:
solr的facet查询
最近在看comet(server push)技术,经过一番google之后,大致理清了头绪,目前已经研究完一个开源的comet实现:pushlet([url]http://www.pushlets.com),包括前台的js,html代码以及后台的java代码,也基本搞清楚了关于pushlet的处理机制并且胡乱写了一部分pushlet的学习笔记,目前还在整理中,到时候将与大家分享!
接下来的打算看另外两个开源的comet实现:dwr 2.0的reverse ajax和dojo的io.bind(),
如果有志同道合者大家可以一起来研究共同提高!
概念
关于comet的最初定义来自这篇blog文章:http://alex.dojotoolkit.org/?p=545。
简单的说就是客户端发送一个请求,服务器接收它,并使用一个无限循环,将客户端需要的数据push到response中,并进行刷新,但是该response并不关闭,继续接收新的数据并刷新,直到客户端断开连接,该循环才结束退出。
我们可以认为ajax解决了单用户响应的问题,而comet则解决了在保证性能的前提下进行协同多用户的响应问题。
comet的优点在于它可以在任何时候向客户端发送数据,而不仅仅只是响应用户的输入请求。而发送数据是在一个已有的单连接上进行的。因此可以大大降低发送数据的延迟时间(建立connection的开销,以及客户端发送请求的等待时间)。
关于Event Web Server
comet技术的一个重要组成部分就是event-drived web server,目前商用的实现已经出现,如lightstreamer(http://www.lightstreamer.com),这个我没有仔细看,只是跑了一下他给出的demo,还行!开源的实现就是apache+jetty(还要加一个mod)这个我还没有具体用过!
有国人声称实现了comet server(http://cnc.agile.com/read.php?tid=319),还没去仔细研究,不知道如何。
pushlet目前使用的是client pull做法,当然它的server push也将在不久的将来实现,它没有声称只能在专用的event-drived web server上运行,目前在tomcat运行环境下是可以的,不知道最多能承受多少用户同时访问还有待考证!
comet新体验
我看了一下comet技术的一些实现,其中meebo(http://wwwm.meebo.com/)算是做的比较好的一个(gmail有谁用过?说说感受),我觉得它的web版本msn messager,比微软自己的web msn就要好用的多。
原因就在于普通web容器中线程与http连接之间一对一的关系:每个线程占用大量的cpu资源和内存资源,所以web容器中允许的http处理线程数是非常有限的,一般设置不会超过200。而我的CometServer里面使用线程池里面固定数量的线程来处理大量连接的:它们不断轮流去执行 Request 的 run()方法。
楼主可能不认同我的观点,我觉得你的线程池和你所讲的普通web容器的线程池没有本质的区别。理由如下:
你用jdk5的特性创建一个线程池,分配线程去执行Request的run,也就是说,其实还是用一个线程去执行了你的方法。假设初始化线程数为200,当你的池里的200个线程都在干活的时候,这个时候,第201个request,来了,你的socket.accept()可以接受到新的Request,但是池里仍然没有线程来供你干活了,会不会就停止响应了呢? 还是一个socket,一个线程来响应,这点和http web容器的线程池工作道理,本质是一样的。如果刚好run里的方法写得比较重的话,一样的是cpu和内存的杀手。
另外,http协议本身是无状态的,只是容器实现加上了httpSession的具体不同实现,而CometServer(不单指楼主的CometServer)要实时地保持着客户端连接的socket,保存request的状态信息,用户标识信息等,在性能上和实现难度上,是不是比http 的server实现,难度还要更高一点。欢迎大家热烈讨论
1.没有做过大规模测试,能支持多少说不上来。但和servlet的实现还是有挺大差别的:由一个线程池(线程池的大小自己设置)来处理所有的这些连接,而不是每个线程处理一个连接。web容器中,不能在servlet里面向下面这样写代码:
的原因就在于普通web容器中线程与http连接之间一对一的关系:每个线程占用大量的cpu资源和内存资源,所以web容器中允许的http处理线程数是非常有限的,一般设置不会超过200。而我的CometServer里面使用线程池里面固定数量的线程来处理大量连接的:它们不断轮流去执行 Request 的 run()方法。
2、CometAction不是一个Servlet,不能获得session。但事实上action很可能期望能取到session,所以我自己借助HttpSessionListener来管理了session,以便能够 CometAction 用request(非servletRequest)获得session。request的state是必要的:为了加快accept的速度,在accept的时候,没有解析request的信息,而是在run的时候去解析的,因此request至少有两个状态:分别代表解析前和解析后的。但在开发CometAction的时候可以不必关心request的状态,只要确保Action的execute()能执行你期望的逻辑就可以了。记住,action的execute是会被线程池中不确定的某些线程以不确定的间隔不断被执行的,当然间隔不会很大,具体大小视服务器总共接受了多少的连接以及线程池中有多少线程而定。
考,怎么开始喜欢使用感叹号了,一直没发觉这一点
楼主说的comet其实就是:
while(1) { printf("<html>xxx</html>"); fflush(stdout); }
CGI直接输出HTML或者JS到浏览器。
简单的说,就是这样,所以comet不存在什么新技术,没有什么神秘可言!瓶颈主要集中在web server这一块,一般成熟的comet商业应用都会有一套它自己专用的web server,比如lightstreamer就是这样!
现在还没时间去看comet server,希望在了解了其他几个comet实现之后能跟你交流交流!
总结的非常有道理,server push通过维持长连接来得到快速将数据push到所有已连接的客户端,正因为如此所以不能采用传统的http web server,必须使用专用的event-drived web server来解决keep-alived connection的问题。
所以comet也没有什么新技术,一个成熟的comet应用除了需要一定的客户端脚本和服务器端代码的支持还需要特定的web server的支持!而一个成熟的comet framework则需要对这些客户端脚本和服务器代码进行良好的封装并能与各种event-drived web server能进行很好的结合,目前还没有比较成熟的event-drived web server出现,因此comet应用也没有象ajax那样普及。
与ajax应用相比,comet技术主要适用于即时通讯,实时数据监控,多用户协同交互的系统,所以comet应该算是ajax的一个有力补充和延伸!
那现在一般怎么做的,都是定期刷新吗?
现在一般用flash通过socket与server通信,再用flash结合js输出,不再经CGI进程转手了。
楼主说的comet其实就是:
while(1) { printf("<html>xxx</html>"); fflush(stdout); }
CGI直接输出HTML或者JS到浏览器。
那现在一般怎么做的,都是定期刷新吗?
接下来的打算看另外两个开源的comet实现:dwr 2.0的reverse ajax和dojo的io.bind(),
如果有志同道合者大家可以一起来研究共同提高!
概念
关于comet的最初定义来自这篇blog文章:http://alex.dojotoolkit.org/?p=545。
简单的说就是客户端发送一个请求,服务器接收它,并使用一个无限循环,将客户端需要的数据push到response中,并进行刷新,但是该response并不关闭,继续接收新的数据并刷新,直到客户端断开连接,该循环才结束退出。
我们可以认为ajax解决了单用户响应的问题,而comet则解决了在保证性能的前提下进行协同多用户的响应问题。
comet的优点在于它可以在任何时候向客户端发送数据,而不仅仅只是响应用户的输入请求。而发送数据是在一个已有的单连接上进行的。因此可以大大降低发送数据的延迟时间(建立connection的开销,以及客户端发送请求的等待时间)。
关于Event Web Server
comet技术的一个重要组成部分就是event-drived web server,目前商用的实现已经出现,如lightstreamer(http://www.lightstreamer.com),这个我没有仔细看,只是跑了一下他给出的demo,还行!开源的实现就是apache+jetty(还要加一个mod)这个我还没有具体用过!
有国人声称实现了comet server(http://cnc.agile.com/read.php?tid=319),还没去仔细研究,不知道如何。
pushlet目前使用的是client pull做法,当然它的server push也将在不久的将来实现,它没有声称只能在专用的event-drived web server上运行,目前在tomcat运行环境下是可以的,不知道最多能承受多少用户同时访问还有待考证!
comet新体验
我看了一下comet技术的一些实现,其中meebo(http://wwwm.meebo.com/)算是做的比较好的一个(gmail有谁用过?说说感受),我觉得它的web版本msn messager,比微软自己的web msn就要好用的多。
评论
16 楼
hexiaodong
2006-10-23
唉,再说详细点,希望这次你能看懂。普通web服务器不能保持长连接,因为如果你想保持长连接,只有一个办法:那就要在servlet的service()方法内执行类似下面的代码:
service()方法里是有死循环的,这样的话,接受了一个长连接请求之后,这个线程就不能去处理其他的请求了。
但在我的CometServer中不是这样的,request中有run(),这个方法内不必有死循环来发送消息。而是线程池中的多个线程循环访问request对列中的request对象,并调用run()方法,run()执行完后立即从对列中取下一个request并执行run()。在request的run方法内,会根据url去执行一个action的execute方法。因此,你可以写一个不包含while(true){}的action来处理当前的request对象。这样,CometServer何须为每个request分配一个固定的线程?CometServer只是在执行run()的片刻为它分配了线程,但不象普通web 容器那样线程执行完的同时也把request销毁了。CometServer会把request重新插入对列,并在不久的将来再次执行它run()方法,以便把新的需要写入浏览器的消息发送出去。
while(true){ if(hasMsg()){ sendMsgToBrowser(); } }
service()方法里是有死循环的,这样的话,接受了一个长连接请求之后,这个线程就不能去处理其他的请求了。
但在我的CometServer中不是这样的,request中有run(),这个方法内不必有死循环来发送消息。而是线程池中的多个线程循环访问request对列中的request对象,并调用run()方法,run()执行完后立即从对列中取下一个request并执行run()。在request的run方法内,会根据url去执行一个action的execute方法。因此,你可以写一个不包含while(true){}的action来处理当前的request对象。这样,CometServer何须为每个request分配一个固定的线程?CometServer只是在执行run()的片刻为它分配了线程,但不象普通web 容器那样线程执行完的同时也把request销毁了。CometServer会把request重新插入对列,并在不久的将来再次执行它run()方法,以便把新的需要写入浏览器的消息发送出去。
15 楼
mineral
2006-10-23
hexiaodong 写道
原因就在于普通web容器中线程与http连接之间一对一的关系:每个线程占用大量的cpu资源和内存资源,所以web容器中允许的http处理线程数是非常有限的,一般设置不会超过200。而我的CometServer里面使用线程池里面固定数量的线程来处理大量连接的:它们不断轮流去执行 Request 的 run()方法。
楼主可能不认同我的观点,我觉得你的线程池和你所讲的普通web容器的线程池没有本质的区别。理由如下:
你用jdk5的特性创建一个线程池,分配线程去执行Request的run,也就是说,其实还是用一个线程去执行了你的方法。假设初始化线程数为200,当你的池里的200个线程都在干活的时候,这个时候,第201个request,来了,你的socket.accept()可以接受到新的Request,但是池里仍然没有线程来供你干活了,会不会就停止响应了呢? 还是一个socket,一个线程来响应,这点和http web容器的线程池工作道理,本质是一样的。如果刚好run里的方法写得比较重的话,一样的是cpu和内存的杀手。
另外,http协议本身是无状态的,只是容器实现加上了httpSession的具体不同实现,而CometServer(不单指楼主的CometServer)要实时地保持着客户端连接的socket,保存request的状态信息,用户标识信息等,在性能上和实现难度上,是不是比http 的server实现,难度还要更高一点。欢迎大家热烈讨论
14 楼
hexiaodong
2006-10-23
1.没有做过大规模测试,能支持多少说不上来。但和servlet的实现还是有挺大差别的:由一个线程池(线程池的大小自己设置)来处理所有的这些连接,而不是每个线程处理一个连接。web容器中,不能在servlet里面向下面这样写代码:
while(true){ if(hasMsg()){ sendMsgToBrowser(); } }
的原因就在于普通web容器中线程与http连接之间一对一的关系:每个线程占用大量的cpu资源和内存资源,所以web容器中允许的http处理线程数是非常有限的,一般设置不会超过200。而我的CometServer里面使用线程池里面固定数量的线程来处理大量连接的:它们不断轮流去执行 Request 的 run()方法。
2、CometAction不是一个Servlet,不能获得session。但事实上action很可能期望能取到session,所以我自己借助HttpSessionListener来管理了session,以便能够 CometAction 用request(非servletRequest)获得session。request的state是必要的:为了加快accept的速度,在accept的时候,没有解析request的信息,而是在run的时候去解析的,因此request至少有两个状态:分别代表解析前和解析后的。但在开发CometAction的时候可以不必关心request的状态,只要确保Action的execute()能执行你期望的逻辑就可以了。记住,action的execute是会被线程池中不确定的某些线程以不确定的间隔不断被执行的,当然间隔不会很大,具体大小视服务器总共接受了多少的连接以及线程池中有多少线程而定。
13 楼
ppeter
2006-10-19
我没有看过comet是什么东西,按照各位的讨论看来,这种技术可以运用到基于web的聊天程序实现.
最近几个月一直在做基于web的聊天程序,主要是运用了xmpp协议,关于这个协议的详细信息,大家不妨可以google一下.运用这个协议,有很多开源的组件包,比如smack.聊天的客户端和服务器端都有开源项目,我用过webchat,wildfire,等.推荐大家有需要的话可以去看看.
最近几个月一直在做基于web的聊天程序,主要是运用了xmpp协议,关于这个协议的详细信息,大家不妨可以google一下.运用这个协议,有很多开源的组件包,比如smack.聊天的客户端和服务器端都有开源项目,我用过webchat,wildfire,等.推荐大家有需要的话可以去看看.
12 楼
poiuyt373
2006-10-19
Comet就是保持长连接,一个请求就一直保持,除非自己实现web,否则很难实用
11 楼
jerry.li
2006-10-17
pushlet 性能并不是很好,不知道dwr2.0的push做的怎么样。如果性能得不到提升,那末comet技术还是不用的好。
10 楼
macrochen
2006-10-17
pi1ot 写道
我比较害怕和喜欢用感叹号的人交流,好像有个人在我面前冲着我大喊一样。
考,怎么开始喜欢使用感叹号了,一直没发觉这一点
9 楼
pi1ot
2006-10-17
我比较害怕和喜欢用感叹号的人交流,好像有个人在我面前冲着我大喊一样。
8 楼
macrochen
2006-10-17
pi1ot 写道
楼主说的comet其实就是:
while(1) { printf("<html>xxx</html>"); fflush(stdout); }
CGI直接输出HTML或者JS到浏览器。
简单的说,就是这样,所以comet不存在什么新技术,没有什么神秘可言!瓶颈主要集中在web server这一块,一般成熟的comet商业应用都会有一套它自己专用的web server,比如lightstreamer就是这样!
7 楼
macrochen
2006-10-17
hexiaodong 写道
我实现的Comet Server,如果用电信宽待访问地址是http://agile.com/read.php?tid=319。我凭兴趣随便做的,做好了不知道该在什么项目里用,就这么闲摆着。
如果想试一试的话,下载后,放到tomcat的webapps目录下就行,然后访问index.jsp或者login.jsp。你可以看到一个很简单的聊天室的效果。
因为时间不多,所以用了很讨巧的方式来实现的。没有修改tomcat的源代码,而是在contextLoader的时候,另外开了一个socket端口用来接受comet连接。
如果想试一试的话,下载后,放到tomcat的webapps目录下就行,然后访问index.jsp或者login.jsp。你可以看到一个很简单的聊天室的效果。
因为时间不多,所以用了很讨巧的方式来实现的。没有修改tomcat的源代码,而是在contextLoader的时候,另外开了一个socket端口用来接受comet连接。
现在还没时间去看comet server,希望在了解了其他几个comet实现之后能跟你交流交流!
6 楼
macrochen
2006-10-17
Lucas Lee 写道
我认为基于http的聊天类应用,自始自终都只有两类做法(如果有其他类别,请指正我),
1.client pull。用JS等定时去服务器取数据。
好处是保持了http server的无状态高并发,坏处是大量的pull动作其实是白费的。
2.server push。服务端的JSP等程序的响应永不关闭,定时输出新内容。
好处是有新内容才输出,比较节省带宽等资源,坏处是长期占用了连接,丧失了无状态高并发的特点。
连接时有状态长期保持还是相反,这个也是传统意义上C/S与B/S的一大区别。所以看上去C/S会比B/S的并发负载能力低。但C/S的响应会更灵活和快速。
所以,server push不会是一个没有副作用的解决方案,是否适合还要仔细权衡。
补充一点,还能用Applet、flash、COM做基于UDP的应用,但那跟QQ差不多了,不在HTTP协议应用的范围内。
1.client pull。用JS等定时去服务器取数据。
好处是保持了http server的无状态高并发,坏处是大量的pull动作其实是白费的。
2.server push。服务端的JSP等程序的响应永不关闭,定时输出新内容。
好处是有新内容才输出,比较节省带宽等资源,坏处是长期占用了连接,丧失了无状态高并发的特点。
连接时有状态长期保持还是相反,这个也是传统意义上C/S与B/S的一大区别。所以看上去C/S会比B/S的并发负载能力低。但C/S的响应会更灵活和快速。
所以,server push不会是一个没有副作用的解决方案,是否适合还要仔细权衡。
补充一点,还能用Applet、flash、COM做基于UDP的应用,但那跟QQ差不多了,不在HTTP协议应用的范围内。
总结的非常有道理,server push通过维持长连接来得到快速将数据push到所有已连接的客户端,正因为如此所以不能采用传统的http web server,必须使用专用的event-drived web server来解决keep-alived connection的问题。
所以comet也没有什么新技术,一个成熟的comet应用除了需要一定的客户端脚本和服务器端代码的支持还需要特定的web server的支持!而一个成熟的comet framework则需要对这些客户端脚本和服务器代码进行良好的封装并能与各种event-drived web server能进行很好的结合,目前还没有比较成熟的event-drived web server出现,因此comet应用也没有象ajax那样普及。
与ajax应用相比,comet技术主要适用于即时通讯,实时数据监控,多用户协同交互的系统,所以comet应该算是ajax的一个有力补充和延伸!
5 楼
LucasLee
2006-10-17
我认为基于http的聊天类应用,自始自终都只有两类做法(如果有其他类别,请指正我),
1.client pull。用JS等定时去服务器取数据。
好处是保持了http server的无状态高并发,坏处是大量的pull动作其实是白费的。
2.server push。服务端的JSP等程序的响应永不关闭,定时输出新内容。
好处是有新内容才输出,比较节省带宽等资源,坏处是长期占用了连接,丧失了无状态高并发的特点。
连接时有状态长期保持还是相反,这个也是传统意义上C/S与B/S的一大区别。所以看上去C/S会比B/S的并发负载能力低。但C/S的响应会更灵活和快速。
所以,server push不会是一个没有副作用的解决方案,是否适合还要仔细权衡。
补充一点,还能用Applet、flash、COM做基于UDP的应用,但那跟QQ差不多了,不在HTTP协议应用的范围内。
1.client pull。用JS等定时去服务器取数据。
好处是保持了http server的无状态高并发,坏处是大量的pull动作其实是白费的。
2.server push。服务端的JSP等程序的响应永不关闭,定时输出新内容。
好处是有新内容才输出,比较节省带宽等资源,坏处是长期占用了连接,丧失了无状态高并发的特点。
连接时有状态长期保持还是相反,这个也是传统意义上C/S与B/S的一大区别。所以看上去C/S会比B/S的并发负载能力低。但C/S的响应会更灵活和快速。
所以,server push不会是一个没有副作用的解决方案,是否适合还要仔细权衡。
补充一点,还能用Applet、flash、COM做基于UDP的应用,但那跟QQ差不多了,不在HTTP协议应用的范围内。
4 楼
pi1ot
2006-10-17
robbin 写道
pi1ot 写道
几年前的几乎所有国内的CGI聊天室都是这么搞得,活生生把无状态高并发的HTTP给挤兑成了个占用Server端一个进程的长连接,服务器支持的并发数直线下降。
现在已经没这么玩得啦。
现在已经没这么玩得啦。
那现在一般怎么做的,都是定期刷新吗?
现在一般用flash通过socket与server通信,再用flash结合js输出,不再经CGI进程转手了。
楼主说的comet其实就是:
while(1) { printf("<html>xxx</html>"); fflush(stdout); }
CGI直接输出HTML或者JS到浏览器。
3 楼
robbin
2006-10-17
pi1ot 写道
几年前的几乎所有国内的CGI聊天室都是这么搞得,活生生把无状态高并发的HTTP给挤兑成了个占用Server端一个进程的长连接,服务器支持的并发数直线下降。
现在已经没这么玩得啦。
现在已经没这么玩得啦。
那现在一般怎么做的,都是定期刷新吗?
2 楼
pi1ot
2006-10-17
几年前的几乎所有国内的CGI聊天室都是这么搞得,活生生把无状态高并发的HTTP给挤兑成了个占用Server端一个进程的长连接,服务器支持的并发数直线下降。
现在已经没这么玩得啦。
现在已经没这么玩得啦。
1 楼
hexiaodong
2006-10-16
我实现的Comet Server,如果用电信宽待访问地址是http://agile.com/read.php?tid=319。我凭兴趣随便做的,做好了不知道该在什么项目里用,就这么闲摆着。
如果想试一试的话,下载后,放到tomcat的webapps目录下就行,然后访问index.jsp或者login.jsp。你可以看到一个很简单的聊天室的效果。
因为时间不多,所以用了很讨巧的方式来实现的。没有修改tomcat的源代码,而是在contextLoader的时候,另外开了一个socket端口用来接受comet连接。
如果想试一试的话,下载后,放到tomcat的webapps目录下就行,然后访问index.jsp或者login.jsp。你可以看到一个很简单的聊天室的效果。
因为时间不多,所以用了很讨巧的方式来实现的。没有修改tomcat的源代码,而是在contextLoader的时候,另外开了一个socket端口用来接受comet连接。
发表评论
-
使用JsonEditor开源组件写了一个Json Viewer
2014-07-06 09:06 12335工作中经常要查看一些无格式化的json数据, 下载了几个桌面的 ... -
code review 工具列表
2009-12-19 21:02 59441.代码格式检查checkstyle; ... -
常用正则表达式收集
2008-07-29 22:01 1730from:http://www.cnblogs.com/a31 ... -
用于获取url指定名称参数的js函数
2008-07-27 12:28 2017刚从csdn里面google到的, 笔记一下 functi ... -
用于转换Sql的一个小工具
2008-07-27 12:24 1821因为要在java中写大量的经过格式化后的sql脚本, 于是写了 ... -
REST学习笔记
2008-01-20 18:22 2582把《架构风格与基于网络的软件架构设计》博士论文大致看了一遍, ... -
FCKEditor定制两则
2008-01-20 01:21 2804FCKEditor是一个非常强大 ... -
为Validation.js增加中文日期验证
2008-01-13 00:31 3122还是以前同时发表在ajaxcn.org上的一片小文, 不过后来 ... -
基于prototype.js验证框架(validation.js)的三个应用
2008-01-13 00:24 2553也是很早发在ajaxcn.org上的一片文章, 现在proto ... -
本人对prototype.js进行的扩展
2008-01-13 00:06 1851很老的帖子了, 发在ajaxcn.org上,贴到这里,以后查找 ... -
对页面右键菜单, 选择屏蔽的屏蔽
2007-12-23 20:42 1870在浏览器地址栏中输入: javascript:void(win ... -
一个Ajax集成开发框架的布局重构之路
2007-02-08 14:22 3166发表于《程序员》2006年12期 一、背景介绍 随着web标准 ... -
AJAX一统天下之Rich Editor整合篇
2007-01-08 11:50 20790Rich Editor是我们 ... -
Ajax一统天下之Dojo整合篇
2006-11-19 16:16 21404随着Ajax应用越来越多, ...
相关推荐
Comet 有时也称反向 Ajax 或服务器端推技术(server-side push)。其思想很简单:将数据直接从服务器推到浏览器,而不必等到浏览器请求数据。听起来简单,但是如果熟悉 Web 应用程序,尤其是 HTTP 协议,那么您就会...
晋城市-晋城市-街道行政区划_140500_Shp数据-wgs84坐标系.rar
内容概要:本文档汇总了46个经典的Linux面试题及其答案,涵盖了Linux系统操作的基本命令和概念。内容涉及路径表示与目录切换、进程管理、文件和目录操作、权限设置、文件内容查看等多个方面。每个问题都给出了明确的答案,旨在帮助面试者全面掌握Linux命令行操作技能,同时加深对Linux系统原理的理解。 适合人群:准备Linux相关职位面试的求职者,尤其是有一定Linux基础但缺乏实战经验的技术人员。 使用场景及目标:①用于个人自学或面试前复习,巩固Linux基础知识;②作为企业内部培训资料,帮助员工提升Linux操作水平;③为初学者提供系统化的学习指南,快速入门Linux命令行操作。 其他说明:文档内容侧重于实际操作命令的讲解,对于每个命令不仅提供了基本语法,还解释了具体应用场景,有助于读者更好地理解和记忆。建议读者在学习过程中多加练习,将理论知识转化为实际操作能力。
街道级行政区划shp数据,wgs84坐标系,直接下载使用。
内容概要:本文提供了10道华中杯C++竞赛真题的详细解析,涵盖多种基础编程技能与高级特性。每道题目不仅包含详细的解题思路和代码实现,还附带了完整的运行结果。具体包括:函数参数传递(指针实现)、宏定义比较、数组元素打印、几何图形面积计算、字符串拼接、素数判断、多态的实现、文件操作、简单计算器和学生信息管理。这些题目帮助读者深入理解C++语言的核心概念和技术应用。 适合人群:对C++有一定了解的编程初学者和中级开发者,尤其是准备参加编程竞赛的学生或程序员。 使用场景及目标:①作为编程练习和竞赛备考资料,帮助读者掌握C++的基本语法和常用算法;②通过实际代码示例加深对C++特性的理解,如指针、宏定义、面向对象编程等;③提供完整的源码供读者参考和调试,增强动手能力和问题解决能力。 阅读建议:建议读者按照题目难度逐步学习,先理解题目背景和解题思路,再仔细研读代码实现,并尝试独立编写和调试代码。同时,鼓励读者扩展思考,探索更多可能的解决方案,以提高编程水平。
街道级行政区划shp数据,wgs84坐标系,直接使用。
街道级行政区划shp数据,wgs84坐标系,直接使用。
通用计算器的设计FPGA.doc
晋城市-沁水县-街道行政区划_140521_Shp数据-wgs84坐标系.rar
赤峰市-松山区-街道行政区划_150404_Shp数据-wgs84坐标系.rar
JAVA中Stream编程常见的方法分类
街道级行政区划shp数据,wgs84坐标系,直接使用。
大同市-浑源县-街道行政区划_140225_Shp数据-wgs84坐标系.rar
包头市-昆都仑区-街道行政区划_150203_Shp数据-wgs84坐标系.rar
街道级行政区划shp矢量数据,wgs84坐标系,下载直接使用
街道级行政区划shp数据,wgs84坐标系,直接下载使用。
内容概要:本文详细介绍了车载电子电器架构中的网络拓扑开发,涵盖开发概述、车载网络总线、网络设计原则、开发流程及小结。网络拓扑开发是汽车电气架构中的重要环节,旨在设计合理的网络结构以确保各电子控制单元(ECU)之间的高效通信。文中阐述了通信协议选择、网络节点布局、通信介质选择、拓扑结构设计及安全性考虑等关键要素,并强调了仿真与验证的重要性。此外,还讨论了网络设计的原则,如前瞻性、兼容性、拓展性、实时性、可靠性和安全性,以及网络负载的优化措施。最后,总结了网络拓扑开发的流程,包括需求分析、设计、仿真验证、优化迭代及文档记录。 适合人群:汽车电子工程师、各域功能工程师、子系统及零部件开发者、测试工程师等从事汽车电气架构开发的相关人员。 使用场景及目标:①帮助工程师理解汽车网络拓扑开发的关键步骤和技术要点;②指导工程师在设计过程中遵循科学合理的设计原则,确保网络拓扑的高性能和可靠性;③提供网络负载优化的措施,确保数据传输的实时性和效率。 其他说明:网络拓扑开发不仅需要考虑技术层面的因素,还需兼顾成本效益,以适应不断变化的市场需求和技术趋势。本文建议读者在实践中不断积累经验,关注新技术的应用和发展,以应对未来的挑战和机遇。