제6장 데이터 전송

6.1 양방향 데이터 흐름

DTP는 두 방향의 데이터 전송을 지원하며, 서로 간섭하지 않는다:

방향명칭설명
Terminal → Fay데이터 수집단말에서 생성된 데이터를 Personal Data Heap에 영구 저장
Fay → Terminal데이터 주입iFay가 필터링과 판단을 거친 최소 데이터셋

두 방향은 동일한 Logical_Frame 형식과 처리 흐름을 사용하지만, 독립적인 시퀀스 번호 공간과 재전송 상태를 유지한다.

6.2 데이터 수집 흐름(Terminal → Fay)

완전한 데이터 수집 흐름은 다음 단계를 거친다:

단말 애플리케이션
  │
  ▼ 데이터 제출
DTP_Slave Engine
  │ 1. 컨텍스트 메타데이터 첨부
  │ 2. LogicalFrame 구성 (Header + Payload)
  │ 3. Payload 암호화
  │ 4. LogicalFrame 직렬화
  │
  ▼ send(binary_data)
Transport_Adapter
  │
  ▼ onReceive(binary_data)
DTP_Master Engine
  │ 1. LogicalFrame 역직렬화
  │ 2. Agreement_ID 검증
  │ 3. Payload 복호화
  │ 4. DAG 의존 검증
  │ 5. 시퀀스 번호 업데이트 + 확인 전송
  │
  ▼ 저장
Personal Data Heap

6.3 데이터 주입 흐름(Fay → Terminal)

완전한 데이터 주입 흐름은 다음 단계를 거친다:

Personal Data Heap
  │
  ▼ 데이터 조회 및 필터링
DTP_Master Engine
  │ 1. Fragment + 컨텍스트 메타데이터 구성
  │ 2. LogicalFrame 구성
  │ 3. Payload 암호화
  │ 4. LogicalFrame 직렬화
  │
  ▼ send(binary_data)
Transport_Adapter
  │
  ▼ onReceive(binary_data)
DTP_Slave Engine
  │ 1. LogicalFrame 역직렬화
  │ 2. Agreement_ID 검증
  │ 3. Payload 복호화
  │ 4. 시퀀스 번호 업데이트 + 확인 전송
  │
  ▼ 데이터 전달
단말 애플리케이션

6.4 Agreement_ID 압축 전송

전송 오버헤드를 줄이기 위해, DTP는 Agreement_ID의 압축 전송을 지원한다:

  • 연속된 Fragment가 동일 약정에 속할 때, 해당 배치의 첫 번째 Fragment 헤더에만 완전한 Agreement_ID를 포함
  • 이후 Fragment의 agreementId 필드는 null로 설정하여, 이전 것을 계승함을 표시

수신측 처리 규칙:

  1. Agreement_ID가 포함된 Fragment 수신 → 현재 컨텍스트의 Agreement_ID 업데이트
  2. Agreement_ID가 포함되지 않은 Fragment 수신 → 현재 컨텍스트에서 가장 최근에 선언된 Agreement_ID에 연결
  3. 알 수 없는 Agreement_ID를 참조하는 Fragment 수신 → 폐기하고 오류 알림 전송

예시:

Fragment 1: agreementId = "abc-123"  ← 완전한 ID
Fragment 2: agreementId = null       ← "abc-123" 계승
Fragment 3: agreementId = null       ← "abc-123" 계승
Fragment 4: agreementId = "def-456"  ← 새 약정, 완전한 ID
Fragment 5: agreementId = null       ← "def-456" 계승

6.5 시퀀스 번호 관리

단조 증가

각 Fragment는 전송 시퀀스 번호(Sequence_Number)를 포함하며, 단일 세션 내에서 단조 증가한다.

양방향 독립

데이터 수집 방향과 데이터 주입 방향은 완전히 독립적인 시퀀스 번호 공간을 유지한다:

데이터 수집 방향 (collection):  seq 1, 2, 3, 4, 5 ...
데이터 주입 방향 (injection):   seq 1, 2, 3, 4, 5 ...

한 방향의 시퀀스 번호 변화는 다른 방향에 영향을 미치지 않는다.

6.6 원본 타임스탬프 보전

DTP는 각 Fragment의 원본 타임스탬프(Origin_Timestamp)가 전체 전송 과정에서 변경되지 않도록 보장한다:

  • 데이터가 소스에서 실제 생성된 시점을 기록하며, 전송 시점이 아님
  • UTC 시간대와 밀리초 정밀도를 사용
  • 직렬화, 암호화, 전송, 복호화, 역직렬화를 거친 후에도 타임스탬프가 전송 전과 완전히 동일
  • 수신측은 원본 Origin_Timestamp를 수정하지 않고 보존

이를 통해 데이터가 지연 업로드되더라도(예: 오프라인 시나리오), iFay가 실제 타임라인을 복원할 수 있도록 보장한다.

6.7 DAG 의존 검증

수신측은 Fragment 수신 시 DAG 의존 검증을 수행한다:

  1. 순환 감지: 새 Fragment의 의존 관계가 DAG에서 순환을 형성하지 않는지 검증. 순환이 감지되면 해당 Fragment를 거부
  2. 의존 해석: 의존 대상 Fragment가 아직 도착하지 않은 경우, 현재 Fragment를 "의존 해석 대기" 상태로 표시하고 캐시
  3. 지연 해석: 피의존 Fragment가 도착하면, 이전에 캐시된 Fragment를 자동으로 해석