RubyConf 我的 "Real Time Web" slide

yedingding · 2012年11月18日 · 最后由 xwf286 回复于 2013年05月21日 · 8001 次阅读

大家好。这个是我的 "Real Time Web" 这个 talk 的 slide http://www.slideshare.net/sishen/real-time-web-15229483

可能得等视频出来后配合这个看比较好,有兴趣的同学可以先看看,有什么想交流的可以联系我,:)

共收到 64 条回复

果然。。 slideshare不翻墙是上不去的。。 还是speakerdeck好点啊

一直想听这个topic,可惜没去的了今年的rubyconf,好在今年有视频了 :)

呵呵 今天去听了,没想到这么快就有ppt了 下载中;另外,祝福dingding宝宝早日康复!

选择主会场分会场真纠结,呵呵,今天一直在分会场,没听到,等视频出来了配合着看。嘉宾辛苦了!

这个slide啥内容都看不出来

楼主的讲解很有干货.

如果不在乎浏览器支持的话, websocket之外, 还可以选择server send event + 普通ajax的手段. 不过目前来讲, 对websocket封装的库会多一点, 也热门一些.

这个主题的演讲非常棒,讲解很清晰流畅,本来对这个主题了解不多,兴趣也不大(因为觉得难度比较大),听完之后一下子逆转了,我们也有一个实时的需求,实时的在线客服,现在是使用第三方的服务,现在感觉可以自己做。

#8楼 @kenshin716 Socket.IO 库这方面做的很好

突然有个想法. 专门建立一个项目, 专门用来做web realtime的showcase.

XMPP vs Bayuex ,该如何选择?

#12楼 @edokeh 应该是Bayuxe Bayuxe, 最初是看CometD这个项目了解的.
这个协议基于HTTP协议, 目标Web Realtime, 传输数据格式为json. Ruby 中可以用 (Faye)http://faye.jcoglan.com/

各人认为比较适合做 web 论坛通知, 审核通知, Web短信消息通知等.

XMPP, 基于xml数据格式, 主要面向IM领域. 如果应用想支持Pidgin这类软件, 可以考虑使用XMPP 使用的时候需要(Openfire)http://www.igniterealtime.org/projects/openfire/之类的独立服务器.

个人理解.

#13楼 @lvjian700 也就是说,如果要考虑与其他 IM 客户端的互通,最好选择 XMPP ?

#12楼 @edokeh 看你应用的具体需求。用 BOSH (XMPP) 的好处在于标准化,可扩展性非常高,已经有非常多的扩展可以用了,比如 IM, Chat Room, Pubsub, File Sharing, etc. Google Wave 就是基于 XMPP 做他的实时方案的。他的缺点也是标准化,你需要先了解 XMPP 才能用得好这个东西。可以用Jabber Client 是一个优点,但不支持也没有任何的关系(你不需要暴露出用户在XMPP服务器上的账号信息)。Bayeux 在我看来是一个很小的协议,他把很多事情都留给应用端了,也就是说你需要自己去定义数据格式等,可以做的非常随意,在后期可能会带来维护上的问题。但是,在上手上会比 使用 BOSH 更快。这两个在Long Polling的实现技术上没有孰优孰劣,最终还是看你的应用的具体需求。

PS:个人偏好 BOSH。

#15楼 同时,我希望未来 WebSocket + XMPP 的组合,有兴趣的可以看看 http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-01

#8楼 @kenshin716 SSE 是使用 http streaming 的,也是不错的选择,单向的服务端推送对很多应用也够了,就像你说的也可以用 SSE + Ajax 来做双向,但是,这样子的话,不如直接上 WebSocket。

#6楼 @bhuztez 对不住 b 大,配合视频的话有内容点....

#9楼 @yzhrain 看你的在线客服要支持到什么程度,:)

#4楼 @Magic 谢谢关心!

#15楼 @yedingding 了解,感谢 之前做一个 webim 的项目,由于工期紧,在这上面没有仔细考虑,直接用了基于 Bayeux 的 Cometd,现在考虑客户端,发现 XMPP 似乎优势更大一点,所以纠结啊,呵呵

@lvjian700 我特地查了下,发现我们俩都写错了,是 Bayeux ... 我只能说这破词真心难记啊。。。

#21楼 @edokeh 哈。我也又一次拼错了. 我觉得 IM 这种就更适合 XMPP 了,所以我觉得... Weibo IM 用 Bayeux 真心无法理解...

#21楼 @edokeh 囧! 的确, 我也拼错了.

感谢楼主的演讲,很不错,以前对这方面不是太了解,今天听后,有了一个大致的概念了,祝你孩子早日康复

这个是不是就是指Faye这类的? 我看ruby-china就是用的这个吧,然后我用了ryan的private_pub,我觉得这个做聊天的比较好,我是做类似ruby-china的论坛的通知,就感觉不太舒服,也可能是我的实现方式比较不好。而且这个是要production环境才有用的,开发不是很方便,要来回切换。。

