[Mediasoup] 1:N 연결 구현

테스트를 해보고 놀랐던 점은, 내부적으로 동작하는 코드가 효율적인 것 같다는 생각이다. 노트북 CPU 가속을 키지 않은 상태인데도 생각보다 CPU를 많이 사용하지 않는다. 직접 만든 SFU의 경우 서버에서 사용하는 양만 꽤 나갔던 걸로 기억하는데... ㅎㅎ

 

소스를 내가 작성한 것은 아니고, 유튜브 Amir Eshaq라는 분이 작성하신 소스가 있어서 보면서 학습했다. 기존에 작성했던 SFU 서버의 동작 방식과 크게 다르지는 않다. 다만 Mediasoup의 처리 순서를 따라가다보니 소스코드가 더 많은 것이 사실이다. 

 

코드 내용을 뜯어서 분석했으나 그대로 정리하고 올려도 직접 뜯어보지 않으면 이해하기 어려울 것이다. 그래서 약간의 설명만 남겨두고 마무리하려고 한다. 

---

클라쪽에서는 consumerTransports로 자신이 받아야 하는 recvPeer 정보를 관리한다.

audioProducer, videoProducer, producerTransport 정보를 가지고 sendPeer를 관리한다. 

 

서버는 rooms 정보로 특정 룸에 대한 router와 peers(socket id) 정보를 갖는다. (어떤 방에 어떤 소켓이 연결되어 있는지)

 

peers 정보는 각 소켓에 관련된 정보를 가지고 있는데, socketId: {socket, roomName, transports(id), consumers(id), producers(id) }의 형태로 가지고 있다. (어떤 방에 연결되어 있고 transports 정보는 어떤지)

 

transports 정보는 consumer와 producer 상관없이 정보를 추가하는 개념인데 consumer 여부값을 가진다. 

(어떤 소켓에 대한 transport이며 어떤 방에 소속되어 있고, consumer 여부를 저장한다)

 

producers 정보는 socketId, producer, roomName을 묶은 형태이다.

consumers 정보는 socketId, consumer, roomName을 묶은 형태이다.

 

처리를 보면 알겠지만, producer나 consumer를 추가할 때 producers, consumers에도 추가하지만 그 이전에 transports 정보에도 추가된다. (transports 쪽에서는 consumer와 producer를 같이 가지고 있는 개념이다.)

 

또한 peers에 있는 각 소켓에 대한 transports, producers, consumers 쪽도 같이 갱신해준다. 

 

처리하는 흐름을 보면, 처음 들어가서 SendPeer를 만들고 RecvPeer를 만들며, 주변 클라에게 RecvPeer를 만들라는 요청을 보내는 방식이다. 

 

Mediasoup 아키텍처 이미지를 하나씩 보면서 흐름을 따라간다면 충분히 이해가 될 것이라 생각한다. 

 

소스 코드

https://github.com/Yumin2019/Mediasoup-Implement/tree/mediasoup-one-to-many

 

참고 자료

https://www.youtube.com/watch?v=oCzq82xVnkU&t=483s&ab_channel=AmirEshaq