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

#1 楼 @Tony612 还真不知道 slideshare 被墙了... https://speakerdeck.com/sishen/real-time-web

一直想听这个 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 囧！的确，我也拼错了。

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

#24 楼 @redvoilin 谢谢关心！

这个是不是就是指 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 好像 htmlfile 可以

http://infrequently.org/2006/02/what-else-is-burried-down-in-the-depths-of-googles-amazing-javascript/ http://cometdaily.com/2007/10/25/http-streaming-and-internet-explorer/ http://cometdaily.com/2007/11/18/ie-activexhtmlfile-transport-part-ii/

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