#26楼 @Tony612 Faye 是基于 Bayeux 的 publish-subscribe 消息系统。单独通知的话考虑用 faye, websocket, SSE. 都可以,基本不存在切换的问题。另外,如果不是非 ruby 不可的话,这部分模块其实基于 node 会更方便。

@yedingding 祝你孩子早日康复 谢谢你的精彩演讲

期待视频释放出来

Great job dude.... :D

好闻,收藏了

@yedingding 你好。你的演讲很不错啊!本来当时想问你个问题的,不过没机会了。 我们现在有个项目是关于足球信息推送的。要求很即时的把信息推送给web客户端(网页),这是核心功能。并且对IE系要有一定程度的支持。原先的Pusher因为是WebSocket,在IE是彻底不能用(而且也有些网络原因),我们现在正在用Faye,就是不知道对IE支持怎么样(因为我们现在都直接告诉客户,建议用Chrome的)。 请问如果考虑对IE的支持的话,是不是就不能用Faye了?那用什么技术比较好呢?Long polling吗?

#32楼 @darkbaby123 Faye 可以支持 IE 的啊

#32楼 @darkbaby123 Pusher 是有 Flash Fallback 的,也就是在有 WebSocket 支持的情况下,用 WebSocket,但是没有的话,就退化成 Flash Socket。你有没有尝试过?文档在这里,http://pusher.com/docs/flash_fallback 在选择实时方案时,从浏览器兼容角度来看,一般都会提供 fallback.

@edokeh 不好意思,我没测试过。这段时间搞别的去了。明天我去测试下。

#32楼 @darkbaby123 关于网络问题的话,的确国内访问 Pusher 速度并不是非常快,你负载大概在多少,可以尝试下 slanger 这个 gem。Faye 也是有 fallback 机制的,支持 IE,在支持 WebSocket 的情况下也可以直接用 WebSocket 作为 transport。用这些的好处在于服务端的开发量少,基本是内部通讯协议的定义。

@bhuztez 好的,我去研究下。谢谢提供资料! @yedingding 我们没用Flash,主要是都不熟。。。目前已经没使用Pusher了,全面用Faye替代。因为原来有几次客户端没有及时收到数据,但连接我们的网站并不卡,后来ping了发现Pusher服务器在欧洲(忘了是美国还是欧洲了),而我们的客户主要是在亚洲,速度不大稳定,国内也有,Pusher也有时候被HX了。。。所以才决定自己用Faye搞推送服务器的。换了Faye之后稳定性大幅提升了,两个月没管都没出问题。。。

#38楼 @darkbaby123 cool,很好的案例。Faye 对 IM 应该支持的,你去实验一下。htmlfile 不适合你,走 http streaming,还要你自己去开发服务端,已经是很老的东西了。

@yedingding Thanks! 说起来不好意思,我自己都没试过IE下的兼容性。听你演讲才知道你们也在用这个,问问你算是偷个小懒。Pusher的FlashSocket和htmlfile有空闲时间我再去看看,算是扩充点知识面了。

#39楼 @yedingding htmlfile是不需要Flash就能支持到IE5.5的方案

Orbited里代码早就有了... https://bitbucket.org/desmaj/orbited/src/tip/daemon/orbited/transports

#41楼 @bhuztez 我没说 htmlfile 需要 flash 啊... 这种基于 http 的跨浏览器本来就是天生的。问题在于 Faye 不支持 htmlfile

#42楼 @yedingding 我只是强调htmlfile的优点很明显

#43楼 @bhuztez htmlfile 已经过时了,有事烧纸

#44楼 @yedingding 怎么就过时了,如果你打算支持IE,又不想用Flash,你没有选择了

#45楼 @bhuztez 为什么?我直接用 ajax 模拟 long-polling (比如 BOSH,Faye 也支持), 或者 jsonp 都可以支持 IE 吧?

大早上赶去,正好听到叮叮的演讲,各种技术的选择还有优缺点讲的很详细,很受教!

#46楼 @yedingding 那个场景不需要双向吧,那就htmlfile最合适了

等视频。。。

faye是支持ie的,只是在ie6里面有一点点问题. 需要修改gem里的一段代码,你到github去看下, 有人提交了解决方案,我也是改了的才成功. 还有别用那个private_pub, 我后来又重新去掉改写程序, 那个gem对ie6有很多问题. 现在有个问题,faye下面用thin服务器,我在linux下运行聊天室,1-2天thin需要重启,我不得不写个shell脚本 DTTERM = ps -ef|grep thin | grep -v "grep"|wc -l if [ $DTTERM -n 0 ]; then cd /opt/nginx/html/project; rackup faye.ru -s thin -E production; fi

用linux里面的cron程序定时去执行这个脚步,每隔5分钟监测一次,如果thin停止好重启.几个月了.我一直没去理.到现在也没找到bug, thin在linux的log在哪里啊?

