Anistar RIA Blog

接續[深入淺出 Flash Media Server (RTMP)介紹 part II]這篇，補完整個RTMP的Overview…

建立Flash Media Server的應用程式要透過兩邊來完成，一邊是一般我們所熟之的ActionScript，你可以採用ActionScript 1.0~3.0的語法來完成，不過ActionScript 3.0的差異於其他版本差異非常的龐大，所以同時寫兩種版本實在是看起來很累贅，接下來的Demo Code我就直接用ActionScript 3.0來做示範，這一方面是ActionScript 1.0~2.0的寫法在其他的網站上都寫過了，寫大家都寫過的有點無聊，所以要看1.0~2.0可以麻煩大家移駕到其他網站，在這邊我們就寫新的吧，另外一方面ActionScript 3.0真的比之前的版本powerful多了，而且現在我教也是使用ActionScript 3.0，所以用3.0的方法來寫。

除了Client端的ActionScript之外，Flash Media Server也可以撰寫程式語言，這個語言稱之為SSAS，是Server-Side ActionScript的縮寫，他的寫法根一般的ActionScript非常的類似，只不過提供了一般ActionScript所沒有提供的功能。

所有的串流應用都可以用硬幹(hardcoded)的方式來完成(抱歉，我喜歡將這個字翻譯成硬幹)，不過也只有透過硬幹的方法你才能全盤了解整個流程跟架構啦，或是選用Flash所提供的組件來使用，例如SimpleConnect、PepoleList、VideoConference、FLVPlayer等元件來完成工作。

RTMP可以用來串流影音與資料，聲音(Audio)的部份可以使用MP3與Nellymoser的格式，影片(Video)則可以使用FLV的格式，ActionScript資料的部分則採用AMF(Action Message Format)的格式。在一般的Media Server中大多使用UDP來傳送影音資料，雖然UDP並沒有TCP來的可靠，但是對於影音應用來說就算掉了一點資料也無所謂，因此UDP的特性反而成為他的優點，使用UDP將會讓資料傳輸更快，在一般的狀況下UDP的表現會比TCP要來的出色。

UDP可以被拿來執行廣播或聯合發送的動作，若是廣播模式可以用的話，在大量使用者使用下將可以有效降低伺服器的Loading，不幸的有些ISP業者為了安全性的理由不會允許你這麼做，這時候就必須要使用聯合發送的方式來達到廣播的目的，聯合發送的意思是指Server必須自己複製Stream，並分別的發送到各自的Client中，若是Client因為某些原因無法允許聯合發送的Stream時，UDP media server將會改用TCP來做傳送的動作。

RTMP提供了比一般串流媒體伺服器更多的功能，傳遞的Stream終將可以包含Video、Audio、ActionScript Data，RTMP將這些資料分開管理，當傳送的是ActionScript Data時，任何的資料將不會被捨去(若是Video和Audio在頻寬壅塞的時候可能會丟棄一些資料，一方面UDP也可以能是造成這個原因的兇手)，因為若丟棄了某些資料，可能會造成應用程式上的困擾，例如資料驗證等。就發送與處理的優先順序而言，Audio的優先順序是最高的，其次是ActionScript Data，最後才輪到Video。

這樣一來大家對Flash Media Server的運作大概就有些概念了，先停在這邊，下次來講一下ActionScript 3.0與Flash Media Server幾個交換資料的簡單範例。

待續…