|
锁定老帖子 主题：来谈谈Server Push吧
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-03-15
cocal 写道 我觉得用户数压力不在协议栈的连接数限制， 而在于虚拟机（应用）本身的效率和资源消耗。
另外Server push也并不一定非用TCP吧？ UDP有何不妥？只是需要开发客户端插件。 觉得大家讨论问题过于理论化，喜欢讨论一个很大的数字，但实际需求大吗？ 看看如此火爆的网游，有几个服务器端配置很惊人的？试过一个传奇旧版本服务器，也就是一台Win2000机器，内存加到2G，支持到上千客户端没有问题，大家的项目有很多大过这个需求数目的吗？ 看来同学有高见啊， 能说说UDP 实现的 Server Push ， 作听.. |
| 返回顶楼 | |
|
发表时间：2006-03-15
zhuam 写道 Hay hongliang ! 我不知道您有没有写过Server 端Socket 程序，对于单台 Socket 连接的极限数那是我们无法更改的，作为 Server ，持久网络连接的确是很耗系统资源，但通常我们说他很耗资源那也包括了 Thread 内处理，不光说网络层的处理。 我当然写过server端socket程序。不过我没理解你的意思，可否表达清楚一些？ 我也知道持久网络连接狠耗资源，但是你后面那句话我就没懂。 zhuam 写道 难道就因为保持了Tcp 连接，这就是个错误！
什么意思？我还是没懂。 |
| 返回顶楼 | |
|
发表时间：2006-03-15
对，我不是搞Internet的，只是很想把Internet的成功模式引进企业环境里（包括真正面向需求，快速响应，服务导向，也Internet包括充分发展之下的低成本，甚至是开源思想），只是目前没什么作为。
哎,换个问法吧：“你们开发的系统并发数多少？说来听下？ ” 
并发的概念我是这么理解的：对于client-pull模式，是每秒处理的请求数;对server-push来说，是同时在线的client数。这样有没有问题？ 讨论用不用server-push，我想应该结合需求来看，如果你的例子中系统要求客户端获取更新的实时性要求是1s，也就是说客户端需要每秒钟pull一次，那么Server-push和client-pull的区别就是这6000个连接是每次都open-close还是挂在那里了，而server-push更可以把实时性要求提高到1s以内的。Server-push可以有效提高应用的实时性。 回归正题吧，你一楼65535这个数是从哪里得来的？ 说来听下，我只知道线程（windows），进程（linux/unix）同时打开的socket数有限制，但os这一级是什么数字的确没找到依据。 这个世界上估计鲜有受到socket数考验的应用，而绝大多数受考验的是进程数限制，内存限制，运算能力限制，网络瓶颈限制....。想像一下数据库连接池，建议做个test，看看最多你能建多少个连接？是什么先不够用？可能性有n个，我想最后一个是 OS socket 平时没有数据不代表不需要有其他代价。
|
| 返回顶楼 | |
|
发表时间：2006-03-15
嗯，也许我把这个帖子的方向讨论偏了。本来是想讨论一下是否有更好的WEB方式的server-push实现方法的，结果现在变成socket数有多少了，哈哈，我的错我的错。
就说单台服务器吧，平时每秒钟处理的和处理中的请求大概至少有6000个。这是静态页面的情况。J2EE应用没这么高，高峰时大概也就4000左右，因为那个时候数据库受不了了，现在我们系统有性能瓶颈，在数据库端。 关于socket的讨论就到这吧，讨论这个的确没多大意义，算我错了阿各位，多多包涵。 回归正题吧，正题！Server-Push在WEB上的实现方法，有更好的方式吗？ |
| 返回顶楼 | |
|
发表时间：2006-03-15
引用 我们可以试想一下这样的情况，如果本身操作系统对socket数没有限制，那么我们就可以肆无忌惮地压榨一台机器，让它接受更多的长连接，不用担心任何问题。 我的意思是你上面这段话有问题， Socket 连接是一个问题，但处理这些Socket 连接需要的资源，那才是最大的问题，所以别总把问题局限在 socket 上，把什么都归结为 tcp 和 socket 的错。 |
| 返回顶楼 | |
|
发表时间：2006-03-15
OK，同意，同意
|
| 返回顶楼 | |
|
发表时间：2006-03-15
okey，忘掉socket这个话题。
其实Server-push根本上解决的是http的无连接性。 http的无连接性是web应用的病根，最早讨论的是session和session安全，虽然现在这个问题讨论平息了。但Server还是无法准确知道现在的客户端窗口是不是被用户close掉了，因此只能靠那个session timeout来解决，但必须面对用户不小心被timeout拒绝的无奈（虽然我们可以通过有效期更长的cookie来解决，比如javaeye的“自动登录”，但此时安全性又受到考验）。 当一个http server有某个信息需要session池里的所有用户实时知晓的时候，它竟然不知道这些clients在哪里,以及他们是否还健在，只能坐在那里等，上帝保佑，客户点一下吧，浏览器上那个ajax小东西来看看我吧，不是约好的吗？呵呵。 我想这是我们对Server-push最大的期待了，对不对？ 对于这个问题的考虑，基本上我的观点是要跑到Browser外面去，希望Server-push不要把大家定义在<html></html>中间，连一点本地代码都不允许。反正即便是他不允许，我也管不了了，能用，好用才是目标对吧？ 因此我的想法可能不叫Server-push，不用理他。 完整地解决这个问题，我想用本地代码，ActiveX控件，Browser plugin都是可以考虑的方式。但我想的是一个更彻底的办法。 zhuam在做jabber(和gtalk通的，应该说gtalk依附于jabber吧？虽然gtalk是基于xmpp的，但xmpp大部分东西还是来自jabber)是吧，我想我们可能想的一样。这两年我尝试过好几次jabber了，没有用起来真实遗憾的事情。有一个jabber客户端有没有注意过？ http://www.pandion.be/ pandion以前叫另外一个名字，由于版权纠纷改过来了，这是一个内嵌IE的程序，本地代码实现xmpp协议层，全部UI都是ajax做的，早在两年前它差不多就是这样了（不幸的是它是基于IE的，并且不开源，否则一定火起来了）。 我一直想把类似pandion这样的东西作为企业应用的入口，作为单点登录的agent，以jabber服务器的扩展作为企业环境下的验证服务器，web server通过jabber服务器来验证客户端。当然客户端功能的入口也可以来自pandion这样的本地环境，携带票据或证书发起一个web session。所有的Server-push通过xmpp直接推到象pandion这样的客户端上来，http还干和现在一样的工作。 这样的应用框架在我的眼中算是比较完美的，但我至今没有说服管理层给我资源，比如5个人年的时间去实现它。而企业级的吹牛大户比如IBM，Oracle和BEA都不知道是不是脑袋被马桶盖夹过了，厂商之间互设壁垒，设置壁垒欺压用户，的确受够他们了。而看看现在的QQ，他已经有这样的做法了，只是本地代码更厚一点而已。 我隐约觉得这个框架包含一些Internet的思路，或者思想在里面，比如以用户为中心，应用和用户平等沟通，为用户定制功能等等等等，但由于没有实践，也永远不会有升华，只能郁闷郁闷，呵呵。 甚至想过一些小的扩展，比如把这个jabber核心向手机短信延伸，实现通过手机短信用户验证和应用交互，真正把信息系统的触角伸出去。或者扩展jabber client客户端的本地代码，做信息系统资产管理，windows安全性检查和控制，同时完成信息系统安全agent的工作等等。 我还在争取获得支持，这段时间有些松动，因为我用openvpn做了一个验证方案，把程序和证书，密钥打包，客户端安装程序只有800k左右，管理层多少有些兴趣。希望总是有的
|
| 返回顶楼 | |
|
发表时间：2006-03-15
那你的客户端是基于IE的？或者更宽泛一点说，是基于Windows系统的？
|
| 返回顶楼 | |
|
发表时间：2006-03-15
没错，因为我考虑的是企业环境，但也不一定基于ie, firefox应该可以。但基于windows几乎是必须的。因为windows除了应用，还有很多东西必须管起来，不能一叶障目，放任企业里的windows自流吧？ windows没好到不用人操心的程度
|
| 返回顶楼 | |
|
发表时间：2006-03-15
Intranet的确是怎么搞都不怕，因为环境是统一的，行政手段也是有效的。
但是Internet呢？ |
| 返回顶楼 | |
