1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
# 020 — 작성한 저장·응답 관계에서 실행 경로 준비
> 후속 [021](021-field-connections.md)에서 이름 기반 필드와 입력 값에 의존하는 범위를 추가했다.
> 이 문서의 구조체 크기와 상수 구간 한정 설명은 당시 구현의 기록이다.
2026-09-23. **이제 C 서버를 고치지 않고 저장할 구간과 응답할 구간을 `.pure`에 작성할 수
있다.** 시작 때 별칭과 중첩 구간을 최종 접근 범위로 합치고, 요청 처리에는 그 결과만 쓴다.
응답 소비자가 필요한 범위가 실제 파일 매핑까지 전달된다. 작성 관계가 실행 경로에 영향을
주는 첫 제한된 구현이다. 문법을 추가한 사실이나 새 알고리즘의 성능 우위를 성과로 삼지 않는다.
기존 작업물 전체를 저장·복원하는 [storage.pure](../../prototypes/connections/examples/storage.pure)를
기본 사용 예로 유지했다. [excerpt.pure](../../prototypes/connections/examples/excerpt.pure)를 고치면
같은 서버 실행 파일로 다른 구간을 응답할 수 있다. 실행 중 교체는 지원하지 않으므로 재시작이
필요하다. [실행·작성 방법](../../prototypes/connections/README.md).
## 작성 관계가 바꾼 것
```text
on get {
let object = store.read(request.key);
let window = range(object.body, 16, 64);
let excerpt = range(window, 16, 16);
reply(object, excerpt);
}
```
이 정의의 준비 결과는 다음과 같다.
- 파일 길이는 **80 B 이상**이어야 한다. 최종 응답에 들어가지 않는 부모 구간의 조건도 남는다.
- 응답 범위는 **오프셋 32부터 16 B**다. 파일 헤더를 확인한 뒤 이 범위만 매핑한다.
- 별칭·중간 구간을 위한 실행 노드나 본문 배열은 만들지 않는다. 매핑·최종 주소 준비·검사는 남는다.
- 파일의 존재·형식 오류와 응답의 revision을 유지한다. 범위 검사와 매핑은 같은 파일 버전에서 수행한다.
실제 1 MiB 객체에서 이 16 B를 응답했고 논리적 본문 접수 예산도 16 B로 처리했다.
이는 요구 범위가 저장 경로까지 전달됐다는 정확성 확인이다. 실제 매핑 페이지·RSS·디스크
사용량이 16 B라는 뜻이 아니며, 전체 응답과의 처리량 비교도 아니다.
쓰기에서도 입력의 일부를 저장하고 같은 부분을 응답할 수 있다. 그 경우 수신 버퍼를
저장 호출 직후 해제하지 않고 전송 완료·중단까지 유지한다. 요청에서 일부만 참조하더라도
원본 수신 할당 전체를 보유하는 비용은 남는다. 사용자는 복사나 해제 콜백을 작성하지 않는다.
## 제거하면 안 되는 작업
최종 `[32,48)`이 유효해도 부모 `[16,80)`이 유효하지 않으면 실패해야 한다. 사용되지 않는
`range`도 길이 부족을 관찰할 수 있으므로 검사까지 제거하지 않는다. 현재 모든 범위 오류는
같은 실패 종류이며 같은 원본에 대한 최소 길이 조건을 최댓값 하나로 합칠 수 있다.
구간별 오류 위치·다른 효과·서로 다른 버전을 관찰하는 연산이 생기면 이 규칙을 그대로
확장할 수 없다.
쓰기의 뷰 정의는 저장 효과보다 앞에 둔다. 실패할 입력으로 저장한 뒤 나중에 오류를
발견하는 것을 막는다. 본문 없는 응답도 저장 효과나 읽기 대상의 존재 검사를 없애지 않는다.
공개 후 영속화 불확실 결과는 기존 `durability_unknown`으로 전달하며 성공으로 바꾸지 않는다.
현재 서버는 준비된 범위·조건을 사용해 직접 저장 API와 전송기를 호출한다. 요청마다
노드 목록을 순회하거나 소스를 다시 해석하지 않는다. `--check-program`의
`runtime_view_steps: 0`은 이 구현 구조의 설명값이며 CPU 명령 수나 실행 중 측정값이 아니다.
일반/검사 빌드에서 준비된 프로그램 구조체는 112 B다. 이는 전체 서버·컴파일러 메모리가 아니다.
## 검증과 범위
Linux AArch64에서 일반 빌드와 ASan·UBSan 빌드가 모두 통과했다.
- 기존 실제 TCP 저장·Workbench 복원 등 16개 시나리오와 새 작성·범위·효과·수명 시나리오
6개를 합쳐 22개. SQL 의존성은 다시 도입하지 않았다.
- 중간 부모의 범위 오류, 쓰지 않는 뷰의 범위 오류, 본문 없는 읽기의 파일 오류를 보존한다.
- 입력을 돌려주는 응답의 부분 전송·완료·중단과 원본 회수, 중단 후 저장 내용 유지.
- 작성 오류는 저장소 생성·네트워크 접수 전에 거절한다. 파싱 실패는 준비 결과를 변경하지 않는다.
- 순서대로 범위를 검사하는 참조 계산과 준비된 범위의 결과·실패를 경계 조건에서 대조했다.
이 단위 검사는 실행 속도 비교가 아니다.
[원자료·소스 사본](../../prototypes/connections/results/2026-09-23-prepared-connections/README.md),
[준비 구현](../../prototypes/connections/program.c),
[실제 실행 경로](../../prototypes/connections/server.c),
[작성 계약](../design/004-prepared-connections.md).
지금은 등록된 읽기·쓰기·응답과 상수 바이트 범위에 한정한다. 요청당 효과는 하나이며,
숫자/화면 DSL과도 파서를 통합하지 않았다. 동적 범위·조건 분기·피드백·임의 연산·다중 소비자·
여러 외부 효과·비동기 저장을 지원하는 일반 실행 모델은 아직 아니다. macOS 실행, 실제
전원 장애, 전체 지연·RAM 우위도 검증하지 않았다.
## 다음 결정
현재는 작성자가 바이트 위치를 알아야 한다. 이 부담을 제품의 정상적인 사용성으로 굳히면
안 된다. 다음에는 **실제 데이터의 필드·연산·소비 관계를 표현하고, 그 관계에서 배치와
접근을 정하는 것**을 다룬다. SQL·범용 객체를 먼저 정하지 않고 실제 앱 데이터에서 필요한
조회·갱신과 외부 형식의 변환 지점을 찾는다. 이번 상수 구간 데모의 크기나 벤치마크 행렬은
늘리지 않는다. 시간 진행과 효과 재실행 의미가 필요한 피드백은 별도 계약 없이 추가하지 않는다.
|