faye做聊天室还有个问题,上线好解决,下线的状态不准确. if faye_action == "subscribe" push_client(faye_msg.person_id,faye_msg.person_nick_name) elsif faye_action == "disconnect" pop_client(faye_msg.person_id) end 你在浏览器里面关掉页面,打开页面,不断的重复这个动作.消息disconnect就不正常了. 我把faye的运行日志打印到命令行里面看到反正多几次这个状态就不正确了.导致有的人下线了还显示在线. DHH写的项目Campfire不知道大家用过没,下线是需要自己点击leave room的. 我到现在还没知道个好的自动下线的方案.如果有谁用faye写过聊天室项目,请告诉我.不知道我是不是漏掉了什么函数没去看. faye项目官方说不主张用这个做聊天室,说做通知最好. 我觉得faye使用简单,也不想跨入node.js,想用faye做下去. 请教yedingding, 在ruby领域里面, 除了用faye实现聊天室,还有什么别的方案吗? 这些都用faye做合适吗? 我是打算faye到底了. 我怕最后性能有问题. 有人在国外论坛上说过thin的问题. 能改faye的服务器吗

#50楼 @tank 不是很理解你说的上下线问题跟代码之间的关系。是不是指用户非主动断开比较关掉页面后,仍然显示在线?这个我觉得是有个 timeout 的过程,如果客户端有一段时间没有给你发请求(心跳)就认为用户断线。做聊天室的话,我个人会倾向于用 BOSH + ejabberd/openfire,可以看看我的 PPT 里关于 HipChat 这个例子的部分。Faye 没在实际项目中用过,不好乱给意见,不好意思

那样也可以,就是需要定时去监测一下.看客户端有没有发请求.列入,发了消息,我就延迟一下timeout的时间.我现在是客户主动关闭标签页,通过faye发送unsubscribe来下线用户,但是faye这方面有点问题.关闭打开,关闭打开,反复几次就不正常了.然后再关闭就忽然没发unsubscribe消息了.导致用户没下线 现在我去下ppt看看bosh+ejabberd/openfile

#51楼 @yedingding 你那个聊天室是用bosh+ejabberd/openfile吗?

#53楼 @tank 你是说我做的 live show 吗?不是的,不过我打算跟 @poshboytl 重做时看看能不能搞个系列的,各种技术都尝试一下。

#52楼 @tank 关闭标签页是指监听 window.onbeforeunload 事件?没法 unsubscribe 消息你查了是什么原因?客户端没发还是发了服务端没处理?

#54楼 @yedingding https://pragmatic.ly 里面有个聊天部分吧,我在ppt里面看的

#55楼 @yedingding 关闭标签的时候faye有时候没发送disconnect消息过来.有时候发.我是通过这种方式来把一个用户下线的, 所以不准确. if faye_action == "disconnect" pop_client(faye_msg.person_id)

#56楼 @tank 暂时没有,以后可能会有。聊天部分是 HipChat (http://hipchat.com).

关闭标签的时候客户端做了啥,服务端做了啥,你自己的代码部分。

突然想到个问题,HTTP Streaming 好像用的很少,是不是因为它相比 Long polling 优势不够明显呢?

#59楼 @edokeh 优势明显,劣势也明显。优势主要是针对在压力非常大的应用里,用 long polling 不断的重新建立连接是个很大的开销,但是大部分应用到不了那个程度,等于优势弱化。而劣势在于服务端开发更难,陷阱多,需要很小心的处理和管理连接。所以相比起来,long polling 目前被用得更多。可以等视频出来后看看我在这方面的一些想法。

#59楼 @edokeh 单向为主的用Streaming,双向都很频繁的你就算做了Streaming用起来和long polling没啥区别啊...

#60楼 @yedingding Long polling 服务器端开发应该跟 Streaming 差不多吧?都是要保持和管理长连接嘛,有哪些不一样的地方嘛?

#61楼 @bhuztez 做双向的话,Long polling 肯定也是另外启用一个连接啊,参见 Faye 的实现

#62楼 @edokeh streaming 的连接理论上是无限长的,需要保持很多状态信息,而 long polling 相对只是保持一定时间的连接,很大程度可以依赖于请求带过来的信息。所以在开发上 streaming 需要处理更加的小心,包括心跳重连等,我说的难度是相对的,是说比起来。双向和单向两个没有区别,都是模拟的双向,也就是一开始建立连接后,只能从服务端给客户端发数据,而客户端要向服务端发数据,必须得另开一个连接。用 Streaming 还是 Long Polling 我觉得还是使用场景,在我看来更新非常频繁的比如 Twitter,是不大适合用 Long Polling 的,因为负载太大,而且延时严重

看个ppt还得翻墙,可公司里没法翻,以后发个ppt不能发到大伙能看到的地方吗?还是流行这样?

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册