Never give up

이번에는 하드웨어의 냉혹한 현실에 대해 다루고자 합니다 화면도 없고 리소스가 제한된 기기에서 고화질 카메라 피드를 끊김 없이 뽑아내려면 하드웨어 프레임을 캡처하고 극도로 제한된 CPU 바운드 내에서 압축하여 실시간으로 WebRTC 미디어 파이프라인에 밀어 넣어야 합니다 만약 인코딩 설정이 아주 조금이라도 어긋나면 기기의 CPU 점유율은 순식간에 100%를 찍어버리고 프레임 드랍, 발열 스로틀링, 그리고 커넥션 타임아웃등이 발생합니다 이 문제를 해결하기 위해 FFmpeg Child Processes, 플랫폼 독립적인 하드웨어 드라이버 추상화 그리고 초저지연 UDP 루프백을 이용해 오버헤드가 거의 없는 비디오 파이프라인을 구축한 과정을 공유해 보겠습니다 크로스 플랫폼 제약: 하드웨어 디바이스 노드의 추상화로..

일반적인 웹 브라우저 간(Web-to-Web)의 WebRTC 애플리케이션이라면 브라우저의 네이티브 런타임에서는 관대하게 작동합니다 패킷 순서가 조금 뒤바뀌어 오더라도 자체적으로 버퍼링을 하거나 암호화 핸드셰이크 과정에서 일어나는 일시적인 상태 미스매치를 알아서 복구해 주죠 하지만 이 피어 연결을 브라우저 밖으로 꺼내서 에이전트에 올리고 비동기 메시지 브로커와 동기화하는 순간 그 자비로움(?)은 눈 씻고 찾아볼 수 없습니다(Node.js 미디어 런타임은 자비가 없습니다) ICE Candidate나 SDP Offer가 단 1밀리초라도 순서가 뒤바뀌어 도착하면 엔진은 기다려주지 않고 즉시 invalid state 예외를 뿜으며 미디어 세션을 통째로 날려버립니다 이 무자비한 비동기 시그널링의 포화 속에서 살아남..

지난 포스팅에서 로컬 기기 페어링 지옥을 다뤘는데 이번에는 패킷을 안전하게 주고받기 위한 시그널링 서버의 구성에 대해 짚고 넘어가보자 합니다 WebRTC를 구현할 때 브라우저와 기기 간에 SDP나 ICE Candidate 같은 메타데이터를 교환하는 시그널링은 필수죠 하지만 클라우드 환경에서 이를 안정적으로 설계하는 것은 완전히 다른 문제입니다 Reverse Tunneling: 공유기 설정 없이 방화벽 우회하기프로토콜을 고민하기 전에 가장 먼저 마주한 제약은 바로 네트워크 접근성이었습니다 전통적인 방식대로 원격 기기에 접속하려면 고정 IP를 쓰거나 방화벽 인바운드 규칙을 바꾸고 포트 포워딩을 설정해줘야 됩니다 하지만 일반 유저에게 이런 복잡한 설정을 요구하는 순간 유저들은 떨어져 나가죠(실제 많은 유저가 ..

최근 클라우드 애플리케이션과 상호작용해야 하는 로컬 IoT나 미디어 서버를 배포할 일이 있었는데 개발 과정에서 가장 큰 복병을 만났습니다. 바로 기기 검색과 페어링(Pairing) 문제입니다 로컬 네트워크 공유기에서 포트 포워딩(Port Forwarding)을 따로 설정하지 않으면 클라우드 서버, 클라이언트는 로컬에 있는 기기에 직접 접근할 수가 없습니다 하지만 포트 포워딩에 의존하게 되면 여러 가지 골치 아픈 문제들이 생깁니다유저가 공유기 접근 권한이 없을 때권한이 있다고 해도, 로컬 포트를 외부 인터넷에 그대로 노출할 때 발생하는 보안 취약점게다가 비전문가인 일반 유저에게 로컬 IP 주소를 직접 찾아서 입력하라고 할 때 저급한 UX이런 네트워크 설정 지옥을 피하기 위해, 여러 가지 대안 페어링 전략들..