.... 15일차 이지만... 첫날 인것처럼 일지를 써보겠다....
우리 팀은 화상면접 서비스 런칭하기로 하였다. 여기에서 메인으로 나올 기능은 webRTC이었다. 솔직히 조금 자신은 있었다. 왜냐 클론코딩을 했을때 socket.io를 사용했기 때문이죠 후후후 ...
하지만 현실은 항상 넉넉하지 않은법... 우리는 곧 webRTC라는 거대한 벽에 막혀서 일주일 가량을 그 곳에 시간을 보내며 허우적 거렸다...
니꼬쌤의 동영상을 보며 공부했지만 머릿속에 정말 들어오지를 않았다. 아니 무슨 핑퐁이 뭐이리 많냐구 ㅠㅠㅠㅠ
그렇다고해서 자료가 엄청 많은것도 아니고 참... 너무 어렵더라 너란 아이.... 질린다 이제....
계속 몸무림을 쳐가면서 내가 찾은 자료중 그나마 이해를 조금할 수 있는 자료의 그림을 찾았다.
우선 위 자료는 P2P 기준으로 작성한 그림이다.
아 ! 우선 이걸 설명 안했구나 !! webRTC는 서버를 거치지 않고 클라이언트끼리 통신하는것을 말한다. 진짜 혁명적이지 않나?!
(사실 거치기는 하는데... 뭐... 우리만의 비밀...)
(webRTC 진짜 누가 만든건지... 너무 짱인듯... 부들부들)
webRTC
설명하자면 pear 1,2 이 STUN 서버한테 클라이언트 (자신의 public IP)를 확인하기 위해 STUN 서버로 요청을 보내고 서버로 부터 자신의 public IP를 받는 것이다. 그래서 클라이언트는 자신이 받은 public IP를 이용해서 시그널링을 할때 받은 정보를 이용하게된다.
다만 이 STUN으로 모든걸 해결할 수 없다. 바로 두 클라이언트가 같은 네트워크에 존재하고 있을때는 이것으로는 해결이 되지 않는다.
이제 순서를 쭉 나열하면 sdp(Session Description Protocol) 형식을 따르는 blob인 offer, answer를 주고 받는다.
1) RTCPeerConnection.createOffer를 호출해 Offer SDP를 생성
2) Signaling Server를 통해 Offer SDP를 송신
3) 상대편에서 Offer SDP를 받아 RTCPeerConnection.setRemoteDescription 수행
4) RTCPeerConnection.createAnswer호출 Answer SDP를 생성 후 Signaling Server에 전달
5) RTCPeerConnection.setRemoteDescription를 호출해 Answer SDP를 등록
6) 여기까지 완료되면 p2p연결이 성공적으로 완료되었다고 판단
요런 느낌으로 진행된다고 보면 된다. 하지만 아직까지는 엄청 많이 이해했다고 하기는 어려워서 ... 좀 더 많이 공부해봐야할거같다.
그리고 webRTC는 클라이언트끼리의 소통이기때문에 사실 backEnd 에서 해줘야할것은 많이 없다. 함수들이 다 frontEnd 에서 하기때문에... 하지만 그래도 나는 그 함수들을 좀 공부해볼 생각이다.
자 ... 여기까지가 대략적으로 내가 이해한 범주 안에서 설명할 수 있는 webRTC의 최대치이다... 후후... 머리 아프쥬..?
그래서 이 webRTC 부분은 우선 프론트 쪽에서 만들어야하기때문에 내가 당장에 할 수 있는게 없어서 ! 우선 CRUD API를 만들기로 하였다.
이름하야 면접예약 CRUD를 만들어야한다 와~~~ 짝짝짝 !
역시 CRUD는 행복이ㅈㅣ.... 라고 생각했지만.... 음 .... 면접편은 내일 일지에 또 작성하도록 하겠다... 지금 어느정도 API를 작성하긴 했지만 굉장히 코드가 길어질거기 때문에.... 그럼 우리 내일 만나요 .... 제발 ....
webRTC 진짜 넘흐 어렵다 .... 쥬륵
