현재 테스트 중입니다: 완료되면 GitHub 코드를 오픈할 예정입니다.

A · 획득됨

구조refresh

획득 요청(A)에 대한 성공 응답입니다. token은 획득마다 커지는 펜싱 토큰(u64, 빅엔디안)이고, owner는 요청에 실었던 값을 그대로 되돌려 준 것입니다 — 어느 획득 시도의 응답인지 정확히 특정하기 위한 상관자입니다(응답 매칭 규칙).

op 뒤에 16바이트 고정 헤더가 붙습니다. 이 16바이트는 이진 값이라 0x0A(\n)를 포함할 수 있으므로, 클라이언트는 반드시 개수 기준으로 먼저 읽은 뒤 개행을 찾아야 합니다.

바이트 표기: op는 ASCII 문자, token·owner는 바이너리(u64, 빅엔디안), key는 UTF-8 텍스트(가변, 구조에서 N)입니다. 마지막 \n0A.

흐름

클라이언트
서버
A · 획득 (key · owner)
비어 있는 키 → 즉시 발급
A · 획득됨 (token = n · owner 에코)
점유 중 → 대기열에서 앞사람의 반납·만료를 대기
차례가 오면 A · 획득됨 (token = n+1)
요청응답

발급 경로는 두 가지지만 프레임은 같습니다 — 즉시 발급이든 대기 후 발급이든, 도착한 A에는 그 시점의 새 펜싱 토큰이 담기며 토큰은 획득마다 커집니다. 대기 중에 wait를 넘기면 이 응답 대신 타임아웃 T가 옵니다.

공식 클라이언트는 요청 바이트 쓰기를 시작하기 직전의 monotonic 시각부터 lease를 보수적으로 계산합니다. 응답을 받았을 때 caller가 지정한 최소 작업 시간(critical work + 예상 pause + DB commit/rollback)이 남지 않았다면 Ticket을 넘기지 않고, 이미 알게 된 exact token으로 반납한 뒤 명시적인 InsufficientLease 계열 오류를 반환합니다. 이 계산은 fencing을 대신하지 않습니다.