본문 바로가기

분류 전체보기94

C++ 프로젝트가 나뉘어 있다면, CMake로 한 번에 묶어 빌드하자 - 그리고 Sanitizer는 꼭 붙이자 들어가며 – 돌아는 가는데, 왠지 찜찜하다C++로 네트워크 프로그램을 만들다 보면 이상한 기분이 들 때가 있다. 컴파일은 문제없다. 실행도 된다. 그런데 가끔 이유 없이 뻗는다. 특히 RTSP처럼 소켓과 버퍼, 포인터를 계속 만지는 코드에서는 더 그렇다. 지금은 멀쩡해 보여도 어딘가에 지뢰가 묻혀 있을 것 같은 느낌. 그게 C++다.파일이 분리된 구조라면, CMake로 통합 빌드를 구성하는 게 맞다. 여기에 Sanitizer까지 붙이면 훨씬 든든해진다. 그냥 취향 문제가 아니다. 유지보수와 안정성의 문제다.파일이 나뉘었는데, 그냥 g++로 빌드하면 안 되나?프로젝트 구조는 이렇게 되어 있다.src/ main.cpp net.cpp rtsp_session.cppinclude/ net.hpp rtsp.. 2026. 2. 26.
RTSP 응답을 읽는다는 것 - 왜 recv() 한 번으로 끝내면 안 되는가 들어가며: 생각보다 만만하지 않다RTSP 클라이언트를 직접 구현하려고 마음먹으면 처음에는 이렇게 생각하기 쉽다. 서버가 RTSP/1.0 200 OK\r\n... 같은 문자열을 보내는데, recv() 한 번 호출해서 문자열로 파싱하면 끝나는 것 아닌가?겉으로 보면 그렇다. 응답은 텍스트이고, HTTP와 구조도 비슷하다. 그래서 자연스럽게 “한 번에 온다”는 전제를 깔고 코드를 짜게 된다. 그런데 실제로 테스트를 해보면 이상한 일이 생긴다.헤더가 중간에서 잘린다.SDP body가 반만 들어온다.어떤 경우에는 응답 두 개가 붙어서 한 번에 들어온다.그제야 깨닫게 된다. 문제는 RTSP가 아니라, TCP를 잘못 이해한 데 있었다는 것을.TCP는 메시지가 아니라 바이트 흐름이다TCP는 “메시지 단위” 프로토콜이 .. 2026. 2. 25.
RTSP 클라이언트 첫걸음: TCP 연결하고 OPTIONS 한 번 던져보기 들어가며 — 서버가 정말로 “대답하는지”부터 보자RTSP 클라이언트를 직접 만들어보겠다고 마음먹으면, 머릿속이 조금 복잡해진다.소켓, 프로토콜, 세션, RTP, 파싱… 해야 할 일이 한가득이다. 그럴수록 한 걸음 물러서서 마음을 잡는다.“일단 서버가 말은 하는지 보자.” 이 단계에서는 거창한 일을 하지 않는다. 그냥 TCP로 붙고, OPTIONS 요청 하나 보내고, 서버가 뭐라고 답하는지 원문 그대로 출력해본다.딱 여기까지. 생각보다 이 과정이 중요하다. 응답을 직접 눈으로 보면, 프로토콜이 갑자기 추상적인 개념이 아니라 살아 있는 텍스트로 느껴진다.TCP 연결 + RTSP OPTIONS 요청 + 응답 출력왜 이걸 먼저 할까?RTSP는 HTTP처럼 텍스트 기반 프로토콜이다. 하지만 포트는 보통 8554나.. 2026. 2. 21.
RTSP 클라이언트를 만들기 전에 꼭 해야 할 준비― mediamtx + FFmpeg으로 테스트 환경 먼저 만들기 들어가며 ― 왜 서버부터 준비해야 할까?RTSP 클라이언트를 직접 만들어보겠다고 마음먹으면, 보통은 이런 생각이 먼저 든다.“일단 코드부터 짜보자.” 나 역시 그랬다. 뭔가를 만들겠다고 하면 손부터 움직이는 편이라서.그런데 RTSP는 혼자서는 아무 일도 못 한다. 구조적으로 그렇다. 반드시 서버와 미디어 소스가 있어야 한다. RTSP는 데이터를 실어 나르는 프로토콜이 아니다. 영상 파일을 직접 보내는 게 아니라, “재생해라”, “멈춰라”, “이 스트림을 열어라” 같은 제어 명령을 주고받는 역할에 가깝다. 말 그대로 리모컨이다. 그래서 테스트를 하려면 최소한 이 세 가지가 필요하다.항상 떠 있는 RTSP 서버그 서버에 붙어 있는 영상 소스(H.264 등)결과를 확인할 수 있는 검증용 플레이어클라이언트를 제.. 2026. 2. 21.

티스토리툴바