요약
- RFC 3018은 원격 읽기, 쓰기, 할당, 객체 및 제어 전송 명령을 통해 128비트 분산 메모리 공간을 노출했습니다. 트랜잭션은 버퍼에 담긴 명령이 함께 실행되거나 전혀 실행되지 않기를 요구할 수 있었습니다.
- 같은 RFC는 실행 후 취소를 명시적으로 제공하지 않았으며, 제어 전송을 되돌릴 수 없을 수 있는 효과로 지목했습니다. 따라서 완전한 전송과 원자적 해제는 가역성, 보안 또는 의도한 애플리케이션 결과를 증명하지 못했습니다.
트랜잭션은 원격 기계에서 대기하고 있었습니다. 그 명령들은 완전했고, 하나의 최종 명령이 전부를 함께 해제할 수 있었으며, 또 다른 명령은 실행되기 전에 전부를 삭제할 수 있었습니다.
그것은 깔끔한 판단 경계처럼 들립니다. 해제 전에는 번들이 사라질 수 있었고, 해제 후에는 모든 명령이 하나의 원자적 행위에 속하게 되었습니다.
그런 다음, 한 명령이 제어를 원격 노드의 코드로 전송했습니다.
RFC 3018은 그 이후에 어떤 일이 벌어지는지에 대해 드물게도 솔직했습니다. 실행 후 취소를 제공하지 않았습니다. 가역이 필요하다면 가상 머신이 이를 구현해야 했는데, 트랜잭션은 제어 전송이 그 대표 예였던, 취소가 불가능할 수 있는 연산을 포함할 수 있었기 때문입니다.
이 구분이야말로 주목할 만한 실험적 RFC의 가장 오래 지속되는 부분입니다. 2000년 12월에 발행된Unified Memory Space Protocol Specification은 원격 프로시저 호출보다 더 야심적인 것을 제안했습니다. 인터넷 노드에 걸친 128비트 주소 공간을 애플리케이션에 제공하고, 가상 머신이 메모리 및 제어 명령을 네트워크 명령으로 변환하게 했습니다. 스레드는 원격 메모리를 읽거나 쓸 수 있었고, 저장소를 할당하거나 해제하고, 코드를 이동하고, 객체 프로시저를 호출하거나, 그곳에서 새 스레드를 생성하는 원격 주소로 점프할 수 있었습니다.
네트워크가 사라진 것은 아니었습니다. 명령어 집합 안으로 숨겨진 것입니다.
하나의 주소 공간은 여러 소유자를 숨기고 있었다
UMSP는 계산을 잡(job), 태스크(task), 스레드로 나누었습니다. 잡은 분산 애플리케이션을 대표했고, 각 노드는 그 잡에 대해 최대 하나의 태스크를 보유했으며, 하나의 태스크는 여러 제어 스레드를 포함할 수 있었습니다. 잡 제어 지점(Job Control Point, JCP)은 잡의 태스크를 중앙에서 추적하고 제어 식별자를 할당했습니다.
주소는 통합된 것처럼 보였지만 권한은 그렇지 않았습니다. JCP는 잡 조정을 통제했고, 각 노드는 자신의 로컬 메모리를 통제했으며, 가상 머신은 메모리, 포인터 및 실행 순서를 관리했고, 전송 계층은 노드 간에 명령을 전달했으며, 사용자 코드는 효과가 다른 곳에서 발생할 수 있는 연산을 시작했습니다.
RFC 3018은 이러한 구분을 반복적으로 보존했습니다. 이 프로토콜은 로컬 잡 메모리를 통제하지 않았고, 사용자 제어 스레드를 추적하지 않았으며, 태스크가 끝나면 가상 머신이 포인터를 무효화해야 했고, 제어 전송이 새 원격 스레드를 만들 수 있었음에도 연속 코드 세그먼트는 노드에 걸칠 수 없었습니다.
이것은 은유를 문자 그대로 받아들이지 말라는 유용한 경고입니다. 16옥텟 포인터는 먼 위치를 지칭할 수 있었지만, 먼 메모리가 하나의 클록, 하나의 장애 도메인 또는 하나의 복구 권한 아래에서 로컬 레지스터처럼 동작하게 만들지는 않았습니다. 주소는 네임스페이스를 연결했을 뿐, 관할권을 합치지는 않았습니다.
연산들은 이 거버넌스 문제를 구체적으로 만들었습니다. UMSP는 즉시 읽기와 쓰기, 메모리 할당과 해제, 비교, 동기화,JUMP,CALL, 객체 생성과 삭제, 그리고 객체 프로시저 실행을 포함했습니다. 실수는 단순히 형식이 잘못된 메시지가 아니었습니다. 변형, 자원 할당 또는 다른 기계 위의 새로운 제어 지점이 될 수 있었습니다.
연쇄에는 한 순간이 아니라 세 순간이 있었다
RFC 3018은 여러 종류의 명령 연쇄를 정의했습니다. 시퀀스는 의존적인 연산을 연결했습니다. 다음 명령은 이전 명령이 끝난 후에만 실행될 수 있었고, 실패하면 나머지 명령이 취소되었습니다. 트랜잭션은 달리 관련되지 않은 명령을 연결할 수 있었습니다. 전부가 함께 실행되거나 아무것도 실행될 수 없었습니다.
그럼에도 트랜잭션은 뚜렷한 상태들을 통과했습니다.
먼저 전송이 있었습니다. 수신자가 번들 전체를 버퍼링해야 할 수 있었기 때문에 길이는 사전에 알려져야 했습니다._BEGIN_TR은 트랜잭션이 어떻게 동작해야 하는지를 기술했고,_END_CHAIN은 마지막 명령을 표시했습니다.
다음은 준비성이었습니다.TRR가 설정되면 전송 완료가 즉시 실행을 유발했습니다. 해제되어 있으면 수신자는 별도의EXEC_TR이 도착할 때까지 트랜잭션을 보관했습니다. 실행 전에CANCEL_TR은 저장된 명령을 복구 없이 버릴 수 있었습니다.
마지막은 실행이었습니다.TRE는 수명이 만료되거나 세션이 비정상적으로 끝날 때, 완전했지만 아직 실행되지 않은 트랜잭션조차 실행되도록 요구할 수 있었습니다. 무기한의 불확실성을 막기 위한 플래그가 네트워크 실패를 실행 트리거로 바꿀 수 있었던 것입니다. 수명 클록은 모든 명령이 도착한 후에야 시작되었고, 0은 한계를 부과하지 않았습니다.
이러한 제어들은 정확한 질문에 답했습니다. 번들은 완전한가? 대기해야 하는가? 어느 연쇄를 해제할 것인가? 실행되지 않은 연쇄는 언제 만료되는가? 이것들은 하나의 “커밋된” 비트로 수축하지 않았습니다.
유용한 감사는 최소한 네 개의 영수증을 보존할 것입니다. 완전한 트랜잭션의 다이제스트와 식별자, 수신자의 버퍼링 준비 상태, 해제 또는 취소 결정, 그리고 모든 결과를 낳는 명령의 관측된 결과. 이것들이 없다면 세션이 끊긴 상황에서 운영자는 바이트가 부분적이었는지, 번들이 완전했지만 대기 중이었는지, 만료 규칙이 그것을 해제했는지, 또는 링크가 실패하기 전에 실행이 시작되었는지 알 수 없습니다.
원자적 실행은 보상이 아니었다
트랜잭션이라는 단어는 RFC가 하지 않은 데이터베이스적 가정을 불러옵니다. RFC 3018은 명령이 한꺼번에 실행되거나 실행되지 않을 것을 요구했습니다. 이미 실행된 세계를 복원할 것을 약속하지는 않았습니다.
문서는 이 경계를 직접 서술합니다. 실행 후의 트랜잭션 취소는 규정되지 않는다. 보상 메커니즘이 필요하다면, 그것은 VM 계층에 속합니다. 그 이유는 빠진 오퍼레이션 코드가 아니라, 어떤 연산은 취소될 수 없다는 데 있습니다. 원격CALL은 또 다른 효과를 만들 수 있습니다.JUMP는 새로운 제어 스레드를 만들 수 있습니다. 쓰기는 원래 트랜잭션에 속하지 않는 코드에 의해 관측될 수 있습니다.FREE는 다른 곳에서 보유된 포인터를 무효화할 수 있습니다. 객체 프로시저는 그 역이 알려지지도 않고 안전하지도 않은 작업을 수행할 수 있습니다.
따라서 완벽하게 원자적인 번들조차 운영적으로 되돌릴 수 없을 수 있습니다.
트랜잭션이 메모리를 할당하고, 코드를 설치하고, 제어를 그 코드로 전송한다고 가정해 봅시다. 세 명령이 함께 실행에 들어갈 수 있었습니다. 새 스레드가 메시지를 보내거나, 장치를 작동하거나, 잡의 가역 도메인 밖의 상태를 변경한다면, 나중에 원래의 명령 연쇄를 삭제하는 것은 그 효과를 회수하지 못합니다. 프로토콜의 원자성은 실행으로의 진입을 통제합니다. 그것은 타임머신이 아닙니다.
그렇기 때문에 해제 영수증과 결과 영수증은 분리된 채 유지되어야 합니다.EXEC_TR은 명명된 연쇄를 실행하라는 명령이 프로토콜 하에서 전송되었음을 증명합니다. 그것만으로 어떤 VM 동작이 완료되었는지, 다운스트림 코드가 무엇을 했는지, 잡이 목표에 도달했는지, 또는 보상이 나중에 성공했는지를 증명하지는 않습니다.
여기서 RFC의 솔직함은 더 넓고 모호한 약속보다 가치 있습니다.
신뢰할 수 있는 전송 계층은 근거 공백을 메울 수 없었다
UMSP는 신뢰할 수 있는 교환을 위해 TCP 가용성을 요구했고, 확인 응답이 필요하지 않은 데이터에 대해서는 UDP를 허용했습니다. 또한 대체 전송 계층이 갖추어야 할 속성들, 즉 전송 보고, 중복 회피, 비상 재시작 이후의 세그먼트 식별을 기술했습니다.
TCP는 실제 문제를 해결합니다. RFC 793은 애플리케이션에 신뢰할 수 있는 순서가 보장된 옥텟 스트림을 제공하고, 손상되거나 잃어버리거나 중복되거나 순서가 어긋난 세그먼트에서 복구합니다. 그것은 UMSP 구현이 살아 있는 연결을 통해 운반되는 모든 바이트의 전달을 다시 발명할 필요가 없음을 의미합니다.
그러나 전송 계층의 확인 응답은 가상 머신의 영수증이 아닙니다. TCP는 수신 TCP가 옥텟을 수용했음을 보여줄 수 있습니다. 그것은 명령이 UMSP 검증을 통과했는지, 올바른 트랜잭션에 들어갔는지, 노드 재시작을 견뎠는지, 의도된 권한에 의해 해제되었는지, 기대한 메모리에 대해 실행되었는지, 또는 호출자가 원하는 애플리케이션 결과를 산출했는지 말할 수 없습니다.
인접한 ONC RPC 사양인 RFC 1831이 이 불확실성을 구체화합니다. TCP를 사용할 때, 응답은 그 모델에서 프로시저가 정확히 한 번 실행되었다는 추론을 지지할 수 있습니다. 응답이 없으면, 호출자는 실행되지 않았다고 가정할 수 없습니다. 서버는 연결이 실패하기 전에 요청을 실행했을 수 있습니다. ONC RPC는 또한 원격 호출이 실패 처리, 부작용, 성능 및 인증에서 로컬 호출과 다르다고 경고합니다.
UMSP는 제어 전송과 원격 메모리 접근을 명령으로 제시함으로써 더 나아갔습니다. 그것은 로컬 환상을 강화했지, 실패 의미론을 단순화하지 않았습니다.
잡 컨트롤러는 전지가 아니라 식별을 조율했다
JCP는 분산 잡에 중심을 제공했습니다. 전역 잡 식별자를 할당하고, 태스크 생성과 완료를 추적했으며, 중앙화된 사용자 식별과 공격 방어를 위한 장소 역할을 할 수 있었습니다.
중앙성은 기록의 상호 연관을 쉽게 만들 수 있습니다. 그것이 자동으로 기록을 완전하게 만들지는 않습니다.
JCP는 태스크가 등록했음을, 세션이 열렸음을, 또는 잡이 완료를 보고했음을 알 수 있었습니다. 그러나 VM은 여전히 메모리와 포인터를 통제했습니다. 원격 스레드는 컨트롤러의 직접 관측 밖의 효과를 만들어낼 수 있었습니다. 전송 계층은 실행 후 응답 전에 실패할 수 있었습니다. 오래된 세션 세그먼트가 여전히 문제가 되는 상태에서 노드가 재시작될 수 있었습니다. 따라서 컨트롤러는 다이어그램에서의 위치로부터 빌린 권한이 아니라 각 계층으로부터의 근거를 필요로 했습니다.
이 구분은 완료와 관련해 중요합니다. “모든 태스크가 끝났다”는 잡 수명 주기의 사실입니다. 그것은 의도된 모든 쓰기가 지속되었음을, 모든 객체 프로시저가 올바른 결과를 산출했음을, 외부에서 관측 가능한 모든 효과가 정확히 한 번 발생했음을, 또는 누출된 모든 권한이 회수되었음을 증명하지 않습니다.
보안은 의도적으로 초기 메커니즘의 밖에 있었다
RFC 3018의 보안 절은 초기 프로토콜 복잡성을 줄이기 위해 안전성 질문이 문서에 포함되지 않았다고 서술하며 시작합니다. 그 절의 제안들은 향후 확장을 위한 권고였습니다.
이 고백은 프로토콜에 관한 어떤 서술과도 함께 다녀야 합니다. UMSP는 원격 쓰기, 할당, 활성 코드 및 제어 전송을 노출할 수 있었습니다. 초기 사양은 그러한 권한들에 대한 완전한 보안 구성을 정의하지 않았습니다.
문서는 TCP/IP에서 사용 가능한 보호를 사용하고, 무결성 또는 암호화 알고리즘을 특별 처리된 연쇄에 배치하며, 인증 매개변수를 확장 헤더로 전송할 것을 제안했습니다. 통신 노드들과 JCP 사이의 인증 관계를 제안했습니다. 중간자 공격 탐지를 위해, 그 당사자들 사이의 경로가 겹치지 않는 토폴로지를 기술했고, 공통 게이트웨이가 그 체계를 약화시킨다는 것을 인정했습니다.
문서는 또한JUMP와CALL을, 그 자원 통제가 VM에 속하는 서비스 거부 위험으로 지목했습니다. 클라이언트에 활성 코드를 내려받는 것이 클라이언트를 노출시키는 반면, 서버에서 클라이언트 코드를 실행하는 것은 서버의 보호 부담을 늘린다는 것을 인식했습니다.
이 관찰들은 위험 표면을 식별합니다. 그것들은 키, 알고리즘, 신원, 인가 정책, 재생 방어, 회수 또는 감사를 구현하지 않습니다.
나중에 발행된 RFC 3552는 유용한 사후 대조를 제공합니다. 그 인터넷 위협 모델은 공격자가 통신 채널에서 트래픽을 읽고, 제거하고, 변경하고, 주입할 수 있다고 가정합니다. 그 후대의 지침을 RFC 3018이 따라야 했던 규칙으로 소급해서 투영해서는 안 됩니다. 그것은 다만 경로 분리와 미정의 확장 헤더가 완성된 보안 영수증으로 다뤄질 수 없는 이유를 보여줍니다.
실험적이었다는 것은 보관된 제안이었지 배치된 사실이 아니었다
RFC 3018은 실험적(Experimental)으로 발행되었습니다. RFC 2026은 실험적 문서를 표준 트랙 밖에 두고, 그것이 인터넷 표준이 아니라고 말합니다. 그러한 문서는 기술 커뮤니티를 위해 연구 또는 개발 작업을 보존할 수 있습니다.
그 지위는 그 아이디어들이 어리석었다는 판정도, 구현되었다는 증명도 아닙니다. 여기서 검토한 출처들은 설계, 그것의 명시적 경계, 그리고 TCP, UDP 및 RPC와의 관계를 확립합니다. 그것들은 UMSP 제품, 배치, 상호운용성 이벤트, 장애, 채택률 또는 운영적 성공을 확립하지 않습니다.
이 문서가 역사적으로 유용한 것은, 야심적인 추상을 판독 가능하게 만들기 때문입니다. 애플리케이션 코드가 네트워크를 무시하고 대신 128비트 명령을 사용하게 하려 했습니다. 그러면서 그 추상이 지울 수 없었던 영수증들을 노출시켰습니다.
주소는 통합될 수 있었지만 제어는 분산된 채였습니다. 트랜잭션은 원자적일 수 있었지만 그 효과는 되돌릴 수 없는 채였습니다. 바이트는 도착할 수 있었지만 실행은 불확실한 채였습니다. 잡은 끝날 수 있었지만 의도된 현실 세계의 결과는 관측되지 않은 채였습니다.
Lu Heng의 Running-Code Primacy는 그 순서를 위한 분석적 렌즈를 제공합니다. 프로토콜 서술은 실행 중인 시스템과 관측 가능한 효과를 통해서만 운영적 사실이 됩니다. Reality Layers는 인코딩된 명령, 버퍼링된 연쇄, 해제, 실행 및 결과가 서로의 권한을 빌려 쓰지 않도록 유지합니다. Minimum Initial Specification은 왜 얇은 실험적 핵심이 선택을 열어 둘 수 있는지, 그리고 보안, 보상 및 관측이 “트랜잭션”이라는 단어로부터 추론되는 것이 아니라 빠진 계약으로 명명되어야 하는 이유를 설명합니다.
이것들은 이후의 렌즈이며, RFC 저자의 동기에 대한 주장이 아닙니다.
트랜잭션은 실재했습니다. 그 경계는 다만 그것이 바꿀 수 있는 세계보다 좁았을 뿐입니다.
출처
- RFC Editor 기록: RFC 3018
- RFC 3018: Unified Memory Space Protocol Specification
- RFC 3018 일반 텍스트 보관판
- RFC Editor 기록: RFC 1831
- RFC 1831: RPC 원격 프로시저 호출 프로토콜 버전 2
- RFC Editor 기록: RFC 793
- RFC 793: 전송 제어 프로토콜(Transmission Control Protocol)
- RFC Editor 기록: RFC 768
- RFC 768: 사용자 데이터그램 프로토콜(User Datagram Protocol)
- RFC Editor 기록: RFC 2026
- RFC 2026: 인터넷 표준 프로세스
- RFC Editor 기록: RFC 2119
- RFC 2234: 문법 명세를 위한 확장 BNF
- RFC 3552: 보안 고려사항 RFC 텍스트 작성 지침
- Lu Heng: Running-Code Primacy
- Lu Heng: Reality Layers
- Lu Heng: Minimum Initial Specification
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





