descord

플로우

Signal 서버와의 모든 통신은 websocket을 통해 이루어 집니다.

유저 상태 관리

• 모든 유저의 접속 상태를 알 수 있음.
  1. 초기에 로그인을 하면 모든 유저의 목록 & 상태를 불러옴
  2. 누군가 로그인을 하면 signal 서버에서 연결된 모든 유저에서 someone_login을 보내 user 목록 & 상태을 로드하도록 함

webRTC Connection 생성

여기서 서버는 signalServer를 뜻함

1. peer1(request)가 로그인(signal 서버와 socket.io 커넥션 생성
2. peer2(accept)가 로그인(signal 서버와 socket.io 커넥션 생성
3. request가 서버에 "나 채팅 쟤(accept)랑 통신할래"
4. 서버가 request에게 "그럼 webRTC connection 부터 만들어"
   1. 서버가 유저 리스트(연결하려는 peer들은 busy로 바꿔서)를 전송
5. request는 webRTC connection을 만들기 시작
   1. track을 받아와서 connection에 추가
   2. DataChannel을 생성
   3. 서버에게 offer 생성 후 전송
6. 서버는 accept에게 offer 전달
7. accept는 연결하기 위한 과정 시작
   1. offer를 받으면 수락, 취소 모달을 생성
   2. 수락을 누르면 accept가 webRTC Connection을 만듬
   3. answer 객체를 만들어서 signalServer에 answer 전송
8. 서버가 request에게 answer 객체를 보냄
9. accepter는 answer 객체로 RTCSessionDescription 생성
   1. ready 메시지를 서버에 보냄(나 준비 됬다.)
10. 이 과정이 끝나면 signalServer는 두 peer에게 ready 메시지를 보내 모달 창을 전부 끄고 통신을 시작한다.

• answer 객체는 localDescription과 request의 offer로 만들어진 remoteDescription를 가지고 만들어진 것
  • RTCSessionDescription을 만들기 위해 위의 2가지 객체가 필요하다.
  • new RTCSessionDescription(data.answer)

프로젝트 회고록

일단 너무 재밌었다. 이렇게 프레임워크를 플로우로 경험해 볼 수 있다는 것 자체가 굉장히 신선한 경험 이었다. 모든 프레임워크는 사용자 중심으로 만들어서 너무 쉽게 사용할 수 있는 반면 내부에서 어떤 과정을 거치는 지 알 수가 없었다. 하지만 이번 webRTC는 신기술이라 그런지 코드 한줄로 모든 걸 할 수 있지는 않았다. 그래서 너무 재밌었다.

아쉬웠던점

사실 이 프로젝트는 혼자 공부하기 위해서 했던 프로젝트라 딱히 아쉽거나 한 점을 찾아보기 힘들다.(내 맘대로 했으니까...) 하지만 혼자 하는 프로젝트라도 앞으로의 발전을 위해서 꼽자면

1. webRTC는 Connection을 말하는 것이다. 내부에 어떤 프로토콜을 이용해서 미디어를 전송하는지 좀 더 자세하게 알아봤어야 했다.
   • 구현에 만족하지 말고 내부 프로토콜, 원리를 먼저 더 자세하게 알아봐야 한다.
2. 왜 webRTC인가에 대해 더 구체적이어야 한다.
   • 다른 프로토콜에 대해서도 알아보고 왜 webRTC가 주목을 받는지 어떠한 장점이 있는 지를 먼저 알아본 다음 구현해야 한다.
3. 통찰력이 모자람
   • webRTC라는 기술을 접했을 때 내부의 동작에 관심이 가거나 미디어를 전송하는 방식 등에 관심이 가려면 새로운 기술을 접하고 구현했을 때 느끼는 감정을 경험하고 그를 통찰력으로 가져야 한다.
   • 앞으로도 접하지 못했던 기술을 접했을 때는 위의 장점과 단점, 한계, 그리고 내부 프로토콜과 원리를 먼저 알아보고 구현에 집중하는 습관을 가져야겠다.