觀察一下目前有哪些有趣的多人協同運作的應用，並且稍微考慮一下想在鐵人賽中實作應用的範圍與技術的困難度。
今天是週日，輕鬆一點，來稍微思考一下多人協同運作的應用，以及哪些適合用WebSocket來實作好了。

廣義的說，其實只要讓特定的一群人可以分享資訊，就可以算是一種多人協同運作的應用了。一些比較靜態的應用其實很普遍，例如用一個blog、wiki、甚至一般網頁跟特定人分享資訊，其實也都可以算是這類型的應用。他的特色主要在於，過程是靜態的。內容通常是由一個人產出，然後透過系統把它分享給多人，寫一整篇文章，由時會花個幾天，也許會先存成草稿，等到編輯者確定內容沒問題才會發佈出去。

有一些系統是更動態的，但是通常資訊不是由「人類」提供。例如一個CI系統，會定期或在check in版本時發動測試，然後把測試結果發佈給團隊成員。雖然機器是碰到「條件」就會反應，然後自動產出、分享訊息，但是就「互動」來說，通常還是比較被動的。

更需要即時反應的系統，最簡單也最常見的就是Chat了，他的對話是即時呈現的，所以也常常用來作開發者的溝通，例如IRC。很多神人常常會沒事掛在上面，幫人解決問題等等。

一些更複雜的應用，除了需要即時反應，還需要處理複雜的「協作」。例如之前Google推出但是很快就掛掉的wave，他可以讓多人同時以所見即所得的方式編輯圖文並茂的內容，這除了讓每個人可以編輯內容，還需要有一些方法把個人編輯的東西整合起來成一致的內容，要做出這樣的協作應用，就比較複雜了。

WebSocket在目前的Web相關技術中，對於「即時反應」應該是相當快速也有效率的方法，所以很適合用來實作需要即時反應的多人協作應用。不過WebSocket只是一種傳輸方法，多人協作的邏輯還是需要自己做出來，沒有捷徑。

在協作的運作中，時序是一個很重要的因素，如果有辦法讓所有請求都能依照順序處理，後續的處理就會比較方便。相較於利用多執行緒或多行程來實作伺服器，node.js的單一執行緒模型有一個好處，就是所有處理都會是依序執行的，這樣可以很簡單的克服時序的問題。不過在需要水平擴充的狀況下，還是需要額外的協助。如果使用node.js的Cluster模組，可以利用master來實作queue，然後各個slave都利用master的queue，就可以做到相同的效果，又能兼顧效能。多機器的水平擴充，就不能依賴這樣的簡單方法來克復，這時就需要額外的支援，例如使用ZeroMQ。

接下來除了把WebSocket以及Socket.IO的應用告一段落後，就會開始嘗試Canvas的相關技術，並且試著在Canvas中實作一些多人協作的應用。