RubyConf 我的 "Real Time Web" slide

yedingding · November 18, 2012 · Last by xwf286 replied at May 21, 2013 · 10713 hits

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

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

果然。。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 看你的在线客服要支持到什么程度,:)

#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 不能发到大伙能看到的地方吗?还是流行这样?

You need to Sign in before reply, if you don't have an account, please Sign up first.