Flash Player 간의 Peer-to-Peer 통신을 가능해주는
Flash 기술인 Stratus 에 대한 Adobe Labs의 포스팅입니다.
원문 : http://www.adobe.com/devnet/flashplayer/articles/rtmfp_stratus_app.html
많은 분들이 보실 수 있도록 번역해 보았습니다.
Real-Time Media Flow Protocol(RTMFP)는 Flash Player 10과 AIR 1.5에 추가된 새로운 통신 수단입니다. 기존의 RTMP와 가장 큰 차이는 RTMP는 Transmission Control Protocol(TCP)였지만 RTMFP는 User Datagram Protocol(UDP)기반이라는 것입니다.
TCP는 데이터의 안전한 전송을 보장하기 때문에 유저간의 응답속도는 썩 좋지 못합니다. 손실된 데이터를 재전송하는 방법으로 이메일이나 파일전송에 적합하기 때문에 속도가 늦어지게 됩니다. 0.01ms도 중요한 실시간 통신에는 유저간의 응답속도가 관건이기 때문에 TCP는 그다지 적합하지 않았습니다. 손실된 데이터 복구 기능은 Audio, Video 압축 기술(Speex audio나 H.264 codec 같은)의 핵심기술의 하나이기 때문에 TCP가 보장하는 데이터 무결성은 필요하지 않죠. Speex나 H.264 모두 Flash Player 10에 탑재되어 있는 기능입니다. 결론은 효율적이고 속도가 빠른 UDP인 것입니다. 그래서 UDP는 실시간 응답이 가능한 서비스에서 널리 쓰이고 있는 것이죠. TCP 대신 UDP가 사용됨으로써 얻는 것은 이뿐만이 아니라 Network Address Translators(NATs) 네트워크 주소를 이용한 클라이언트간의 직접 데이터 전송인 Peer-to-Peer가 가능하다는 것입니다.
RTMP에 비해서 RTMFP가 가지는 실시간 통신의 이점은 다음과 같습니다.
방화벽이 있을땐?
RTMFP는 UDP기반이기 때문에 연결하려는 두 클라이언트가 NATs나 방화벽에 의해서 보호되고 있다면 방화벽에서 UDP통신 채널을 허가해주어야합니다. 대부분의 소비자나 작은 오피스내지는 홈 오피스(SOHO)의 방화벽에서는 대부분 UDP 채널이 막혀있습니다.
===============================================================================================================
이 점선 부분은 저도 모르는 부분이라 해석도 난해하고 거의 직역에 가깝습니다 ^^;;
이를 해결하기 위해서 Flash Player를 TURN 프록시(Traversal Using Relays around NAT proxy)를 설정해줘야합니다. Flash Player는 IETF Internet Draft(draft-ietf-behave-turn-08)기능을 제공하기 때문에 네트워크 관리자가 누구나 접근 가능한 TURN proxy를 UDP 채널을 사용할 수 있도록 허가하려면 mms.cfg 파일에 다음과 같은 코드를 추가해주는 방법으로 Flash Player의 설정을 변경할 수 있습니다.
이렇게 설정하면 UDP 직접 통신으로 시도하게 되고 TURN 프록시는 백업용으로만 사용됩니다. 이는 Flash Player와 Stratus 사이 또는 Flash Player 간 통신하지 못하게 하는 UDP통신을 위한 것입니다.
그런데 만약 한명이 UDP 통신을 방화벽에서 허가했다하더라도 방화벽의 조합으로 인해서 end-to-end 통신이 불가능할 수도 있습니다. 다른 한명이 흔히 말하는 "Symentric Firewall"으로 보호되고 있다면 end-to-end 통신은 할 수 없습니다. (방화벽 형식에 대해서 알고 싶다면 위키피디아의 Network address translation을 참조하세요.) 이같은 상황에서도 TURN 프록시를 사용해야 할것입니다.
===============================================================================================================
Stratus service
Flash Player 객체는 다른 Flash Player와 통신하기 위해서는 Adobe Stratus service(주소 rtmfp://stratus.adobe.com)에 접속해야합니다. Stratus는 Flash Player 객체가 다른 Flash Player에(NATs 뒤에 있더라도) 연결하기 위한 호스트 서비스입니다. Stratus에 접속하는 방법은 Flash Media Server에 접속하는 방법과 매우 유사하지만 Flash Media Server가 제공하는 기능은 지원하지 않습니다.(media relay, shared object, remoting, etc.) Flash Player는 커뮤니케이션을 하기 위해서는 Adobe Stratus에 계속 접속해있어야합니다. Stratus에 접속하기 위해서는 Adobe Developer ID를 발급받을때 생성되는 개발자 키가 필요합니다.
RTMFP는 아직 공개되진 않았지만 Flash Media Server의 앞으로의 모습을 목표로 개발되었습니다. 앞으로는 Flash Media Server를 이용하면 Flash Player 10은 물론 Flash Player 9 객체끼리도 통신할 수 있고 이전 RTMP와도 통신할 수 있을 것입니다.
Security
RTMFP는 사용자 사이를 안전하게 통신할 수 있도록 Diffie-Hellmann 키 교환 방식에 기반한 128-bit AES 알고리즘이 사용됩니다. 하지만 RTMPS나 SSL처럼 최종 사용자 인증이 강력하지는 않습니다. 최종사용자 인증을 보강하기 위해서는 RTMFP와 ActionScript의 임시 보안(secure nonce)를 알아야합니다. 이 방식은 두 Flash Player가 서로를 인증할 수 있도록 해준다. 이렇게 함으로써 사용자 인증 과정 중간에서 공격 당하는 것을 방지할 수 있습니다. 이것은 개발키를 주고 받는 데도 사용될 수 있습니다.
하나의 Flash Player에서 다른 Flash Player로 사용자의 마이크와 웹캠에서 미디어를 전달하기 위해서 매우 훌륭한 기능입니다.
RTMFP에 대해서 더 자세하게 알고 싶은 분은 Adobe Labs의 FAQ를 참고하시기 바랍니다.
Real-Time Media Flow Protocol FAQ (PDF, 166k)
4 페이지중에서 앞 2 페이지입니다.
RTMFP의 전체적인 개요와 기능을 설명해주는 부분입니다.
뒷부분 2페이지는 예제와 코드에 대해서 다룹니다.
Flash 기술인 Stratus 에 대한 Adobe Labs의 포스팅입니다.
원문 : http://www.adobe.com/devnet/flashplayer/articles/rtmfp_stratus_app.html
많은 분들이 보실 수 있도록 번역해 보았습니다.
RTMFP를 이용한 end-to-end 서비스, Stratus
Adobe Flash Player 10과 Adobe AIR 1.5에서는 새로운 통신 수단인 Real-Time Media Flow Protocol(RTMFP)가 지원됩니다. 응답이 빠르고 end-to-end 직접 연결 통신, 보안, 대용량 전송이 가능한 실시간 통신 어플리케이션을 비용도 저렴하고 환상적인 UX를 제공하는 애플리케이션을 개발할 수 있게 되었습니다.
이전 Flash Player에서 사용되던 Real-Time Messaging Protocol(RTMP)는 FMS라 불리던 Flash Media Server가 중앙 서버로 꼭 필요했습니다. RTMP는 여전히 미디어 스트리밍이나 데이터 공유, 원격 통신에는 최선의 선택이지만 음성이나 영상 실시간 통신에서는 한계가 있었던건 사실입니다.
RTMFP를 사용하기 위해서는 FMS의 차기 버전인 Adobe Stratus beta 같은 RTMFP용 서버에 접속해야합니다. Stratus는 두 Flash Player 간의 커뮤니케이션을 연결하기 위한 호스트 통합 서비스이므로 FMS와는 달리 Media-relay, Shared Objects, scripting 같은 것은 지원하지 않습니다. Stratus는 한쪽의 Flash Player에서 다른 Flash Player와 직접 커뮤니케이션하기 위한 어플리케이션에만 사용될 수 있습니다.
Flash Player는 이미 인터넷에서 비디오서비스의 선두주자입니다. 훌륭한 미디어 압축 코덱과 RTMFP를 이용하면 Flash Player 10은 실시간 통신에서도 선두주자가 될 것입니다.
이번 포스팅에서는 실시간 애플리케이션에서 RTMFP가 가져다 주는 장점들을 소개할 것입니다. 그리고 RTMFP를 사용하기 위한 ActionScript 3.0 API를 설명할 것입니다. 마지막으로 VideoPhone 예제를 소개할 것입니다.
───────────────────────────────────────────────────────
요구사항
Flex Builder 3
- 체험판 / 구입 (영문판)
Flash Player 10
- Download
예제 파일
- stratus_article_assets.zip (ZIP, 13k)
요구사항
───────────────────────────────────────────────────────
이 포스팅을 이해하고 활용하려면 다음과 같은 소프트웨어와 파일들이 필요합니다.Flex Builder 3
- 체험판 / 구입 (영문판)
Flash Player 10
- Download
예제 파일
- stratus_article_assets.zip (ZIP, 13k)
───────────────────────────────────────────────────────
RTMFP의 장점.
───────────────────────────────────────────────────────RTMFP의 장점.
Real-Time Media Flow Protocol(RTMFP)는 Flash Player 10과 AIR 1.5에 추가된 새로운 통신 수단입니다. 기존의 RTMP와 가장 큰 차이는 RTMP는 Transmission Control Protocol(TCP)였지만 RTMFP는 User Datagram Protocol(UDP)기반이라는 것입니다.
TCP는 데이터의 안전한 전송을 보장하기 때문에 유저간의 응답속도는 썩 좋지 못합니다. 손실된 데이터를 재전송하는 방법으로 이메일이나 파일전송에 적합하기 때문에 속도가 늦어지게 됩니다. 0.01ms도 중요한 실시간 통신에는 유저간의 응답속도가 관건이기 때문에 TCP는 그다지 적합하지 않았습니다. 손실된 데이터 복구 기능은 Audio, Video 압축 기술(Speex audio나 H.264 codec 같은)의 핵심기술의 하나이기 때문에 TCP가 보장하는 데이터 무결성은 필요하지 않죠. Speex나 H.264 모두 Flash Player 10에 탑재되어 있는 기능입니다. 결론은 효율적이고 속도가 빠른 UDP인 것입니다. 그래서 UDP는 실시간 응답이 가능한 서비스에서 널리 쓰이고 있는 것이죠. TCP 대신 UDP가 사용됨으로써 얻는 것은 이뿐만이 아니라 Network Address Translators(NATs) 네트워크 주소를 이용한 클라이언트간의 직접 데이터 전송인 Peer-to-Peer가 가능하다는 것입니다.
RTMP에 비해서 RTMFP가 가지는 실시간 통신의 이점은 다음과 같습니다.
- 빠른 속도 : UDP기반의 RTMFP는 지연율(latency)가 매우 낮습니다. 빠르다는 의미입니다. 이 점은 RTMFP가 무결성 전송과 그렇지 않은 전송을 모두 할 수 있다는 것을 의미합니다. 두 Flash Player간에 NetStream.send()메소드처럼 순수한 데이터를 전송할때는 무결성 전송이 사용되고 Speex audio를 전송할때는 무결성 전송이 아닌 최소 지연 전송 방식이 선택됩니다.
- End-to-end 미디어 통신 : 미디어 데이터가 중간 서버없이 두 Flash Player끼리 직접 주고 받을 수 있습니다. RTMP가 Flash Media Server를 통해야지만 주고 받을 수 있었던 것에 비해서 RTMFP는 end-to-end이기 때문에 속도도 매우 빠르고 중간 서버가 없기 때문에 생산비용이 엄청나게 절약될 수 있습니다.
- 데이터 우선순위 : 오디오 데이터는 비디오 데이터나 실시간과 상관없는 데이터(채팅메시지같은)보다 우선 순위로 전송됩니다. 이것은 유저가 커뮤니케이션에서 어긋남을 느끼지 않도록 하는 매우 획기적인 방법입니다.
방화벽이 있을땐?
RTMFP는 UDP기반이기 때문에 연결하려는 두 클라이언트가 NATs나 방화벽에 의해서 보호되고 있다면 방화벽에서 UDP통신 채널을 허가해주어야합니다. 대부분의 소비자나 작은 오피스내지는 홈 오피스(SOHO)의 방화벽에서는 대부분 UDP 채널이 막혀있습니다.
===============================================================================================================
이 점선 부분은 저도 모르는 부분이라 해석도 난해하고 거의 직역에 가깝습니다 ^^;;
이를 해결하기 위해서 Flash Player를 TURN 프록시(Traversal Using Relays around NAT proxy)를 설정해줘야합니다. Flash Player는 IETF Internet Draft(draft-ietf-behave-turn-08)기능을 제공하기 때문에 네트워크 관리자가 누구나 접근 가능한 TURN proxy를 UDP 채널을 사용할 수 있도록 허가하려면 mms.cfg 파일에 다음과 같은 코드를 추가해주는 방법으로 Flash Player의 설정을 변경할 수 있습니다.
RTMFPTURNProxy=ip_address_or_hostname_of_TURN_proxy
mms.cfg 파일 위치 찾기
Microsoft(Vista, XP and 200)
- Windows\System32\Macromed\Flash
Macintosh
- /Library/Application Support/Macromedia
Linux
- /etc/adobe/
Microsoft(Vista, XP and 200)
- Windows\System32\Macromed\Flash
Macintosh
- /Library/Application Support/Macromedia
Linux
- /etc/adobe/
이렇게 설정하면 UDP 직접 통신으로 시도하게 되고 TURN 프록시는 백업용으로만 사용됩니다. 이는 Flash Player와 Stratus 사이 또는 Flash Player 간 통신하지 못하게 하는 UDP통신을 위한 것입니다.
그런데 만약 한명이 UDP 통신을 방화벽에서 허가했다하더라도 방화벽의 조합으로 인해서 end-to-end 통신이 불가능할 수도 있습니다. 다른 한명이 흔히 말하는 "Symentric Firewall"으로 보호되고 있다면 end-to-end 통신은 할 수 없습니다. (방화벽 형식에 대해서 알고 싶다면 위키피디아의 Network address translation을 참조하세요.) 이같은 상황에서도 TURN 프록시를 사용해야 할것입니다.
===============================================================================================================
Stratus service
Flash Player 객체는 다른 Flash Player와 통신하기 위해서는 Adobe Stratus service(주소 rtmfp://stratus.adobe.com)에 접속해야합니다. Stratus는 Flash Player 객체가 다른 Flash Player에(NATs 뒤에 있더라도) 연결하기 위한 호스트 서비스입니다. Stratus에 접속하는 방법은 Flash Media Server에 접속하는 방법과 매우 유사하지만 Flash Media Server가 제공하는 기능은 지원하지 않습니다.(media relay, shared object, remoting, etc.) Flash Player는 커뮤니케이션을 하기 위해서는 Adobe Stratus에 계속 접속해있어야합니다. Stratus에 접속하기 위해서는 Adobe Developer ID를 발급받을때 생성되는 개발자 키가 필요합니다.
RTMFP는 아직 공개되진 않았지만 Flash Media Server의 앞으로의 모습을 목표로 개발되었습니다. 앞으로는 Flash Media Server를 이용하면 Flash Player 10은 물론 Flash Player 9 객체끼리도 통신할 수 있고 이전 RTMP와도 통신할 수 있을 것입니다.
Security
RTMFP는 사용자 사이를 안전하게 통신할 수 있도록 Diffie-Hellmann 키 교환 방식에 기반한 128-bit AES 알고리즘이 사용됩니다. 하지만 RTMPS나 SSL처럼 최종 사용자 인증이 강력하지는 않습니다. 최종사용자 인증을 보강하기 위해서는 RTMFP와 ActionScript의 임시 보안(secure nonce)를 알아야합니다. 이 방식은 두 Flash Player가 서로를 인증할 수 있도록 해준다. 이렇게 함으로써 사용자 인증 과정 중간에서 공격 당하는 것을 방지할 수 있습니다. 이것은 개발키를 주고 받는 데도 사용될 수 있습니다.
하나의 Flash Player에서 다른 Flash Player로 사용자의 마이크와 웹캠에서 미디어를 전달하기 위해서 매우 훌륭한 기능입니다.
RTMFP에 대해서 더 자세하게 알고 싶은 분은 Adobe Labs의 FAQ를 참고하시기 바랍니다.
Real-Time Media Flow Protocol FAQ (PDF, 166k)
4 페이지중에서 앞 2 페이지입니다.
RTMFP의 전체적인 개요와 기능을 설명해주는 부분입니다.
뒷부분 2페이지는 예제와 코드에 대해서 다룹니다.
'Adobe AIR > AIR 강좌' 카테고리의 다른 글
| [펌] UXD(User eXperience Design)란? (17) | 2009.06.29 |
|---|---|
| [AS3] OOP를 지향하기 위한 몇 가지 팁. (45) | 2009.03.05 |
| [기술문서] AIR로 할 수 없는 것들 (11) | 2009.01.21 |
| [AIR, 번역] AIR 개발자가 흔히하는 실수 10가지 (23) | 2008.08.25 |
| [AIR] 완성도 높은 어플리케이션을 만들어 보자. (7) | 2008.07.25 |
