요약

  • Christopher Welles와 Walter Milliken이 1984년 7월에 제안한 RFC 909는 원격 호스트가 패킷 교환 노드나 게이트웨이 같은 표적을 적재하고, 상태를 꺼내고, 메모리를 읽고 쓰며 디버깅하도록 했다. 저자들은 중단점에서 표적을 세워 두고 네트워크 너머의 다음 명령을 기다리면 실시간 업무 요구에 응하지 못한다고 지적했다.
  • 설계는 작은 적재기, 기본 디버거, 완전한 디버거의 누적된 세 단계를 정의했다. 최고 단계는 조건부 명령을 표적 장비에 미리 설치하고 사건이 일어났을 때 현장에서 실행할 수 있었다. 네트워크 왕복에 덜 의존하는 대신 관찰 대상이 그 명령과 상태의 비용을 떠안는다.

관찰 장비가 새 장애를 만들 때

중단점은 개발자에게 반가운 도구다. 프로그램을 특정 명령에서 정지시키고 값을 살펴본 뒤 다음 행동을 고른다. RFC 909가 다룬 표적은 혼자 실험실에 놓인 컴퓨터만이 아니었다. 패킷 교환 노드, PAD, 게이트웨이처럼 다른 사람의 통신을 계속 처리해야 하는 장비가 포함됐다. 저자들은 원격 호스트에서 중단점 명령이 도착할 때까지 표적을 세우는 방식은 그 실시간 업무에 제한적이라고 명시했다. 고장 난 네트워크를 진단하는 과정이 통신을 더 멈출 수 있었다.

Loader Debugger Protocol, 곧 LDP는 응용 계층의 명령 체계였다. 호스트가 세션을 주도하고 표적이 응답한다. 프로그램 적재와 상태 추출, 메모리 읽기·쓰기, 실행 제어, 예외 보고가 포함됐다. 명세에는 40개가 넘는 명령이 있고 프로토콜, 데이터 전송, 관리, 제어, 중단점의 범주로 나뉜다. 원격 기술자가 얻는 통제력이 큰 만큼, 표적 장비가 그 통제를 수행하는 데 쓰는 자원도 보아야 했다.

그래서 문서는 모든 표적에 전체 디버거를 요구하지 않았다. 부트 적재기는 코드 공간이 좁을 수 있다. LOADER_DUMPER는 적재와 추출에 필요한 읽기, 쓰기, 이동, 시작, 예외 처리를 담는다. BASIC_DEBUGGER는 제어 기능과 일반 중단점을 더한다. FULL_DEBUGGER는 유한상태기계 중단점 명령을 넣고 감시점은 선택 사항으로 둔다. 세 단계는 누적된다. 연결을 연 뒤 호스트가 HELLO를 보내면 표적의 HELLO_REPLY는 버전, 구현 단계, 장비 종류, 주소 형식을 알려 준다. 기술자는 상대가 지원하는 범위를 확인하고 명령을 보낼 수 있다.

명령을 사건보다 먼저 현장에 둔다

일반 중단점은 표적 객체를 정지시키고 상태를 호스트에 보고한다. 호스트가 다음 결정을 내리는 동안 멈춤은 계속된다. 완전한 디버거의 유한상태기계 중단점은 순서를 바꾼다. 호스트가 미리 조건부 명령 목록을 표적에 보낸다. 감시할 주소가 실행되면 장비 안의 상태 변수가 어떤 목록을 실행할지 고른다. 카운터와 포인터도 조건과 동작에 쓰인다. 사건의 순간에 필요한 판단을 사건이 생긴 기계 안에서 처리하는 것이다.

이 방식에도 비용이 있다. 명령 목록과 상태는 메모리를 차지하고, 조건 평가에는 처리 시간이 든다. RFC 909는 중단점 수와 상태, 조건, 명령 목록 크기에 구현상 한계가 있을 수 있다고 밝혔다. 어떤 명령은 여전히 객체를 멈추거나 바꿀 수 있다. 핵심은 모든 디버깅을 무중단으로 만든다는 약속이 아니다. 원격 왕복을 기다리는 시간을 줄이고, 실시간 사건의 판단을 표적에 미리 맡기는 것이다.

각 중단점과 감시점은 특정 디버거 연결 하나와 주소 하나에 묶였다. 여러 사람이 같은 표적을 조사할 수 있도록 하려면 전송 계층과 표적이 여러 연결을 지원해야 했다. 장비는 어떤 세션이 어떤 규칙과 상태를 갖는지 구분해야 한다. 조사자가 늘어도 장비의 메모리와 처리 능력이 함께 늘지는 않는다. 디버깅 자원을 누구에게 얼마나 내줄지 역시 운영 문제였다.

죽은 호스트가 마지막 자리를 차지한다

세션은 전송 연결을 열고 HELLO와 HELLO_REPLY를 주고받으며 시작한다. 호스트가 연결을 닫으면 표적은 관련 자원을 풀어야 한다. 그런데 호스트가 중간에 죽으면 어떨까. 한 연결만 받는 표적이 반쯤 죽은 세션을 감지하지 못하면 다음 기술자는 접근할 수 없다. RFC 909는 죽은 연결을 알아내거나 새 연결이 비활성 연결을 밀어내도록 하는 방법을 제안했다. 후자의 방법도 기존 연결 중에 새 요청을 들을 별도 통로가 필요하다.

문서는 RFC 908의 RDP를 권장 전송으로 들고, TCP도 더 많은 자원이 드는 대안으로 적었다. 전송은 메시지를 믿을 수 있게 순서대로 보내고 연결을 구별해야 한다. 하나의 메시지에 여러 LDP 명령을 담을 수 있지만 각 명령은 한 메시지 안에 완전히 들어가야 한다. 패킷 전달 규칙은 중요한 밑받침이다. 중단점이 표적의 업무 시간을 얼마나 빼앗는지, 사라진 호스트의 자리를 언제 회수할지는 LDP와 운영의 판단으로 남는다.

RFC 909는 실험적인 제안이었다. 실제 장비에 얼마나 설치되었는지 보여 주는 보급 통계는 담지 않았다. 대신 지금 읽어도 날카로운 설계 질문을 남겼다. 살아 있는 네트워크 장비를 더 깊이 관찰하려고 통제력을 늘릴수록, 관찰 도구가 장비 안에서 일할 몫도 커진다. 문제의 명령을 정확히 잡았어도 게이트웨이가 그 순간 모든 이용자의 패킷을 멈춘다면 진단은 문제의 일부가 된다.

원자료