如果您喜歡這裡的內容,記得分享到您的Facebook和Twitter上面所有的朋友們吧!

2016年10月23日 星期日

健康操和組播(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




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


如果您喜歡這篇文章,不考慮試試Email訂閱嗎?


Related Posts with Thumbnails

0 意見:

張貼留言

小技巧:也可以 匿名 留言!

經典熱門文章