健康操和組播(IP Multicast)

數年前，我服務的公司忽然有了一個簡單的需求。需求背後的故事不重要，重點是，為何最後IP Multicast幫我解決了問題。

很簡單的需求

原始的需求只有這麼簡單。下午三點半，全公司七百多人，可以一起在座位的PC前面，同步收看健康操影片，每個人跟著影片中的動作，做做健康體操，增加員工的身體健康。

背景資訊：全公司七百多人，被路由器分隔在好多網段，甚至部分外部辦公室，頻寬只有E1 (2Mbps)的專線。

我一聽到以上需求的時候，我發現，我必須要解決兩個問題。


第一個問題是頻寬

七百多人，假設一個員工觀看影片，占用1Mbps，如果我還是採取單播(Unicast)的話，我在伺服器上面，就必須要提供至少700Mbps的頻寬，來播放這個影片。

當時的伺服器，雖然物理埠可以提供1,000Mbps的頻寬，我的確也可以將兩個埠做合併(Port Aggregation、EtherChannel)。但是，我沒有把握磁碟I/O是否跟得上這個速度。700Mbps遠比當時公司內部安裝在最高級硬體的Microsoft Exchange Server需求還要高。如果真的要這麼做，我需要好多部的伺服器，才能夠支撐全部的流量需求。

假設我真的要設計成多部伺服器，我的伺服器也需要增加額外的軟體，才能夠讓用戶端自動分散連結不同的伺服器，或是負載均衡的網路硬體。當時，這些額外增加的預算都不可行。

另外，外部辦公室的部分，如果使用單播，只有2Mbps頻寬的專線也不夠用。增加專線，預算上又不可行。


第二個問題是同步

不是全部的員工，都會同時打開播放軟體，假設有員工比較晚打開播放軟體，最好能夠同步地從現在的時間點開始看，而不是一律從頭開始觀看。

我們知道今天的技術，例如 YouTube Live，可以透過將影片分割成數秒鐘一段，即使只使用單播的技術，一樣可以達成類似同步的效果。可是，當年並沒有這樣的軟體。


IP Multicast解決我這兩個問題

最後，我在網路端的設計，只剩下一個選擇，那就是IP Multicast。

因為，我只要在伺服器端丟出一份的影片內容、一份的頻寬、一份的IP Multicast UDP/RTP封包，全公司的員工都可以收到。

延續前面的分析，伺服器端只需要丟出 1Mbps 左右的頻寬，全公司七百多人都可以同時收到。

路由器上面需要設定IP Multicast路由協定。所有UDP/RTP的封包，都是由中間的路由器來擔任往各網段複製封包的工作。到了VLAN裡面，就改由L2交換器擔任逐埠(per port)的封包複製。

我全部的路由器都是Cisco，因此，IP Multicast路由協定，很自然地就使用Cisco PIM (Protocol Independent Multicast)。

更好的是，封包收到的時間是完全同步的！PC端的軟體，不論何時打開軟體，都可以同步播出影片的內容。



One more thing…

因為沒有其他的預算，伺服器端我用既有的Windows Server (當時是Server 2003)的Windows Media Service，用戶端就只使用Windows Media Player。影片原始檔案是MPEG-1，我用Windows免費軟體轉換成 Windows Media的影片格式。

從網路的角度來看，UDP/RTP的封包，幾乎都是同時抵達用戶端的，可是我真正走到不同的座位觀察才發現，因為用戶端PC的硬體新舊、規格不一致，每一部PC真正開始緩存內容、播放，竟然有數秒鐘的時間差異，即使接在完全相同VLAN、交換器的PC。

我當時的同事，幫我想到一個辦法，讓全公司的人都有一致的音樂節奏可以做體操。方法是每個辦公室找一部PC一樣打開收聽IP Multicast，將影片中的聲音，接到各辦公室內的擴音(聲音廣播)系統，播放給整個辦公室聽。雖然PC上面的畫面有幾秒鐘的不一致，因為影片都是每天重複的，只要廣播的聲音是同步的，同事們覺得可以接受畫面的幾秒鐘的差異。

如果大家未來有類似的需求，IP Multicast將是您的好工具。我從這個故事也學習到，不是全部的問題，都可以用技術方法來解決，需要大家一起合作，一起發揮創意啊！

Fort Charlotte, Saint Vincent & the Grenadines

本文的照片，都是在這裡拍攝的。