해설 — 채널/인스턴스 이동 중 상태 이관 누락 (C++)

난이도: 중

답변 프레임워크: 요약 → 문제 분류 → 원인 → 수정안 → 더 나은 설계

요약

핸드오프가 네 가지로 깨진다. (A) 페이로드에 쿨다운·진행 중 시전이 빠져 이동 후 초기화된다 (쿨다운 리셋 치팅, 시전 끊김). (B) 출발 서버가 대상 ack 전에 active_.erase 하고 전송 결과를 무시 → 전송 실패 시 블랙홀, 또는 임의 순서로 중복 활성. (C) erase 가 unique_ptr 를 파괴하므로, 직후/동시에 들어온 applyUpdate 가 그 플레이어를 찾으면 못 찾아 유실되고, 만약 다른 스레드가 이미 *it->second 포인터를 들고 있었다면 UAF. (C') freeze가 없어 직렬화 이후 출발에 들어온 갱신은 대상에 반영되지 않는다. 정답 한 줄: 휘발 상태 전체를 직렬화하고, freeze→전송→대상 ack→release 순서로 핸드오프를 원자화하며, freeze 이후 갱신은 큐잉해 대상에서 재생하고, 세션 수명은 ack 이후에만 파괴한다.

변별: problem10(핸드오프+graceful shutdown 드레이닝), problem13(split-brain 동시활성 탐지/방지)과 달리 본 문제는 상태 이관 완전성 + 핸드오프 순서 + 세션 수명(UAF) 이 핵심.

---

문제점

(A) 휘발 상태 부분 직렬화 — 상태 유실 (정합/치팅) ★간판

• 분류 태그: incomplete-state-transfer.
• 증상: 페이로드가 hp/buffs 만 담고 cooldownUntilMs/castingSkillId 를 뺀다. onReceiveMigration 은 빠진 필드를 기본값으로 둬 이동 시 쿨다운 전부 리셋·시전 소멸. 채널 이동으로 궁극기 쿨다운을 초기화하는 어뷰징이 가능.
• 근본 원인: 휘발 상태 정의가 한 곳에 없어 직렬화 누락.

(B) 대상 ack 전 erase + 전송결과 무시 — 블랙홀/중복 활성 (정합) ★간판

• 분류 태그: ordering / lost-handoff.
• 증상: active_.erase(it) 를 전송 전에 하고 결과를 무시. 전송 실패면 출발·대상 모두 없음(블랙홀). 순서를 뒤집어도 대상 활성과 출발 release 사이 split-brain 창.
• 근본 원인: freeze→transfer→ack→release 원자 전이와 실패 롤백 부재.

(C) erase 가 unique_ptr 파괴 — 유실 + UAF 위험 (메모리/수명) ★C++ 핵심

• 증상: erase(it) 는 unique_ptr<PlayerState> 를 파괴해 PlayerState 객체를 즉시 해제한다. 직후 applyUpdate 는 find 실패로 갱신 유실. 더 위험한 건, 다른 워커가 이미 it->second.get()(또는 &*it->second) raw 포인터를 잡고 있었다면 erase 후 접근이 use-after-free. unordered_map 노드는 주소 안정적이지만 erase 된 노드는 예외 — 해당 값은 파괴된다.
• 근본 원인: 세션 수명이 핸드오프 완료(ack)와 분리되지 않았고, 동시 접근 보호도 없다.

(C') freeze 없는 동시 갱신 — 이관-갱신 경쟁 유실 (동시성/정합)

• 증상: 직렬화 시점 이후 출발에 들어온 갱신은 옛 상태에 적용되거나 버려져 대상에 반영 안 됨.
• 근본 원인: 직렬화~release 가 임계구역이 아니고, freeze 이후 갱신 보존 경로가 없다.

---

수정안

핵심: ① 전체 휘발 상태 직렬화, ② freeze→전송→ack→release + 실패 롤백, ③ freeze 이후 갱신 큐잉, ④ 수명은 ack 후 파괴, 동시 접근은 락(또는 단일 스레드 액터).

struct MigrationPayload {
    int64_t playerId;
    int     hp;
    std::vector<Buff> buffs;
    std::unordered_map<int, int64_t> cooldownUntilMs;   // 추가
    int     castingSkillId;                              // 추가
    std::vector<std::function<void(PlayerState&)>> pendingUpdates; // freeze 이후 갱신
};

enum class MigPhase { None, Frozen };

bool beginMigrate(int64_t playerId, const char* targetServer) {
    PlayerState* st = nullptr;
    MigrationPayload payload;
    {
        std::lock_guard<std::mutex> g(mu_);
        auto it = active_.find(playerId);
        if (it == active_.end()) return false;
        st = it->second.get();
        if (st->phase == MigPhase::Frozen) return false;
        st->phase = MigPhase::Frozen;                    // 이후 갱신은 큐로
        // freeze 와 같은 임계구역에서 스냅샷 — pendingBuffer 이동도 락 안에서
        // (동시 applyUpdate 의 push_back 과의 경쟁 차단)
        payload = MigrationPayload{ st->playerId, st->hp, st->buffs,
                                    st->cooldownUntilMs, st->castingSkillId,
                                    std::move(st->pendingBuffer) };  // 전체 직렬화 + pending 동봉
    }

    if (!sendToTargetAndAwaitAck(targetServer, payload)) {     // 대상 활성 ack 대기
        std::lock_guard<std::mutex> g(mu_);
        st->phase = MigPhase::None;                            // 실패 → 롤백(출발 유지)
        return false;
    }
    std::lock_guard<std::mutex> g(mu_);
    active_.erase(playerId);                                   // ack 후에만 파괴
    return true;
}

void applyUpdate(int64_t playerId, std::function<void(PlayerState&)> mutate) {
    std::lock_guard<std::mutex> g(mu_);
    auto it = active_.find(playerId);
    if (it == active_.end()) return;
    PlayerState& s = *it->second;
    if (s.phase == MigPhase::Frozen) { s.pendingBuffer.push_back(std::move(mutate)); return; }
    mutate(s);
}

void onReceiveMigration(MigrationPayload p) {
    auto st = std::make_unique<PlayerState>();
    st->playerId = p.playerId; st->hp = p.hp; st->buffs = std::move(p.buffs);
    st->cooldownUntilMs = std::move(p.cooldownUntilMs);
    st->castingSkillId = p.castingSkillId;
    for (auto& u : p.pendingUpdates) u(*st);                  // freeze 이후 갱신 재생
    std::lock_guard<std::mutex> g(mu_);
    active_[p.playerId] = std::move(st);
    // 이후 출발로 ack
}

(PlayerState 에 MigPhase phase = MigPhase::None; 와 std::vector<std::function<void(PlayerState&)>> pendingBuffer; 추가, 멤버에 std::mutex mu_;)

포인트

• 전체 휘발 상태 직렬화 → 쿨다운/시전 유지.
• ack 후에만 erase → 파괴 시점이 핸드오프 완료와 일치, UAF·블랙홀 제거. 실패면 롤백.
• raw 포인터 st 는 락 밖에서 멤버를 읽지만, 파괴(erase)는 ack 이후 락 안에서만 — 수명 보장. 더 보수적으로는 shared_ptr<PlayerState> 로 보유해 인플라이트 동안 살아있게 한다.
• freeze 이후 갱신은 큐잉 → 대상에서 재생(유실 없음).

---

더 나은 설계 (+트레이드오프)

1. 2단계 핸드오프(PREPARE/COMMIT) + 코디네이터 타임아웃/롤백. 트레이드오프: 지연/복잡도 ↑.
2. owner epoch/fencing 토큰: 대상 활성 시 epoch+1, 출발의 늦은 처리(옛 epoch)는 거부 → split-brain 차단(problem13 연계).
3. 세션을 shared_ptr + 단일 스레드 액터로: 인플라이트 참조가 수명을 연장, 한 액터가 한 플레이어를 처리해 락 없이 원자성. 트레이드오프: 샤딩 설계.
4. 이관 스키마 버전/체크섬: 필드 누락을 컴파일/스키마로 차단.

---

면접 포인트 (예상 질문)

1. unordered_map::erase 가 unique_ptr 를 파괴할 때, 다른 스레드가 들고 있던 raw 포인터는 왜 위험한가? unordered_map 의 "주소 안정성" 보장의 예외는?
2. "먼저 erase 후 전송" vs "먼저 전송 후 erase" 의 실패 시나리오(블랙홀 vs 중복 활성)를 각각 설명하라. ack 기반 순서가 왜 필요한가?
3. freeze 이후 갱신을 유실 없이 대상으로 넘기는 방법은? shared_ptr 가 UAF 를 어떻게 완화하는가(그리고 그 비용은)?