4상 백엔드 브리지 — 기존 브라우저/메신저에 적용 가능 확인 (E2E 실증)
질문과 답
"크라우니서비스(백엔드) 안에서 기존 브라우저/통신/메신저에도 적용 가능한가?" →
가능. 실증 완료.
기존 클라이언트는 UDP 원시 소켓을 못 쓰지만,
4상 구간을 백엔드(서비스↔서비스)가 대신 지면
양 끝 클라이언트는 아무 것도 바꾸지 않는다.
[기존 브라우저]--HTTP POST-->[:9661 4상브리지]--4상 3사본 UDP-->[:9660 4상수신루프]--릴레이-->[msg.crowny.org 기존 메신저]
(무변경) 한선씨 FEC 복원 (무변경, 폰/웹 그대로)
E2E 실증 (2026-07-03)
- curl(기존 브라우저 대역) POST →
{"ok":true,"trits":534,"copies":3}
- 4상 구간: 3사본 UDP → 다수결 복원 "소거 0, 무결"
- msg.crowny.org 수리 색인 284·285 — 폰 msg.crowny.org/chat에서 [4상통신] 프리픽스로 표시
- 긴급비콘도 동일 경로 통과 (SOS일반 37.57N 126.98E 인원3, 15바이트 프레임)
산출물
apps/4상통신/4상브리지.한선 (+RPN) — HTTP→4상UDP 입구 :9661 (포트 레지스트리 등록)apps/4상통신/4상수신루프.한선 (+RPN) — 상주 수신→로그+메신저 릴레이(게이트 /tmp/4상메신저푸시.txt="1")/tmp/4상푸시.sh — 크라우니메신저연동.sh 경유 정적 헬퍼 (따옴표 함정 회피)
적용 범위 정리 (기존 클라이언트 관점)
| 구간 | 적용 방법 | 상태 |
|---|
| 크라우니 서비스↔서비스 (백엔드) | 4상 UDP 직접 | 즉시 가능 — 오늘 실증 |
| 기존 브라우저 → 백엔드 | HTTP 브리지(:9661)가 4상 구간 대행 | 즉시 가능 — 오늘 실증 |
| 백엔드 → 기존 메신저 | 수신루프가 msg API 릴레이 | 즉시 가능 — 오늘 실증 |
| 브라우저 최종 구간(라스트마일)까지 4상 | WebRTC DataChannel 비신뢰모드 / QUIC 데이터그램에 4상 FEC 탑재 | 옴(다음 단계 — 표준 브라우저 API로 가능) |
핵심: "기존 브라우저 적용"의 정답은 클라이언트 개조가 아니라
가장 손실이 심한 구간(백엔드 무선/원거리 링크)을 4상으로 바꾸는 것. 라스트마일은 보통 근거리라 기존 TCP로 충분하고, 원거리·불안정 구간이 백엔드에 있을 때 이 브리지 구조가 그대로 먹힌다.
발견 함정 (학습 반영)
TCP읽기(소켓) 1인자 컴파일은 되지만 빈 문자열 — 2인자(소켓, 크기) 필수- HTTP 본문 추출 = 마지막 개행 뒤 (\r 리터럴 불가 — 기존 가드레일 재확인)
잔여
- 수신루프/브리지 launchd 상주화(현재 데모 기동·종료만) + 메신저 푸시 게이트 운영값 결정
- 실기기 WiFi 가장자리 실측(맥 2대) — 소거율-거리 실곡선
- 브라우저 라스트마일: WebRTC 비신뢰 DataChannel에 4상 프레임 탑재 프로토타입