다음 이전 차례

9. 멀티캐스트 트랜스포트 프로토콜

지금까지 UDP를 이용한 멀티캐스트 전송에 대해 알아보았다. TCP에서는 불가능하기 때문에 이상이 일반적인 내용이다. 그렇지만, 좀더 새로운 멀티캐스트 트랜스포트 프로토콜 (Multicast Transport Protocols) 을 만들어내기 위해 지난 몇 년간 집중적인 연구가 계속되고 있다.

새로 개발된 프로토콜 가운데 몇 가지는 구현 단계를 거쳐 테스트 단계까지 이르고 있다. 모든 형태의 응용에 적합한 일반적인 멀티캐스트 트랜스포트 프로토콜은 존재하지 않는다는 것이, 연구를 통해 밝혀지는 것 같다.

아주 복잡하고 조정하기 어려운 프로토콜에서 다음과 같은 문제들을 생각해 보자. 지연(멀티미디어 회의에서), 자료 손실, 패킷 정렬(ordering), 재전송, 흐름 및 혼잡도 조정, 그룹 관리 등.....게다가 수신자가 하나가 아니라 수백 수천 개의 저밀도 분산 호스트들이라면...이런 경우에 조정에 큰 곤란을 겪을 것이다. 따라서, 수신한 모든 패킷에 대해 수신 확인(ACKs)을 보내는 대신, 수신하지 못한 패킷에 대해서만 수신 불량 신호(NACKs)를 보내는 식의 알고리즘을 개발한다. RFC 1458 이 멀티캐스트 프로토콜 요구사항을 제안하고 있다.

멀티캐스트 프로토콜에 대한 자세한 해설은 문서의 범위를 넘기 때문에 더 이상 설명하지 않을 것이지만, 대신, 프로토콜 이름과 자료를 찾아 볼 수 있는 요점만 짚고 넘어가도록 하겠다. Real-Time Transport Protocol (RTP) 은 분산형 멀티미디어 회의(multi-partite multimedia conferences)와 관련 있으며, Scalable Reliable Multicast (SRM) 은 wb (the distributed White-Board tool, see section ``Multicast applications'')가 사용한다. Uniform Reliable Group Communication Protocol (URGC) 은 중앙 집중식 제어에서 자료 처리(transaction) 가 신뢰적이며 정연히 이루어질 수 있도록 도와준다. Muse 는 MBone 에서 뉴스를 전송할 수 있도록 특정 프로그램용으로 고안된 것이며, Multicast File Transfer Protocol (MFTP) 은 문자 그대로 파일 전송과정 회의에 참여하듯이 참여 할수 있도록 해주는 프로토콜이다. Log-Based Receiver-reliable Multicast (LBRM) 은 기록 서버(logging server) 로 보내지는 모든 패킷을 추적하여 전송측에 데이터를 다시 전송해야하는지 아니면 이상 없이 수신되었는지 알려주는 특이한 프로토콜이다. 또 한가지, 멀티캐스트 프로토콜이면서 STORM (STructure-Oriented Resilient Multicast)이라는 재미있는 이름을 가진 프로토콜도 있다. 웹을 찾아보면 이 외에다 많은 멀티캐스트 프로토콜이 있으며 멀티캐스트를 이용해 새로운 일들을 벌이려는 재미있는 내용의 글들도 많다.(예를 들어, 멀티캐스트를 이용한 웹 페이지 자동 전송 같은 것)

멀티캐스트 프로토콜간의 신뢰성비교는 http://www.tascnets.com/mist/doc/mcpCompare.html을 참고하라.

멀티캐스트와 관련한 흥미로운 링크들과 최신 정보(인터넷 초안, RFC, 논문, 링크)가 가득한 아주 좋은 사이트다. http://research.ivv.nasa.gov/RMP/links.html

여기도 좋은 정보가 많다. http://hill.lut.ac.uk/DS-Archive/MTP.html

Katia Obraczka의 "Multicast Transport Protocols: A Survey and Taxonomy" 라는 글은 각 프로토콜에 대한 간단한 설명을 하고 기능상 차이점으로 분류하고 있다. 이 글은 IEEE Communications magazine, January 1998, vol. 36, No. 1. 에도 실려있다.


다음 이전 차례