11 5 회의

안건1 : 아키텍처 설계

나온 이야기

헥사고날 아키텍처 설계는 어떤가?

: 조금 어려울것 같지만 간단하게 의존성만 신경써서 해보자

안건2 : WebRTC, 시그널링 서버가 필요한가?

원래는 시그널링 이후에 클라이언트가 정보를 가지고 클라이언트와 SFU 서버를 연결하여 스트림을 보내는 과정이다.

그런데 우리는 단방향 스트리밍인데, 시그널링 과정이 필요한가? 시그널링은 p2p 방식에서 서로의 정보를 알기 위해 있는것이 아닌가?

클라이언트 쪽도 시청하는건데 p2p로 연결을 해야되나? ⇒ 안그래도 된다. http나 websocket방식으로 해서 받는 방식으로 해도 된다.

---

가설 1: WebRTC 기반 room 구조

• 방(room) 개념을 만들어서 그 안에서 P2P 방식으로 host와 client의 연결을 관리한다
• 방에 host와 client의 정보가 담겨져 있고, 실시간으로 데이터를 주고 받는다

장점

• 스트리밍 서비스에 적합하다. P2P 방식으로 연결되기 때문에 delay가 거의 없다
• 이미 잘 구현해 놓은 라이브러리가 존재한다. mediasoup

단점

• 서버에서 모든 연결을 관리하기 때문에 서버에 가해지는 부하가 크다

가설 2: 저장 기반 스트리밍 구조

• 방을 만들어 참가자 정보를 유지하지만, 실제 세션을 유지하지 않고 데이터만 기록한다
• 스트리밍 데이터는 미디어 데이터로 변환 후 Object Storage, CDN에 저장한다.
• 사용자가 요청하면 CDN 혹은 Object Stroage에서 데이터를 가져와서 제공한다.

장점

• 서버에 가는 부하가 줄어든다
• 영상을 장기 보관 혹은 관리에 더 유리하다

단점

• webRTC에 비해서 delay가 훨씬 크다
• 기존 webRTC와 비교했을 때 구현하는 방식이 다르기 때문에 추가 학습이 필요하다