|
锁定老帖子 主题：来谈谈Server Push吧
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-03-16
cocal 写道 端口数==连接数？
这么讲吧，连接的确认是以ip+端口+协议id的。 在比较老的书上说，listen到一个进入的连接，会copy 到一个新的socket 上， 这个新的socket用一个新的port号。 所以port 号限制了可用的连接。 一般性可用的连接，还不到65535，因为还有一部分被底层引用占掉的。 不知道现在的tcp/ip的socket 是不是还是这么实现。 |
| 返回顶楼 | |
|
发表时间：2006-03-16
ServerPush有一种情况是用在聊天室的情况下
此时客户端就是浏览器，它仅仅是被动的接收数据 除非你在写个插件，否则UDP好像没法用 当然，我对这也理解不深,可能说的不对，不过当年写聊天室我们就是用的Server Push，基于Http |
| 返回顶楼 | |
|
发表时间：2006-03-16
scud 写道 ServerPush有一种情况是用在聊天室的情况下
此时客户端就是浏览器，它仅仅是被动的接收数据 除非你在写个插件，否则UDP好像没法用 当然，我对这也理解不深,可能说的不对，不过当年写聊天室我们就是用的Server Push，基于Http 非常正确！ 引用 只不过在实现的时候吧tcp改成udp就好了吗？server端只有一个接收线程，登录是客户端发起的，server保持一张在线用户列表，需要push的时候查表把信息丢到相关的客户端（当然，客户端也随时可以发请求给服务器，通讯是双向的），增加一个最简单的ack机制，收不到回应认为其离线。当然，为了维护在线清单的及时性，执行间隔的alive ping就可以了，这个和现在ajax定时去pull来保持session有相似之处，只是可以从server发起也可以从client发起，不管是网络还是cpu开销要小的多而已。 很难理解？需要争论？ UDP的提出是由于楼主对TCP的置疑，UDP得明显的好处是Server不需要为每个client fork一个线程，不管UDP的协议开销还是应用空间的资源开销都要小的多，不反对吧？ 以求突破楼主假设的socket数限制，支持一个海量的客户端。马化腾当年做QQ的时候不傻，几十成百万用户在线也不一定要google那样的服务器群。 必须承认的是，我的确没有实现过，但这个模型是成立的，基本的教科书例程嘛。为了做IM我大概也不会再去开发一套基于UDP的通讯协议出来，因为楼主的假设其实没有成立，硬件/网络的发展已非几年前可比，目前的主流IM通讯是基于TCP IP的，有标准可用肯定还是用标准咯。 Server Push 离开了浏览器那就没意思， 我也是做IM 软件的，我如果不明白UDP 与 TCP ，呵呵。 UDT 是一个不错的通讯协义，你们可以去看看，我们在系统中应用了UDT ，还不错。 |
| 返回顶楼 | |
|
发表时间：2006-03-17
dwangel 写道 cocal 写道 端口数==连接数？
这么讲吧，连接的确认是以ip+端口+协议id的。 在比较老的书上说，listen到一个进入的连接，会copy 到一个新的socket 上， 这个新的socket用一个新的port号。 所以port 号限制了可用的连接。 一般性可用的连接，还不到65535，因为还有一部分被底层引用占掉的。 不知道现在的tcp/ip的socket 是不是还是这么实现。 建议做个测试： 一个tcp server，一个tcp client。client开十个连接，然后挂断，server，client分别把使用的端口号打印出来 
|
| 返回顶楼 | |
|
发表时间：2006-03-17
zhuam 写道 Server Push 离开了浏览器那就没意思， 我也是做IM 软件的，我如果不明白UDP 与 TCP ，呵呵。 UDT 是一个不错的通讯协义，你们可以去看看，我们在系统中应用了UDT ，还不错。 UDT不也是基于UDP的吗？呵呵，其实一楼那个不结束的request（其实叫long-pull比较准确点）也算是一种的折中吧，不太理解什么叫“没意思”？ 不跳出http，哪里来的了server push哦。 |
| 返回顶楼 | |
|
发表时间：2006-03-17
dwangel 写道 说实话，人家把http弄成无连接的，就是为了在低服务器消耗的条件下处理更多的连接。
现在又要把http弄成持续连接。这种感觉好怪…… 要知道http名字叫“超文本传输协议”来的，本意只是希望图文并茂地把文档传阅开来的，哪里想到发展的这么走形，变成颠覆传统C/S结构的应用基础了？呵呵，如果它老爸能预计到现在这么用法，一定会加个面向连接的选项 
|
| 返回顶楼 | |
|
发表时间：2006-03-17
cocal 写道 dwangel 写道 说实话，人家把http弄成无连接的，就是为了在低服务器消耗的条件下处理更多的连接。
现在又要把http弄成持续连接。这种感觉好怪…… 要知道http名字叫“超文本传输协议”来的，本意只是希望图文并茂地把文档传阅开来的，哪里想到发展的这么走形，变成颠覆传统C/S结构的应用基础了？呵呵，如果它老爸能预计到现在这么用法，一定会加个面向连接的选项 在http设计初期，是考虑到了机器性能问题才设计成无连接的。 http1.1里已经可以支持持续连接了，只要加上特定的头。 不过，经过代理服务器时，还是需要代理的支持。 其实http成为b/s架构基础，就是因为无连接能够以低成本（服务器）支持更多的用户。对服务器的限制也少。 |
| 返回顶楼 | |
|
发表时间：2006-03-17
cocal 写道 zhuam 写道 Server Push 离开了浏览器那就没意思， 我也是做IM 软件的，我如果不明白UDP 与 TCP ，呵呵。 UDT 是一个不错的通讯协义，你们可以去看看，我们在系统中应用了UDT ，还不错。 UDT不也是基于UDP的吗？呵呵，其实一楼那个不结束的request（其实叫long-pull比较准确点）也算是一种的折中吧，不太理解什么叫“没意思”？ 不跳出http，哪里来的了server push哦。 首先我想说的是，Server Push 我需要基于浏览器来实现，我如果不是在IE 这样一个特定的环境下来讨论Server Push ，那我不是傻差啊，晕！ UDT 是一个基于udp 来部分模仿TCP的一个新协议实现，但给出他，是为了让你看看他，因为你讨论到IM 关于UDP 的实现，所以我才说他的，我并不是为了说SERVER PUSH 来用 UDT啊，同志！ |
| 返回顶楼 | |
|
发表时间：2006-03-17
cocal 写道 dwangel 写道 说实话，人家把http弄成无连接的，就是为了在低服务器消耗的条件下处理更多的连接。
现在又要把http弄成持续连接。这种感觉好怪…… 要知道http名字叫“超文本传输协议”来的，本意只是希望图文并茂地把文档传阅开来的，哪里想到发展的这么走形，变成颠覆传统C/S结构的应用基础了？呵呵，如果它老爸能预计到现在这么用法，一定会加个面向连接的选项 你看你所有的关于Server PUSH 的讨论， 我给你一个总结，那就是观察者模式 ＋ TCP OR UDP 的一个实现。 晕，如果是这样我需要讨论嘛！ 对于HTTP 等高层协议，你也可以设计实现一个，但你设计的浏览器能支持嘛！ 同志，跳出，也要看在那里跳啊！ 把这篇帖子的主题拉回来，那就是我们只讨论基于IE 或者说基于浏览器的Server Push 实现 |
| 返回顶楼 | |
|
发表时间：2006-03-17
to cocal !
Server Push 是一个值得讨论的话题，他本身不是什么新技术，我讨论他，是因为在当前WEB 2.0 的大形式下，基于浏览器来实现Server Push ，对我来说很有诱惑， 而不是要文不对题的， 吓撤什么IM ，UDP 实现Server push，如果你拿出一个好的基于IE 的一个UDP Server Push方案，或者代码能说服我，那我服， 我本身就是做IM 的，你给我来这么一套，你不让我晕啊，同学 ，我不喜欢空谈啊， 实际点，现实点啊.. |
| 返回顶楼 | |
