TURN ..
솔까 개발이 끝이 없어서 하기가 싫은 것이 아니겠나요. 다음 주는 릴레이 프로토콜을 넣어야 하빈다.
symantic nat 사이에 연결이 안되어서 결과적으로 turn 중계 서버를 사용해야 하여요. webrtc도 같은 기법을 사용하빈다.
stun은 코드가 단순하여서 ai생성을 하여도 되는데 turn은 과정만 조금 더 많아진 것이어서 ai생성을 하여도 될지도 모를 일이저.
RFC 5389 - Session Traversal Utilities for NAT (STUN)
만일 취미로 온라인 게임을 개발한다면 udp 프로토콜이 나을 것이어요. 앵간하게 비싼 서버를 구매하기 싫스빈다. 클라우드 서버는 부품 교체 유지비가 포함된 것이어서 앵간하게 비싸요. 트래픽 요금도 계속해서 발생하는데 애초에 서버 관리에 스트레스받기 싫은 것이저.
애초부터 대부분에 기업들은 인터넷 공유기를 사용하여서 밖에서 윈도우 원격 데스크탑 연결이 안되는데 vpn은 추가 장비를 써야 하고 포트포워딩은 공유기 설정을 건드려야 하면서 팀뷰어나 애니데스크는 유료로 예네들 릴레이 서버를 함부로 못써요. 러스트데스크가 무료이고 터널링 기능도 유사하게 구현하였는데 느리빈다. 번들로 제공되는 유료 개인 호스팅을 사용하면 빠를 것이어요.
대부분이 인터넷 공유기나 무선 데이터 통신은 stun연결이 성공하는데 turn은 상용 서비스에 사용할꺼라서 해야하빈다. 컴퓨터를 좀 쓴다는 이용자는 클라우드플레어 워프 VPN 같은 거를 사용하여서 symantic nat 상태가 되는데 양쪽 모두 워프를 켰다면 연결이 안되어서 대응하는 기능을 만들어주어야 일반적으로 좋아요. 워프 어플을 끄거나 워프 어플에 예외 어플을 등록하면 워프로 통신을 하지 않는데 애초에 워프 사용 목적이 통신 데이터를 숨기는 거여서 이케 하라고 강요하면 안댈꺼빈다.
RustDesk: 오픈 소스 원격 데스크탑 및 자체 호스팅 서버 솔루션
여담, 어설픈 스타트업 기업들이 어려운거 나오면 내가 하기는 싫고 핑계는 내고 싶으면서 계획서를 자꾸 편한대로 고쳐요. 찐 노력과 사기에 차이이지 않겠나요.
