octoshape

Octoshape是一個p2p流媒體伺服器以及客戶端, 使用點對點格線技術來儘可能的減少轉播數據流所占用的頻寬，從而達到讓所有廣播流媒體占用最小的頻寬就能播放。Octoshape 採用HTTP 方式連線伺服器，採用UDP 方式傳輸數據，默認UDP 連線埠為：554、5060。Octoshape是目前高清晰直播視頻技術的領航者，它將為日益增多的網路高清直播提供解決方案。

Octoshape是一個p2p流媒體伺服器以及客戶端, 使用點對點格線技術來儘可能的減少轉播數據流所占用的頻寬。Octoshape是目前高清晰直播視頻技術的領航者，它將為日益增多的網路高清直播提供解決方案。
實時流媒體本身及其套用正變得越來越流行，個人網路連線也正在快速擴展，並且還有部分網民在利用無線網線技術隨時隨地得接入網際網路。實時流媒體的網路傳播本身存在兩個問題：規模和負載。它的挑戰是在不增加網路負擔的條件下，使用某種協定將單個網路資源同時傳送給多個用戶。實時流媒體的發展給網路傳輸造成很多技術上的難題，可以從Franc Kozamernik的著作中看到介紹，本文的焦點是在不增加網路負載的情況下傳輸大規模的實時流媒體數據。實時流媒體與下載播放和點播不同，它經過網路傳輸對事件現場進行直播。
本文將首先討論實時流媒體傳輸的各種技術，包括比較傳統的技術，研究規模和負載的問題是如何產生的，這樣，我們就可以清楚的知道目前的技術是怎么解決問題的，最後將介紹Octoshape，它提供了一種較好的解決以上兩個問題的方法，也將說明Octoshape是如何在這方面獲得優勢的。
1．規模和負載問題
上面已經提到規模和負載會引發一些問題。由於網路結構設計為點對點的傳輸檔案，且檔案只能在完全下載後才能使用或觀看，這與一個數據源對應多個用戶的無限傳輸理論的觀點完全相反，所以問題在逐漸增加。舉例來說，多個用戶同時需要一個傳播者的視頻信號，那么這個單一的數據源就需要同時分別向多個用戶傳送數據，這就是為什麼需要增加頻寬（代表網路性能）來應付數據流增加所帶來的網路負載。
進一步說，這也是負載很難均衡的原因。向多個網路用戶同時分別傳輸數據造成了網路瓶頸，而網路瓶頸必然引起終端用戶數據的不穩定，在最壞的情況下，用戶會收到“伺服器忙”的訊息。雖然規模和負載的問題使實時流媒體的播放質量很難達到要求，但是網民對這種新興的技術很感興趣，要求也越來越高。
2．大規模實時流媒體傳輸的解決方案
某些技術對規模和負載所引發的問題採取不均衡的解決方法，這篇文章中，我們首先介紹這些較偏頗的解決方法，然後呈現Octoshape，並對它們進行對比。
到目前為止，格線技術有幾種廣泛套用，如P2P的檔案共享程式BT，它提供電影和音樂檔案共享，用戶就可以使用多個數據源互相下載檔案，這樣就不會造成單方面網路負載的增加。文章的最後，我們將討論Octoshape如何均衡提到的兩個問題，來提供實時流媒體檔案的，簡單的說就是用較小的負載傳播大規模的數據檔案。雖然Octoshape只是一種解決方法，但是它仍然允許用戶建立個人的共享網路。
2．1 媒體伺服器：單播與平衡下載
單播是一種典型的實時數據流傳輸連線方式，如圖1所示。這裡，我們所指的結構使用一個或成群的伺服器來管理用戶請求數據，伺服器群能夠平衡機器下載並使這結構裝更健壯，因為即使伺服器群中的某台機器損壞，其它數據共享的伺服器也可以向用戶繼續傳送同樣的數據，這樣一種結構就稱為媒體伺服器，它所在網路的大小或其能力同樣用頻寬表示。舉例來說，假設媒體伺服器的網路頻寬是100Mbit/s，那么一個100kbit/s的音頻數據流理論上最多就可同時傳送給1000個用戶。一些大規模的傳輸網路擁有兩個或三個媒體伺服器，即便那樣，頻寬需求與用戶數量仍然需要保持一定的比例，可用下面的公式表示：
Bandwidth_Needed = Size_of_Audience X Streaming_Quality
負載問題：傳送兩倍的數據需要兩倍的頻寬，要滿足三倍的用戶就需要三倍的頻寬，換句話說，如果傳送數據量增加或者用戶增加，那么負載也一定會相應的增加。
規模問題：如果所有的數據都來自於同一個數據源（或兩個），那么，這個連線點的頻寬使用會很快達到它的上限，瓶頸問題與“伺服器忙”的現象就會很快出現，這與早上同一家庭的所有成員同時出門去上班的現象相同，幾個人不可能同時穿過一個門。這個問題很難解決，同時也說明為什麼成倍的數據傳輸會引起成倍的頻寬負載。
2．2 CDN：目前廣泛使用的技術
CDN技術最初的目標是解決世界範圍內的網路延遲問題，來有效掌控對同一網頁同時的大量訪問。它的主要思想是安置成千上萬的機器，即邊緣伺服器，分布在世界範圍的網路轉換點上，同一個網頁可以存儲在這些邊緣伺服器上，這樣，當用戶請求這個網頁的時候，就可以從最近的本地邊緣伺服器獲取，結構如圖2所示。這就增強了對同一資源可能的大量同時訪問現象的掌控，同樣也減小了檔案下載所占用的頻寬。現在，CDN技術也被用在實時流媒體傳輸上，有一部分公司目前正在提供類似的問題解決方法。
對實時流媒體傳輸問題的解決辦法與對網頁的處理是類似的，雖然上面只是對CDN技術的簡單介紹，但是仍能明顯看出，CDN技術比媒體伺服器方式更具規模化，因為它旨在世界範圍內分布成千上萬的邊緣伺服器。儘管這樣，資源共享也只對向邊緣伺服器請求相似資源的用戶成立，因為大量的網路邊緣機器不能本地化。例如，假設在英國發布一個大事件，CDN技術對英國範圍以外的訪問幫助不大，因為不管怎么處理，英國以外的網路訪問都需要經過同一個轉換網路進入英國。CDN技術能在一定範圍內解決規模問題，但它不能解決負載問題，因為它引入了太多的機器。
2．3 多播：多地址傳輸同一數據
如果問五個人多播技術的定義，或許能得到多於七種不同的答案。這裡，我們將介紹兩種，希望能涵蓋大部分的觀點，在提供這兩個定義之前，我們首先給出一個IP的確切定義。開車去一個確定的地方，就需要知道這個地方的明確地址。同樣，在網上傳輸數據，也需要知道這個數據的目標地址，這個網路目標地址就稱為IP位址。我們都知道，每台機器都使用自己的IP位址連線到網路，而數據流通過IP位址尋找傳輸路徑與目標機器。
有些特殊的IP位址被預留出來為多播使用，這些地址被稱為多播地址。使用多播的主要目的是傳送數據時，可以通過一個地址一次傳給多個用戶，傳送到多播地址的數據將同時傳給在地址中標記的用戶。多播的使用可追溯到20世紀80年代，當時人們為此付出了巨大的努力。雖然多播IP位址不是一個物理實體，但是它必須有硬體和軟體的支持，最大的問題是什麼使之成為可能？它是如何實現的？如果虛擬用戶使用它將會發生什麼？誰將為此負責？目前，如果交換機/路由器在本地網路中實現多播，那么企業內部使用多播將成為可能。
2．4 P2P流媒體傳輸：負載共享
使用前面描述的任何一種技術時，用戶都只是接收數據卻不會傳出，即使這個用戶既可以是單純的用戶也足夠成為傳播者。這就說明，前面的解決方法把重擔都放在了終端上，即數據源一端，這將意味著雖然某個數據源用戶的頻寬使用達到極限，數據源用戶卻什麼也沒得到。
P2P流媒體傳輸的思想就是使終端用戶能夠使用空閒頻寬，這樣在數據源上的負載可用下面的公式表示：
Streaming_Quality X Audience_Size – Used_Idle_End user_Bandwidth
P2P傳輸的過程是，一個傳播者可以只向一個用戶傳輸數據，而接收數據的用戶接著可以再傳給下一個用戶，這樣一直向下傳輸。理論上講，一個傳播者只傳輸給一個用戶就可以擁有無數個用戶，但是，技術上是無法實現較長用戶鏈的。
事實上，基於用戶傳送能力的原則會起到一定的作用。一些軟體公司，開源軟體和學校工程正在使用這種方法，在它的理論指導下，基於樹結構實現如下過程：一個傳播者將數據傳送給兩個用戶，這兩個用戶再分別傳送給兩個或更多用戶，這樣一直向下傳輸，如圖4所示。用這種方法可避免前面提到的用戶鏈過長問題，這種方式就稱為P2P傳輸技術。P2P技術已經成功套用於10-100個同時操作的流媒體用戶規模中，並且可使用伺服器組對其進行擴展，小規模下的數據傳輸與較低的傳播速率可將頻寬需求降低40％－50％。
如圖中看到的，P2P伺服器似乎只輸出兩個數據流，幾乎可能節省100％的頻寬，但是，實際上是不可能的，下面我們作出解釋：
（1） 終端用戶需要輸出與接收數據近似相等大小的數據流，但是，DSL只用於從伺服器端向客戶端傳輸，不能用於其它的方式，與此接近的一種方法是降低傳播速率 。
（2） 在樹結構中，大部分用戶作為樹的葉子存在於最低級別中，只能接收數據而不能向外輸出，因此，大量用戶中只有少數共同承擔帶寬的問題。
（3） 具體來說，當傳播一個150kbit/s的數據流時，只有達到150kbit/s的用戶才能為數據傳輸作出貢獻，具有128kbit/s傳輸能力的用戶根本起不到作用。
（4） 當某個用戶關掉機器後，或許與其臨近的正接收數據的用戶會丟失數據源，P2P服務也必須重新構造樹形式的網路結構。
在各種因素的影響下，很難建立一種健壯穩定的用於大規模的P2P數據服務結構，此外，將來這個問題會更加難以解決，原因是目前的P2P流媒體傳輸使用通信協定TCP，它不允許使用地址轉換的用戶(使用無線路由器)互相傳輸數據。
2．5 網狀結構：用於大規模實時流媒體傳輸的Octoshape
Octoshape技術與傳統的伺服器技術相比節省了97％的頻寬需求，這樣就基本不存在頻寬負載問題，也就不存在限制大規模化的瓶頸問題。為達到P2P樹結構的目的，Octoshape使用外掛程式減小傳播者頻寬的需求，達到使用戶共同承擔頻寬的目的。Octoshape與廣泛使用的檔案共享程式相似，在詳細介紹Octoshape技術之前，我們先看一下檔案共享程式。
檔案共享程式，如BT和Kazaa，廣泛套用於電影和音樂類檔案的共享，用戶可以通過個人的PC機互相傳輸數據，包括數據請求與接收，實際上，根據報導，正是這些檔案共享程式造成了70％的網路擁塞問題。BBC也正在測試以實現節目共享，它的重點就在限制頻寬負載上，檔案共享程式只能用於下載，而不能用於實時流媒體，如一段音樂，用戶只能完全下載後才能正常播放。
伺服器向用戶傳輸數據後，用戶可改變數據來減小頻寬需求，一個用戶不僅可以向多個用戶同時傳送數據，也可以同時從幾個用戶那裡接收數據。能夠同時從其它用戶那裡接收數據是Octoshape的目的，這對系統的整體效率是至關重要的。
在P2P樹結構中，一個用戶只能接收另一個用戶的數據，但是Octoshape用戶可以同時從多個用戶1，2，3中接收數據。如圖6所示：
這裡仍然考慮用戶互相傳輸數據的場景，在圖6中，如果接收數據的用戶要下載一部電影，那么向其傳輸數據的三個用戶可分別向其傳輸電影的一部分，如電影中間或者最後30分鐘的內容。Octoshape的兩個特點是：
（1） 用戶可以同時從多個用戶中接收同一檔案的不同部分。這就允許不同的用戶同時向同一用戶傳輸數據，能充分利用用戶的下載能力。
（2） 如果某個正在傳輸數據的用戶堵塞或者關機，檔案的接收用戶可以選擇網路中的其它用戶繼續接收中斷數據。通過這種方法，使用戶獨立於單一的數據源。
與用於檔案下載相比，Octoshape技術用於實時流媒體傳輸比較困難。如果傳輸數據的用戶關掉機器，它需要花費時間找到其它的數據傳輸用戶，這對檔案下載只是時間問題。但是，在實時流媒體傳輸中，這樣會造成客戶端媒體播放中斷，直到找到其它合理的數據源。此外，為實時流媒體提供獨立的網路也比較困難，用戶不可能同時接收流媒體檔案前面，中間或者最後的部分，因為對於實時流媒體檔案來說，這些部分根本不存在。
Octoshape實時流媒體技術為使網路達到最大的效率包含很多方面的內容，下面我們對其中幾項關鍵技術作出解釋。一般音頻或視頻檔案才會被作為實時數據流傳輸，而在實時數據流中，數據會按邏輯進行排序，沒有兩個數據是完全相同的。舉例來說，假定實時流媒體檔案的傳輸速率為400kbit/s，而每一個數據流的速率為100kbit/s，在Octoshape解決方式中，不同的數據流會按邏輯順序重新排序，上面的例子中，用12個數據流描述一個畫面，某用戶接收到其中任意4個100kbit/s的數據流後，就可以用它們恢復出原始畫面，這樣就可實現用戶對媒體的實時播放。如圖7所示：
下面，我們把焦點放在網路數據用戶上。在Octoshape技術中，每個終端用戶都有屬於自己的獨一無二的數據流，因此不同的數據流個數就代表了不同的終端用戶數，這些數據流以共享的方式存在，不會給傳播者造成負擔。每個用戶既可以將自己的數據流傳輸給0，1，2，3，甚至更多的用戶，也可以從其它用戶那裡接收100kbit/s的數據流，然後將這些數據流重新構造出原始的實時媒體檔案。圖8表示一個用戶從四個用戶那裡接收數據後又傳送給三個用戶：
下面說明這些方面為什麼能使網路達到最好的效率：
穩定的連線：終端用戶一般都會維護一個相鄰用戶的連線表，每個終端用戶都會不斷向鄰居發出請求以確認連線，一旦有用戶堵塞或停止傳送數據，可以及時找到替代用戶。如果這個連線表太小，可以從地址簿中添加。
避免瓶頸問題：如果某個用戶陷入堵塞，與其連線的用戶會從連線表中找到其它用戶代替，通過對連線的不斷更新維護，用戶就可避免瓶頸和堵塞問題。
不存在伺服器的下載：既然每個用戶都有地址簿和連線表，就沒有必要在傳送數據的用戶中斷後給伺服器增加負擔。
靈活使用頻寬：用戶通過減小傳輸實時流媒體的數據流大小來減小自己的網路負載，這樣就使整個系統變得比較靈活。用戶用低於媒體數據流大小的上傳能力可上傳較少的數據流，用戶的上傳能力較高或許可以上傳更多的數據。為得到完全的靈活性，數據量與流的比率應該大於4，用戶使用實時數據流的平均速率傳送數據就可節省97％的頻寬。
做到不可能的：假設一組用戶使用某種方式連線在一起，與前面那個英國的例子類似，在一個地區或城市中，這組用戶通過較小的網路連線在一起，某個用戶需要向其它地區的用戶傳輸數據，一般情況下，此網路中所有的用戶都需要參與數據傳輸，而如果使用Octoshape技術，數據只需要傳給組中的一個用戶就可遍布其它用戶。
如果用戶都能做到儘量節省數據，有穩定的連線時不從伺服器下載數據，就能減少本地甚至全球的網路堵塞與瓶頸問題，就能用較小頻寬實現大規模數據傳輸，就能實現高質量的流媒體傳輸。