ALPACA 관제 프로젝트 구조

01무엇이고, 어떤 일을 하나

• 센서의 캡처와 전송 작업을 큐로 분리한다.
• 길이와 타입을 가진 프레임으로 여러 기록을 전달한다.
• 중앙 이벤트에서 원본 패킷·경보로 되돌아갈 참조를 유지한다.

02어떤 순서로 동작하나

1. 패킷 수집

   libpcap에서 번호·timestamp·raw bytes를 얻어 Packet Queue에 넣는다. 항목 수 한도는 바이트 한도와 다르다.

2. 배치 구성

   송신기가 개수·바이트·최대 대기시간 조건으로 배치를 모은다.

3. 프레임 직렬화

   !4sBBI 공통 헤더에 magic·version·type·payload 바이트 길이를 쓰고 type2의 count와 레코드들을 연결한다.

4. TCP에서 재구성

   수신기는 10바이트 헤더를 모아 검사한 뒤 지정된 payload를 정확히 읽는다. 한 recv가 한 프레임이라는 전제는 사용하지 않는다.

5. 내부 경계 검증

   Count·각 raw_length·남은 바이트·전체 상한을 검사한 뒤 저장 큐에 전달한다.

6. 확인·재전송 관리

   Send 성공과 DB commit을 구분하고 센서·세션·레코드 키로 중복을 다룬다. 재전송만으로 exactly-once가 보장되지는 않는다.

03먼저 알아둘 용어와 구성요소

PKLP

이 프로젝트에서 메시지 경계를 표현하는 자체 프레임 형식.

Queue

생성 속도와 전송 속도를 분리하는 대기 구조.

Frame length

TCP 바이트 스트림에서 한 메시지를 완성하는 길이 정보.

Offset

로그 파일의 읽기 위치 또는 버퍼에서 파싱한 위치를 나타내는 값.

TCP stream

송신 바이트 순서를 제공하지만 응용 메시지 경계를 보존하지 않는 전달 방식.

Length prefix

메시지 앞에 길이를 기록해 수신자가 경계를 재구성하는 표현.

Sequence

배치 또는 메시지의 순서를 식별하는 값.

04예제로 따라가기

• 레코드 조건: 타입 2 배치에 raw 길이가 60바이트와 100바이트인 패킷 두 개가 있다고 가정한다. 실제 통신을 생성하지 않는 포맷 계산이다.
• 레코드 길이: 첫 레코드는 20+60=80바이트, 두 번째는 20+100=120바이트다. 고정부가 각 패킷마다 반복된다.
• Payload 길이: 개수 필드 4바이트를 더하면 payload는 4+80+120=204바이트다. 헤더의 payload 길이 필드는 이 값을 나타낸다.
• 전체 프레임: 10바이트 공통 헤더를 더하면 총 214바이트다. TCP 분할 때문에 실제 recv 횟수나 세그먼트 수는 달라질 수 있다.
• 불일치 입력: count=3인데 payload가 두 레코드에서 끝나면 정상 완료로 넘기지 않는다. 미완성·잘못된 선언을 구분하여 연결·레코드 처리 정책을 적용한다.

05혼동하기 쉬운 점과 확인 기준

• 단계별 개수: 센서 생성·큐 입력·프레임 송신·중앙 파싱·적재 개수를 같은 ID 범위로 비교한다. 서로 다른 시점의 총계는 직접 같지 않을 수 있다.
• 문자열 길이: 타입 1·3의 길이가 UTF-8 바이트 기준인지 확인한다. 한글 한 글자가 1바이트라는 가정은 이후 필드 경계를 깨뜨린다.
• 미완성 꼬리: 연결 종료 때 헤더·payload 중 어디까지 받았는지 기록한다. TCP 정상 연결 수와 정상 프레임 수를 동일시하지 않는다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.