주제 : Stream-oriented & Multicast communication

Stream-oriented-communication

이전까지는 데이터의 종류가 text인 경우,
이제 멀티미디어 데이터다. 오디오나 비디오 같은.
Transport layer에서는 데이터의 종류는 알빠 아니다. 그냥 전달만 제대로 해준다.
그 위의 App 레이어에서 고려할 사안이 많아지는 것이다.

중요 포인트 : Timing(끊김없이)

데이터 스트림 : 결국 0,1의 집합

types of mode

Async

• Time 제약 없음
• 파일 전송 : 빨리 보내는 것보다 정확히, 신뢰성이 더 중요

Sync

• Time constraint 존재
• "최대 딜레이"가 있어서, 그 딜레이보단 늦어지면 안됨.
• ex. 온도 등의 순간 센서 데이터

Isochronous

• 최대 딜레이 + 최소 딜레이가 있어서, On-time에 전송해야됨..
• Ex. distributed multimedia

types of Stream

Single stream & Complex stream

Single stream

• 니가 아는 스트림

Complex stream

• 2개 이상 single stream이 섞임
• ex. Movie(audio + image), streao(left+right)
• 두 스트림의 싱크를 맞춰야 되기에 어려움

QoS Controller 를 둬서 이 미들웨어 단에서 압축을 도와줄 수 있다.

Quality of Service, QOS

Timeliness,Volume,Reliability

• 전송 딜레이가 짧아야 됨.
• 데이터 보내기 전 셋업 딜레이
• End-to-End 딜레이가 짧아야 됨.
• Delay variance (jitter)

딜레이 줄이는 방법

Network level solution

• 멀티미디어 패킷의 구분자를 둬서, 다른 패킷들보다 우선순위를 높게 해주기

App level solution

• Buffering : 받는 쪽에서 버퍼를 두고, 어느정도 쌓이면 플레이 (Jitter 줄이기)
• Foward Error correction :
  - 중간에 빠진 패킷을 복구할 수 있는 기술 (UDP에서)
  • 받은 패킷들만으로 부가적인 정보로 없는 패킷의 복구
• Interleaving frame technique
  

데이터 프레임을 순서대로 패킷에 보냈다가 잃어버리면, 한 부분이 통으로 날라가니,
프레임을 섞어서 보내서, 잃어버려도 사용자는 눈치 못채게 하자는 방법.

Stream Sync

• 특정 Slide에 Audio는 쉬운데, continuous인 경우 어려워짐
• Sync Middleware를 둬서 처리할 수 있겠다.
• 싱크를 받는 쪽에서 할 거냐, 받은 쪽에서 할거냐? : 보낸쪽에서 맞춰주는게 쉽지

---

Multicast communication

Multicast

• 여러 Receiver가 있는 경우
• 라우터에서 처리를 해주는데, 대부분 기능을 꺼둔다.

문제

• 라우터 단에서 패킷을 복사해서 여러 쪽에 보냄
• 방송에 특화
• 보내는 App은 누가 받는지 몰라, 특정 멀티캐스트 주소(따로 주소 레인지가 있음)로 보냄
• UDP와 비슷하게, 소켓 지정시 멀티캐스트로 하고, 받는 주소도 멀티캐스트용 주소로
• 라우터에서 안 해주면 앱 레이어에서 해야됨.
• 전송 Path를 앱에서 정해야되서, 관리 코스트 늘어남.
• 왜 라우터에서 안해줘? : 돈 받아야 되는데 파악이 어려워
• P2P는 대부분 앱 레벨에서 이를 해결함

App level multicasting

Basic idea

• 오버레이 네트워크를 어떻게 구성할 것인가?
• 라우터에게 기대 안함

아래처럼 개무식하게 보낼 수도 있다. (내가 이리 구현했는데)
하지만 이렇게 하면 피어 늘어날수록 부담이 커지니, 다른 구조로 구현할 수도 있을 것이다.

다양한 방법을 사용할 수 있을 것이다.

핵심 : 오버레이 네트워크를 어떻게 구축할 것인가?

overlay network = logical path
mesh(graph) or tree?

Multicast in Scribe system

트리의 루트를 찾아 메시지를 쫙 뿌리는 방식
메시지를 받고 싶으면 Tree에 Join 하면 된다.

LOOKUP(MID) : root에 붙으면 star가 되니, root를 찾아가는 도중에, 해당 tree에 참여하고 있는 노드에 붙는 방식

노드 종류

• Pure forwarders (트리에 안 붙어있는데 전달만)
• Joined tree + Forwareder (트리 참여자)

효율적인 트리 판단의 기준

A가 루트라고 생각하면, 트리 구조는
A => B => D => C 구조다.
그러나 라우터까지 고려한 Path는
A ⇒ Ra ⇒ Rb ⇒ B ⇒ Rb ⇒ Rd ⇒ D…..
이런식으로 될텐데, 라우터 Rb가 여러번 사용된다.
이런 중복 path를 줄일 수록 좋은 것이다.
그렇다고 A에 다 붙는 건 star구조라 안 좋다.

Cost 정의

1. Link stress
   하나의 링크가 받는 스트레스 (중복 사용될수록 늘어남)
2. Stretch
   어떤 라우터를 거치냐를 포함해서 봤을 때 최적의 루트 (현재 cost / 최적 cost)
3. Tree cost
   트리의 전체적인 cost
   ex. 모든 노드가 메시지 받을 때 까지 시간?
   실제로 노드가 늘어날수록 트리의 종류도 많아지기에, 최적의 tree를 찾는데만 100만년 걸림.
   그래서 실제론 Suboptimal한 트리를 사용함.
   랑데뷰 노드 : 새로 Join할 때 어떤 정보가 있는지 알려줘서 좋은 노드 찾기.