Amir Salihefendic 演講: Comet with node.js 影片與筆記

星期四, 十二月 31, 2009

Amir Salihefendic 演講: Comet with node.js 影片與筆記

12/29 TOSSUG 的活動 - Amir Salihefendic: Comet with node.js (下述簡介轉載自此文)

node.js [1] 是個架在 Google V8 Javascript 引擎之上的事件驅動式的輸入輸出模組（evented I/O）[2]。V8 是最快的 Javascript 虛擬機之一，node.js 用最佳的方法利用了 V8。

講者將會介紹 node.js 和實作 Comet 型態 [3] 的 chat 的實例。

node.js

evented I/O: 用 event 和 callback 而不用 multi-thread 實作 server 的方式，twisted 是知名的一個這樣實作出來的 web server。

comet: 一種讓 web server 可以把資料 push 到瀏覽器的做法，見 Comet_(programming)

現場演講影片

感謝 FourDollars 的分享 - Amir Salihefendic: Comet with node.js (當天演講的錄影)

投影片重點摘要整理

直接看投影片(Comet with node.js and V8) 做的筆記, 影片還沒看, 有錯請糾正我. Orz..

Apache / Nginx 比較
- nginx: non-blocking (能夠承受較多的使用者, 記憶體使用較少, by event)
- apache: threaded (隨著人數越多, loading 就越重)
- comet 比較適合 non-blocking 的 server.
Ajax is so yesterday
- Comet can be create real time web-applications
Comet 原理、方法
- Ajax: Browser 去跟 Server 問, 再回應修改.
- Comet(long poll): ~~一段時間自動去跟 Server 問, 再回應修改 (我認為這還是 Ajax, 只是 Ajax 加上固定時間去問 Server, Plurk 目前採用此方法)~~
  clydewu 的解釋比較清楚: Long polling (下述取自此篇)
  Long polling 是一種傳統查詢(poll)技術的變形 and 允許模擬從伺服器到用戶端的資訊推送(information push)。有了long polling，客戶端從伺服器要求資訊相似於一般的查詢。但是，如果伺服器沒有任何可用的資訊給客戶端，伺服器會保留這個需求(request)並等待一些資訊可用 instead of 送出一個空的回應。一但資訊變成available (或是在適當的timeout後), 一個完整的回應被送至客戶端。客戶端將會一般的立即重新要求資訊從伺服器，所以伺服器將幾乎總是有一個可用的等待需求而可以用來交付資料來回應事件。
  Long Polling 本身不是推送技術，但是可以被使用在真正的推送還不可能的環境。
  
  php實作long polling的example:
  用usleep()給他等沒錯 XD
- Comet(streaming): 由 Server push 資料到 Browser.
- Comet server 需要非常多的 open connections (因為 browser 開啟後, 就一直連著不中斷, 就像是 Web 的 Socket)
WebSockets 在 HTML5 有定義, 目前於 Google Chrome 有實作出來.
其它 Comet server
- JBoss Netty (Java)
- erlycomet (Erlang)
- Tornado (FriendFeed's Python non-blocking server)
- 講者推薦的還是 node.js

延伸閱讀

相關標籤

this is comment icon [回覆]

amix有說他那個投影片的圖有錯誤,有幾條線是多的
事後問他long polling, 我的理解是

在原本的架構下
client丟一個request,server不會馬上response
而是等到有新東西進來才response給client
然後這個connection就會被close

這時client再馬上發一個新的request開始一個connection
繼續上述等待server response

我這樣想是對的嗎?

Comment by clydewu (01/01/2010 01:04)

this is comment icon [回覆]

打錯名字了...罰打10次
Amir Amir Amir Amir Amir Amir Amir Amir Amir Amir

Comment by clydewu (01/01/2010 01:06)

this is comment icon 回 clydewu [回覆]

Amir 幸好你有提醒, 不然我應該會跟你一樣打錯字. XD
他的投影片的上的圖, 我倒是沒有仔細看, 我都看文字描述.
我覺得你說的 long polling 的理解, 好像跟我理解的不同.
(我想文字描述理解比較容易有不同, 所以我直接看實例. :P)
我在 Plurk 用 Firebug 看主控台, 看網路送哪些 request.
發現
1. 30秒送一次
2. 發送、取得 http://www.plurk.com/Poll/getResponsesN/xxxxxx
他每個 request 都有回應資料回來, 把 connection close 掉(沒新資料會回傳 "[]")
我想這個比較合理, 因為 connection 若沒有收到回應, 會一直在那邊 wait, 對 server 和 client 都是種負擔.
不知道這樣子你的看法如何? (我也不確定自己對錯, 一起討論看看吧~ :P)

Comment by Tsung (01/01/2010 13:01)

this is comment icon [回覆]

剛剛內容超過一千字
拿出百年沒用的blogger打了篇文章 XD

http://claudck.blogspot.com/2010/01/long-polling.html

我想知道的是，怎麼從firebug看出他是30秒送一次request?
我的firebug的網路那頁的甘特圖(可以這樣稱呼吧？XD)
我覺得好奇怪...

Comment by clydewu (01/03/2010 20:58)

this is comment icon 回 clydewu [回覆]

嗯嗯, 我是照他投影片的說明, 就覺得怪怪的, 感覺起來就是一直發 request.
你寫的這種確實是 comet 的模式沒錯. :)
我看 30秒發一次 request, 是由 Firebug -> 主控台看的.
1. 找到 POST http://www.plurk.com/Poll/getResponsesN/xxxxxx 看標頭.
2. 再看下一個 POST http://www.plurk.com/Poll/getResponsesN/510115 看標頭.
3. 這兩者時間差是 30秒.

不過似乎這兩次送完後, 就不太會再送, 後續走的模式就比較像你所說的.
Plurk 的實作模式應該也有做些修改 (若沒什麼動作, 似乎 connection 就會先中斷一陣子, 一段時間後才會再送個 request)
照你所說的, 我想應該要在 status bar 看到 comet05 一直等待的狀態才對, 而不會出現"完成".

Comment by Tsung (01/03/2010 22:01)

this is comment icon 回 clydewu [回覆]

你這篇文章的解釋很清楚, 特別是下面這兩個:
1. Long Polling 本身不是推送技術，但是可以被使用在真正的推送還不可能的環境。
2. php + usleep();
非常感謝~

Comment by Tsung (01/03/2010 22:04)

this is comment icon [回覆]

宗董客氣了~
我不是很確定他當初跟我說的錯誤的地方是哪些
雖然現在這樣看起來公布出來的投影片是跟當初講座的時候不一樣

現在的投影片因該是正確的
我修改了blogger內容，補上照片對照...
還有最下面有一個long polling效能的討論

Comment by clydewu (01/04/2010 09:02)

this is comment icon 回 clydewu [回覆]

嗯嗯, 效能問題似乎會有些有趣的狀況發生, ex: 除了吃系統資源外, 還可能把網路卡的 IO 吃滿.
作者提到這兩點, cannot send data => 所以 Plurk 都另外 POST 來解決.
1) The server is waiting for a request (and cannot send data)
2) The browser is waiting for a response (and cannot send data.)

Comment by Tsung (01/04/2010 10:13)