KR101021360B1 - 피어 투 피어 네임 레졸루션 와이어 프로토콜 및 프로토콜에 사용하기 위한 메세지 포맷 데이터 구조를 생성 및 발송하기 위한 방법 및 컴퓨터 판독가능 기록매체 - Google Patents

피어 투 피어 네임 레졸루션 와이어 프로토콜 및 프로토콜에 사용하기 위한 메세지 포맷 데이터 구조를 생성 및 발송하기 위한 방법 및 컴퓨터 판독가능 기록매체 Download PDF

Info

Publication number
KR101021360B1
KR101021360B1 KR1020040043115A KR20040043115A KR101021360B1 KR 101021360 B1 KR101021360 B1 KR 101021360B1 KR 1020040043115 A KR1020040043115 A KR 1020040043115A KR 20040043115 A KR20040043115 A KR 20040043115A KR 101021360 B1 KR101021360 B1 KR 101021360B1
Authority
KR
South Korea
Prior art keywords
message
pnrp
peer
field
array
Prior art date
Application number
KR1020040043115A
Other languages
English (en)
Other versions
KR20040107420A (ko
Inventor
존엔. 밀러
헨리 라와스
라두 시미오네스쿠
브라이언 리에울렌
Original Assignee
마이크로소프트 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 마이크로소프트 코포레이션 filed Critical 마이크로소프트 코포레이션
Publication of KR20040107420A publication Critical patent/KR20040107420A/ko
Application granted granted Critical
Publication of KR101021360B1 publication Critical patent/KR101021360B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4541—Directories for service discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/24—Time-division multiplex systems in which the allocation is indicated by an address the different channels being transmitted sequentially
    • H04J3/242—Time-division multiplex systems in which the allocation is indicated by an address the different channels being transmitted sequentially the frames being of variable length
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1044—Group management mechanisms 
    • H04L67/1046—Joining mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
    • H04L67/1065—Discovery involving distributed pre-established resource-based relationships among peers, e.g. based on distributed hash tables [DHT] 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)
  • Communication Control (AREA)

Abstract

피어 투 피어 네임 레졸루션 프로토콜(peer to peer name resolution protocol, 이하 "PNRP"라고 함)에서 메세지의 확장 가능한 데이터 구조(extensible data structure)가 개시된다. 이 메세지 데이터 구조는 다수의 필드를 이용하고, 각 필드는 메세지 엘리먼트(message element)를 포함한다. 바람직하게, 제1 필드는 프로토콜 정보를 포함하고 메세지 유형을 식별하는 메세지 헤더(header)이다. 각 메세지 엘리먼트는 다수의 필드를 포함한다. 이러한 메세지 엘리먼트 필드로는 유형 필드(type field), 길이 필드(length field), 및 메세지 엘리먼트의 내용 또는 페이로드(payload)가 있다. 한 실시예에서, PNRP가 제대로 동작하기 위해 적어도 10개의 메세지가 형성되고, 그 10개의 메세지들은 RESOLVE, RESPONSE, SOLICIT, ADVERTISE, REQUEST, FLOOD, INQUIRE, AUTHORITY, ACK 및 REPAIR이다.
피어, 네임 레졸루션 프로토콜, 메세지, 피어 투 피어 메세징 프로토콜

Description

피어 투 피어 네임 레졸루션 와이어 프로토콜 및 프로토콜에 사용하기 위한 메세지 포맷 데이터 구조를 생성 및 발송하기 위한 방법 및 컴퓨터 판독가능 기록매체{PEER-TO-PEER NAME RESOLUTION WIRE PROTOCOL AND MESSAGE FORMAT DATA STRUCTURE FOR USE THEREIN}
도 1은 본 발명이 구현될 수 있는 예시적인 컴퓨터 시스템을 일반적으로 도시하는 블록도.
도 2는 PNRP의 기능 엘리먼트를 도시하는 간략한 블록도.
도 3은 본 발명의 양상을 도시하는 프로토콜 메세지 흐름도.
도 4는 본 발명의 다른 양상을 도시하는 프로토콜 메세지 흐름도.
도 5는 본 발명의 메세지 구성을 가능하게 하는 본 발명의 확장 가능한 데이터 구조 모델을 도시하는 데이터 구조도.
도 6은 본 발명의 예시적인 메세지의 구성을 도시하는 간략한 데이터 구조도.
<도면의 주요 부분에 대한 부호의 설명>
110: 컴퓨팅 환경
120: 처리 장치
130: 시스템 메모리
121: 시스템 버스
본 발명은 일반적으로 피어 투 피어 인프라스트럭처(peer-to-peer infrastructure)에서의 통신 프로토콜에 관한 것이고, 보다 구체적으로는, 피어 투 피어 그래프에서 구조화된 통신을 가능하게 하는 메세지 포맷 데이터 구조에 관한 것이다.
인터넷 상의 다양한 통신 기술을 통해 공통의 관심사를 지닌 사용자들은 협력하고, 파일을 공유하고, 서로 채팅하고, 프레젠테이션 및 그룹 미팅을 위해 오디오 및 비디오를 멀티 캐스트하고, 다중 플레이어 게임에 참여할 수 있다. 그러나, 현재, 인터넷 상의 대부분의 통신은 서버 중심의 환경에서 일어나고, 따라서 모든 통신은 중앙의 거대한 서버로 또는 이를 통해 흐르고, 개인들은 이러한 통신에 가입하거나 참여하기 위해 중앙의 서버로 접속할 수 있다.
피어 투 피어 기술이 재출현하면서, 인터넷 통신의 서버 중심의 현재 모델이 급속도로 대체되고 있다. 실제로, 피어 투 피어 기술을 이용하여 사용자들은 서버가 없는 환경에서 서로를 접촉할 수 있고, 서버 기반 인터넷 통신의 제한을 받지 않는다. 피어 투 피어 기반 시스템에서는, 네트워크 내의 피어간에 통신이 직접 일어나기 때문에 사용자 익명성(anonymity) 및 프라이버시(privacy)가 유지될 수 있다. 그러나, 개별 통신 및 파일 공유는 상대적으로 피어 투 피어 네트워크에서 양호하게 확립되어 있는 반면, 설정(establishing), 탐색(discovering), 가입(joining), 유지(maintaining), 및 정보 공유는 피어 투 피어 환경에서 양호하 게 확립되어 있지 않다.
피어 투 피어 환경 및 실제 모든 유형의 통신은 선택된 엔티티 또는 노드간의 유효한 접속을 설정하는 가능성에 좌우된다. 이러한 엔티티 및 노드는 피어 투 피어 네트워크 내에서 형성된 피어(예를 들어, 사용자 또는 기계) 또는 그룹일 수 있다. 노드간의 접속은 노드로 및 노드간에 전달되는 통신 및 정보를 가능하게 하는 피어 투 피어 그래프를 형성한다. 그러나, 엔티티는 네트워크 내에서 이동하기 때문에, 망의 형태(topology)가 바뀌기 때문에, 어드레스 임대(address lease)를 다시 시작할 수 없기 때문에, 그룹 기능 및 목적이 바뀌기 때문에, 하나 또는 변경할 수 있는 여러 어드레스를 지닐 수 있다. 따라서, 이 문제에 대한 전통적이고 구조적인 솔루션은 각 엔티티에 고정된 이름을 할당하고, 접속이 필요하면 그 이름을 현재의 어드레스로 "해석하는(resolve)" 것이다. 이 이름에서 어드레스로의 변환은 확고해야 하며, 또한 쉽고 빠르게 업데이트 할 수 있어야 한다.
한 엔티티에 접속하고자 하는 이들에 의해 그 엔티티의 어드레스가 발견될 가능성을 증가시키기 위해, 많은 피어 투 피어 프로토콜에서 엔티티들은 다양한 메커니즘을 통해 자신의 개별 또는 그룹 어드레스를 널리 알릴 수 있다. 또한 일부 프로토콜에서 클라이언트는 네트워크 내의 다른 노드로부터의 요청을 처리함으로써 다른 엔티티의 어드레스를 알 수 있다. 실제로, 이렇게 어드레스를 알아내고 확고한 그래프를 유지함으로써 이 피어 투 피어 네트워크의 성공적인 동작을 가능하게 한다. 즉, 네트워크 내의 다른 피어 및 그룹에 대해 더 좋은 정보(즉, 더 확고한 그래프)를 알아내면 알아낼수록, 특정 리소스 또는 레코드에 대한 검색이 집중될 가능성이 더 커진다.
서버 중심 환경에서, 피어 투 피어 그래프는 그래프 내에서 인터넷 파일 검색 및 공유 허용을 전적으로 허용한다. 그러나, 피어 투 피어 네트워크가 분산 사용자 또는 피어 그래프로서 형성되기 때문에, 네트워크 내의 모든 피어가 공유된 정보를 알게 되기 전에 한 피어에서 다른 피어로 통신 및 데이터(레코드)가 전달될 필요가 있다. 이러한 라우팅을 제공하는 시스템으로는 Usenet 및 OSPF가 있다. 그러나, 이러한 현재의 시스템은 지금까지 피어 투 피어 기술의 완전한 개발을 오늘날까지 제한해 오고 있는 한계로 인해 어려움을 겪고 있다. 게다가, 피어 투 피어 네트워크는 현재 충분한 그래프 관리의 부족으로 인해 때때로 멤버 중 하나가 그룹을 떠날 때 그래프가 깨지거나 또는 분할되는 어려움을 겪고 있다. 이러한 경우에, 그래프의 한 부분으로부터 온 정보는 피어 중 하나의 일탈로 인해 생성된 파티션의 다른 쪽에 있는 피어 멤버로 더 이상 전달될 수 없다. 더 불리한 것은, 이러한 파티션을 검출하는 데에 충분한 메커니즘이 없다는 것이다.
종래에 존재했던 기능 문제 뿐만 아니라, 네트워크 트래픽의 양이 쉽게 클라우드 내에 참가하는 피어를 제압할 수 있다. 메세지 크기 및 구조는 신속하게 메세지를 처리하는 피어 기능을 복잡하게 만들고, 따라서 클라우드의 크기가 커짐에 따라 지연되거나 버려진 통신을 초래하기도 한다.
그러므로 상술된 문제 및 종래 기술의 다른 문제를 해결하는 피어 투 피어 메세징 프로토콜 및 데이터 구조에 대해 종래 기술의 요구가 존재한다.
본 출원에 개시된 발명의 개념은 PNRP에서 사용되기에 적합한 메세지의 확장 가능한 데이터 구조에 관한 것이다. 이 메세지 데이터 구조는 PNRP에서 사용되는 다양한 메세지를 구성하기 위해 메세지 데이터 필드를 이용한다. 이 메세지 데이터 필드 각각은 메세지 엘리먼트를 포함한다. 바람직하게, 제1 필드는 프로토콜 정보를 포함하고 메세지 유형을 식별하는 메세지 헤더 엘리먼트이다.
메세지 그 자체가 그러하듯이, 각 메세지 엘리먼트는 다수의 메세지 엘리먼트 데이터 필드를 포함한다. 이 메세지 엘리먼트 필드들에는 유형 필드, 길이 필드, 및 메세지 엘리먼트의 내용 또는 페이로드가 있다. 유형 필드는 메세지 엘리먼트의 유형을 명시하는 식별자를 포함한다. 길이 필드는 필드 유형 및 길이 필드를 포함하여 메세지 엘리먼트의 길이를 나타낸다.
한 실시예에서, PNRP가 제대로 동작하기 위해 적어도 10개의 메세지가 형성된다. 그 10개의 메세지들은 RESOLVE 메세지, RESPONSE 메세지, SOLICIT 메세지, ADVERTISE 메세지, REQUEST 메세지, FLOOD 메세지, INQUIRE 메세지, AUTHORITY 메세지, ACK 메세지 및 REPAIR 메세지이다. 이들 메세지는 바람직한 실시예에 존재하는 22가지의 다른 메세지 엘리먼트들로부터 구성된다.
본 명세서에 포함되고 그 일부를 형성하는 이하 첨부된 도면들은 본 발명의 여러 양상을 도시하고, 설명과 함께 본 발명의 원리를 설명하기 위한 것이다.
본 발명은 일부 바람직한 실시예와 함께 기술될 것이지만, 이러한 실시예에 제한되도록 의도하지 않는다. 이와는 대조적으로, 이하 첨부된 청구범위에 의해 정의된 본 발명의 정신 및 범위 내에 포함되는 모든 대안, 변경, 및 동등물을 다 포함하고자 한다.
도면에서, 유사한 참조 번호는 유사한 엘리먼트(element)를 참조하고, 본 발명은 적합한 컴퓨팅 환경에서 구현된 것으로 도시된다. 필수는 아니지만, 본 발명은 퍼스널 컴퓨터에 의해 실행되는, 프로그램 모듈과 같은 컴퓨터 실행가능 명령어의 일반적인 관점에서 기술될 것이다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등을 포함한다. 또한, 당업자들은 본 발명이 핸드헬드 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 또는 프로그램 가능한 가전제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터 등과 같은 다른 컴퓨터 시스템 구성에서 수행될 수 있다는 것을 이해할 것이다. 본 발명은 또한 통신 네트워크를 통해 링크된 원격 처리 장치에 의해 태스크를 수행하는 분산 컴퓨팅 환경에서 실행될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 로컬 및 원격 메모리 스토리지 장치 둘 다에 위치할 수 있다.
도 1은 본 발명이 구현될 수 있는 적합한 컴퓨팅 시스템 환경(100)의 일례를 도시하고 있다. 컴퓨팅 시스템 환경(100)은 단지 적합한 컴퓨팅 환경의 일례에 불과할 뿐이며, 본 발명의 사용 또는 기능의 범위에 관해 어떤 제한을 두고자 하는 것이 아니다. 또한, 컴퓨팅 환경(100)이 예시적인 운영 환경(100)에 도시된 컴포넌트들 중의 임의의 하나 또는 그 조합에 관하여 어떤 종속성 또는 요건을 갖춰야 하는 것으로 해석되어서도 안된다.
본 발명은 많은 다른 범용 또는 전용 컴퓨팅 시스템 환경들 또는 구성들과 함께 동작될 수 있다. 본 발명과 함께 사용하기에 적합할 수 있는 잘 알려진 컴퓨팅 시스템, 환경, 및/또는 구성의 예로는, 퍼스널 컴퓨터, 서버 컴퓨터, 핸드헬드 또는 랩탑 장치, 멀티프로세서 시스템, 마이크로프로세서-기반 시스템, 셋탑 박스, 프로그램 가능한 가전제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 상기의 시스템 또는 장치 중의 임의의 것을 포함하는 분산 컴퓨팅 환경 등이 포함될 수 있지만, 이에 한정되지 않는다.
본 발명은 컴퓨터에 의해 실행되는, 프로그램 모듈과 같은 컴퓨터 실행가능 명령어의 일반적인 관점에서 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등을 포함한다. 본 발명은 또한 통신 네트워크를 통해 링크된 원격 처리 장치에 의해 태스크를 수행하는 분산 컴퓨팅 환경에서 실행될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 스토리지 장치를 포함하는 로컬 및 원격 컴퓨터 스토리지 매체 둘 다에 위치할 수 있다.
도 1을 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은 컴퓨터(110)의 형태의 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 컴포넌트들로는, 처리 장치(120), 시스템 메모리(130), 및 시스템 메모리를 포함하는 여러 시스템 컴포넌트를 처리 장치(120)에 연결시키는 시스템 버스(121)가 포함될 수 있지만, 이에 한정되는 것은 아니다. 시스템 버스(121)는 여러 버스 아키텍처 중의 임의의 것을 사용하는 로컬 버스, 주변 버스, 및 메모리 버스 또는 메모리 컨트롤러를 포함하는 몇가지 유형의 버스 구조 중의 임의의 것일 수 있다. 예로서, 이러한 아키텍처는 ISA(industry standard architecture) 버스, MCA(micro channel architecture) 버스, EISA(Enhanced ISA) 버스, VESA(video electronics standard architecture) 로컬 버스, 및 메자닌 버스(mezzanine bus)로도 알려진 PCI(peripheral component interconnect)를 포함하지만, 이에 한정되는 것은 아니다.
컴퓨터(110)는 일반적으로 여러 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터(110)에 의해 액세스될 수 있는 임의의 사용가능한 매체일 수 있으며, 휘발성 및 비휘발성 매체, 이동식 및 이동불가식 매체를 둘 다 포함한다. 예로서, 컴퓨터 판독가능 매체는 컴퓨터 스토리지 매체 및 통신 매체를 포함할 수 있지만, 이에 한정되는 것은 아니다. 컴퓨터 스토리지 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 이동불가식 매체를 모두 포함한다. 컴퓨터 스토리지 매체는 RAM, ROM, EEPROM, 플래쉬 메모리 또는 기타 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 기타 광학 디스크 스토리지, 자기 카세트, 자기 테이프, 자기 디스크 스토리지 또는 기타 자기 스토리지 장치, 또는 컴퓨터(110)에 의해 액세스될 수 있고 원하는 정보를 저장하는 데 사용될 수 있는 임의의 기타 매체를 포함할 수 있지만, 이에 한정되지 않는다. 통신 매체는 일반적으로 반송파 또는 기타 전송 메카니즘 등의 피변조 데이터 신호에 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈, 또는 다른 데이터를 구현하며, 임의의 정보 전달 매체를 포함한다. "피변조 데이터 신호"라는 용어는 신호 내에 정보를 인코딩하도록 그 신호의 특성 중 하나 이상이 설정되거나 변환된 신호를 의미한다. 예로서, 통신 매체는 유선 네트워크 또는 직접 유선 접속(direct-wired connection) 등의 유선 매체와, 음향, RF, 적외선 및 기타 무선 매체 등의 무선 매체를 포함하지만, 이에 한정되지 않는다. 상술한 것들의 모든 조합은 또한 컴퓨터 판독가능 매체의 범위 내에 포함되어야 한다.
시스템 메모리(130)는 ROM(131) 및 RAM(132) 등의 휘발성 및/또는 비휘발성 메모리의 형태의 컴퓨터 스토리지 매체를 포함한다. 시동 시, 컴퓨터(110) 내의 엘리먼트들간에 정보를 전송하는 것을 돕는 기본 루틴을 포함하는 기본 입출력 시스템(BIOS)(133)은 일반적으로 ROM(131)에 저장된다. RAM(132)은 일반적으로 처리 장치(120)에 의해 즉시 액세스될 수 있는 것 및/또는 처리 장치(120)에 의해 현재 작동되고 있는 프로그램 모듈 및/또는 데이터를 포함한다. 예로서, 도 1에는 운영 체제(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)가 도시되어 있지만, 이에 한정되는 것은 아니다.
컴퓨터(110)는 또한 다른 이동식/이동불가식, 휘발성/비휘발성 컴퓨터 스토리지 매체도 포함할 수 있다. 단지 예로서, 도 1에는 이동불가식/비휘발성 자기 매체로부터 판독하거나 그 자기 매체에 기록하는 하드 디스크 드라이브(141), 이동식/비휘발성 자기 디스크(152)로부터 판독하거나 그 자기 디스크에 기록하는 자기 디스크 드라이브(151), 및 CD-ROM 또는 기타 광학 매체 등의 이동식/비휘발성 광학 디스크(156)로부터 판독하거나 그 광학 디스크에 기록하는 광학 디스크 드라이브(155)가 도시되어 있다. 예시적인 운영 환경에서 사용될 수 있는 기타 이 동식/이동불가식, 휘발성/비휘발성 컴퓨터 스토리지 매체로는 자기 테이프 카세트, 플래쉬 메모리 카드, DVD(Digital versatile disk), 디지털 비디오 테이프, 반도체 RAM, 반도체 ROM 등이 있지만, 이에 한정되지 않는다. 하드 디스크 드라이브(141)는 일반적으로 인터페이스(140)와 같은 이동불가식 메모리 인터페이스를 통해 시스템 버스(121)에 접속되고, 자기 디스크 드라이브(151) 및 광학 디스크 드라이브(155)는 일반적으로 인터페이스(150)와 같은 이동식 메모리 인터페이스에 의해 시스템 버스(121)에 접속된다.
앞서 기술되고 도 1에 도시된 드라이브 및 그 관련 컴퓨터 스토리지 매체는 컴퓨터(110)에 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 기타 데이터의 저장을 제공한다. 도 1에서, 예를 들어, 하드 디스크 드라이브(141)는 운영 체제(144), 애플리케이션 프로그램(145), 기타 프로그램 모듈(146), 및 프로그램 데이터(147)를 저장하는 것으로 도시되어 있다. 이들 컴포넌트는 운영 체제(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)와 동일한 것이거나 그와 다른 것일 수 있음에 유의한다. 운영 체제(144), 애플리케이션 프로그램(145), 기타 프로그램 모듈(146), 및 프로그램 데이터(147)는 최소한 이들이 서로 다른 복사본(different copies)임을 나타내기 위하여 다른 번호를 부여하였다. 사용자는 일반적으로 마우스, 트랙볼, 또는 터치 패드라 불리우는 포인팅 장치(161) 및 키보드(162)와 같은 입력 장치를 통해 컴퓨터 시스템(110)에 명령 및 정보를 입력할 수 있다. 기타 입력 장치(도시 생략)로는 마이크, 조이스틱, 게임 패드, 위성 안테나, 스캐너 등이 있을 수 있다. 이들 입력 장치 및 기타 입 력 장치는 시스템 버스에 연결된 사용자 입력 인터페이스(160)를 통해 종종 처리 장치(120)에 접속되지만, 병렬 포트, 게임 포트 또는 USB(universal serial port)와 같은 기타 인터페이스 및 버스 구조에 의해 접속될 수도 있다. 모니터(191) 또는 다른 유형의 디스플레이 장치도 또한 비디오 인터페이스(190) 등의 인터페이스를 통해 시스템 버스(121)에 접속된다. 모니터 외에도, 컴퓨터는 또한 출력 주변 인터페이스(195)를 통해 접속될 수 있는 스피커(197) 및 프린터(196) 등의 기타 주변 출력 장치도 포함할 수 있다.
컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 이용하여 네트워크화된 환경에서 동작될 수 있다. 원격 컴퓨터(180)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어(peer) 장치, 또는 다른 공통 네트워크 노드일 수 있으며, 컴퓨터(110)에 관하여 상술한 구성요소 중 다수 또는 그 모두를 일반적으로 포함할 수 있지만, 도 1에는 메모리 스토리지 장치(181)만이 도시되어 있다. 도 1에 도시된 논리적 접속은 LAN(171) 및 WAN(173)을 포함하지만, 그 외의 네트워크도 포함할 수 있다. 이러한 네트워킹 환경은 사무실, 기업 규모의 컴퓨터 네트워크, 인트라넷, 및 인터넷에서 일반적인 것이다.
LAN 네트워킹 환경에서 사용되는 경우, 퍼스널 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해 LAN(171)에 접속된다. WAN 네트워킹 환경에서 사용되는 경우, 컴퓨터(110)는 일반적으로 인터넷 등의 WAN(173)상에서의 통신을 설정하기 위한 모뎀(172) 또는 기타 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 기타 적절한 메카니즘을 통해 시스템 버스(121)에 접속될 수 있다. 네트워크화된 환경에서, 퍼스널 컴퓨터(110)에 관하여 도시된 프로그램 모듈 또는 그 일부분은 원격 메모리 스토리지 장치에 저장될 수 있다. 예로서, 도 1에서는 원격 애플리케이션 프로그램(185)이 메모리 장치(181)에 상주하는 것으로 도시되어 있지만, 이에 한정되는 것은 아니다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들간의 통신 링크를 구축하는 그 외의 수단이 사용될 수 있음을 잘 알 것이다.
이하의 설명에서, 다른 언급이 없다면, 본 발명은 하나 이상의 컴퓨터에 의해 수행되는 동작의 상징적인 표현(symbolic representation) 및 행위(acts)를 참조하여 기술될 것이다. 이와 같이, 이러한 행위 및 동작은 때때로 컴퓨터 실행가능한 것이며, 구조화된 형태로 데이터를 나타내는 전기 신호에 대한 컴퓨터의 처리 장치에 의한 조작을 포함한다는 것을 이해할 것이다. 이 조작은 데이터를 변환시키거나 컴퓨터 메모리 시스템 내의 위치에서 데이터를 보유하고, 이는 당업자들에게 잘 알려진 방법으로 컴퓨터 동작을 재구성하거나 그렇지 않으면 변경시킨다. 데이터가 보유되는 데이터 구조는 데이터 포맷에 의해 정의된 특정 속성들을 지니고 있는 메모리의 물리적 위치이다. 그러나, 본 발명을 상기한 관점에서 기술하였지만, 당업자는 이하에 설명되는 여러 행위 및 동작들이 하드웨어로도 구현될 수 있다는 것을 이해할 것이므로, 한정되지 않는다는 것을 알 것이다.
위에서 소개되었듯이, 피어-투-피어(peer-to-peer;P2P) 프로토콜의 성공은 선택된 엔티티간에 유효한 접속을 설정하는 프로토콜의 능력에 달려 있다. 또한, 이러한 P2P 네트워크에서 그룹을 형성하는 것도 이러한 능력에 달려 있다. 특정 사용자가 다른 어드레스를 갖는 여러 위치에서 여러 방법으로 네트워크에 접속할 수 있기 때문에, 바람직한 접근 방법은 고유의 아이덴티티(identity)를 사용자 또는 그룹에 할당하고, 그 아이덴티티를 프로토콜을 통해 특정 어드레스 또는 어드레스들로 해석하는 (resolve) 것이다. 이러한 피어-투-피어 네임 레졸루션 프로토콜(PNRP)에 특별히 적용된 아이덴티티 관리 시스템 및 본 발명의 방법이 2001년 8월 29일에 출원되고 현재 계류중인 출원 번호 제 09/942,164의 "피어-투-피어 네임 레졸루션 프로토콜 및 함께 사용되는 멀티레벨 캐쉬(Peer-to-Peer name resolution protocol and multilevel cache for use therewith)", 2002년 4월 15일에 출원되고 현재 계류중인 출원 번호 제 10/122,863의 "피어-투-피어 네임 레졸루션 프로토콜을 위한 멀티레벨 캐쉬 아키텍처 및 캐쉬 관리 방법(multi-level cache architecture and cache management method for Peer-to-Peer name resolution protocol)" 및 2001년 9월 19일에 출원되고 현재 계류중인 출원 번호 제 09/955,923의 "피어-투-피어 그래프 보유를 위한 피어-투-피어 그룹 관리 및 방법(Peer-to-Peer group management and method for maintaining Peer-to-Peer graph)" 에 설명되어 있으며, 이들의 내용 및 개시는 전부를 여기에 참조함으로써 포함된다.
또한, 2001년 9월 19일에 출원되고 현재 계류중인 출원 번호 제 09/956,260의 "피어-투-피어 네임 레졸루션 프로토콜 보안 인프라스트럭처 및 방법(Peer-to-Peer name resolution protocol security infrastructure and method)" 에 기초가 되는 보안 인프라스트럭쳐가 설명되어 있고, 이 보안 인프라스트럭쳐는 용량 초과 로 인한 네트워크에 불필요한 부하를 주지 않으면서, 네트워크 내의 여러 엔티티의 아이덴티티가 유효하도록 해 준다. P2P 그룹핑 환경에서, 2001년 9월 19일에 출원되고 현재 계류중인 출원 번호 제 09/955,924의 "피어-투-피어 네임 레졸루션 프로토콜 그룹 보안 인프라스트럭처 및 방법(Peer-to-Peer name resolution protocol group security infrastructure and method)"에 이러한 그룹을 위해 사용되고 기초가 되는 보안 인프라스트럭처가 설명되어 있다. 이 출원들의 내용 및 개시는 또한 전부를 여기에 참조함으로써 포함된다. 그러나, 본 발명의 인터페이스 및 방법이 이 PNRP에 특별히 적용되고 상호작용하면서, 당업자들은 본 발명이 P2P 그래프 관리 기능을 제공하고자 하는 모든 P2P 시스템 또는 프로토콜에 적용되지만, 이에 한정되지 않는다는 것을 이해할 것이다.
위의 PNRP를 기술하는 현재 계류중인 출원에서 언급되었듯이, 일부 유용한 배경지식을 제공하기 위해, 피어 네임 레졸루션 프로토콜(PNRP)은 피어를 기반으로 하여 이름으로부터 어드레스를 해석하는 프로토콜이다. 피어 자원은 피어 네임으로 주어진다. 애플리케이션은 피어 네임이 다른 피어들에게 탐색(discovery)될 수 있도록 PNRP로 피어 네임을 등록할 수 있다. 다른 애플리케이션들은 PNRP를 이용하여 피어 네임을 해석하고 등록된 애플리케이션의 대응하는 IP 어드레스 및 포트를 얻는다. PNRP는 피어 네임을 찾거나 훑어보는(browse) 어떠한 메커니즘도 제공하지 않는다. 피어 네임을 분배하는 메커니즘은 다른 수단을 통해 행해져야 한다. 피어 네임을 어드레스로 해석하는 것은 참여 피어들이 메세지를 서로에게 전달하고, 피어 네임 대 어드레스 매핑의 분산 캐쉬를 유지하는 데 있어 함께 동작함으로 써 행해진다. 등록 및 레졸루션 메커니즘은 초기화를 제외하고는 서버의 존재와 무관하다. PNRP 인스턴스는 처음 나타나면, 데이터를 교환할 일부 다른 PNRP 인스턴스의 어드레스를 찾아야 한다. 사용가능한 다른 수단이 없다면, 다른 PNRP 인스턴스 리스트를 획득하기 위해 잘 알려진 서버가 사용된다.
다시 말해, PNRP는 피어 애플리케이션으로 하여금 피어 네임 대 끝점(endpoint) 매핑을 등록할 수 있도록 하고, 피어 네임을 해석하여 끝점을 획득할 수 있도록 한다. 여기서 일부 정의가 필요하다. 피어 네임(peer name)은 피어 자원(peer resource)을 나타내는 문자열이다. 피어 네임을 등록하기 위해, 애플리케이션은 공용/전용 키 페어(public/private key pair)를 액세스해야만 한다. 키 페어는 변조(tempering)를 막기 위해 메세지 일부를 서명하는 데 사용된다. 피어 네임은 또한 공용 키에서 파생될 수 있으며, 아이덴티티 소유권(ownership) 검증(verification)을 가능하게 한다. 끝점은 하나의 IPv6/IPv4 어드레스, 포트 및 프로토콜이다. 사실상, 끝점들의 리스트가 하나의 피어 네임으로 등록될 수 있고, 피어 네임이 해석될 때 그 리스트는 리턴된다. 노드는 PRNP 프로토콜 서비스의 인스턴스이다. 일반적으로 컴퓨터당 하나의 노드가 있다. 클라우드(cloud, 구름 모양의 표시)는 서로 도달할 수 있는 노드들의 네트워크이다. 하나의 노드는 하나 이상의 클라우드에 접속될 수 있다. 클라우드는 IPv6에 정의된 범위(scope) - 글로벌(global), 사이트 로컬(site local), 및 로컬 링크(local link) - 와 동등한 범위 속성(scope property)을 지닌다. 노드는 다수의 사이트 로컬 클라우드(site local cloud) 및 다수의 링크 로컬 클라우드(link local cloud)를 지닐 수 있다. 노드들 간의 통신은 한 클라우드에서 다른 클라우드로 절대 교차해서는 안 된다. 클라우드 네임은 클라우드를 구분하기 위해 사용된다. 피어 네임은 하나 이상의 노드에 등록될 수 있다. PNRP는 각 등록이 서로 구분되도록 유지시킨다. 각 피어 네임 인스턴스와 관련된 끝점 리스트는 서로 다를 것이다. 노드 내에서, 노드가 접속된 하나 이상의 클라우드에 피어 네임을 등록하는 것도 또한 가능하다. 이러한 등록 각각은 구분된다. 정상적으로, 끝점 리스트는 또한 이러한 인스턴스들 각각에서 다를 것이다. 노드가 피어 네임을 해석하고자 시도할 때, 노드는 이것을 선택된 클라우드 상에서 수행한다. 피어 네임이 동일한 클라우드에 등록되었을 경우에만 그 해석은 성공할 것이다. 하나 이상의 클라우드에서 동시에 피어 네임을 해석하는 것은 가능하지만, 이들은 독립적인 리졸브 요청으로 다루어진다.
PNRP 서비스는 도 2에 도시된 대로 함께 작동하는 여러 모듈로 구성되어 있다. 서비스 관리 컴포넌트(service management component)(200)는 PNRP 서비스 시작 및 중지와 같은 단순한 정리작업(housekeeping)을 처리한다. RPC 서버 및 스터브(RPC server and stub)(202)는 클라이언트 프로세스와 PNRP 서비스간의 인터페이스를 제공한다. 이것은 요청의 엔트리 포인트(entry point)를 제공하는 노출된 인터페이스 및 이벤트와 요청 완료의 통보를 관리한다. 이것은 또한 클라이언트 프로세스 종료로부터의 복구(recovering)를 처리한다. 클라우드 관리자(cloud manager)(204)는 특정 클라이언트 요청의 상태를 유지하며, 사용가능 PNRP 클라우드 리스트를 유지한다. 이것은 클라우드를 생성하고, 클라우드 상태 변동을 클라 이언트에게 알리는 것을 담당한다.
캐쉬 관리자(cache manager)(206)는 로컬 PNRP 캐쉬, 및 각 클라우드에 로컬로 등록된 PNRP 네임 리스트를 유지한다. 이것은 분산 PNRP 캐쉬의 일부이다. 이것은 다른 컴퓨터들로부터 온 리졸브 요청(resolve request)에 대해 참조 및 다음 홉 선택(lookup and next hop selection)을 제공한다. 이것은 정기적으로 리졸브 요청을 개시함으로써 자신의 캐쉬를 유지하고, 캐쉬가 잘 구조화되도록 한다. 이것은 클라우드 분할(cloud split)을 검출하고, 그것을 복구하고자 한다. 이것은 다수의 등록된 피어 IDs를 지니는 능력을 제공하고, 캐쉬를 구조화하여 이들 각각을 지원한다. 프로토콜 관리자(protocol manager)(208)는 유효 PNRP 메세지 생성 및 전송을 처리하고, 수신된 PNRP 메세지를 처리한다. 이것은 캐쉬 관리자(206)와 함께 작동하여 PNRP 프로토콜을 구현한다. 마지막으로, 메세지 전송(message transport)(210)은 메세지의 실제 전송 및 수신을 처리한다. 이것은 다수의 네트워크 인터페이스 및 어드레스들을 다루며, 로컬 어드레스 집합에서 일어나는 변동을 검출한다. 다수의 프로토콜이 필요한 경우(IPv4 및 IPv6), 이 컴포넌트는 두 가지 프로토콜 모두를 처리할 것이다.
각 PNRP 노드는 클라우드 내의 일부 다른 노드들에 대한 피어 네임 대 끝점 매핑 캐쉬(cache of peer name to endpoing mappings)를 유지한다. 본 발명에 따라 구성된 메세지는 클라우드 내의 노드들에게 피어 네임에 대한 정보를 배포하기 위해 노드들간에 교환된다. 각 캐쉬를 바르게 유지시키는 것은 각 노드의 책임이다. 위의 출원에서 기술되었듯이, PNRP 프로토콜은 수치 네임스페이스(numerical namespace)을 정의한다. 각 피어 네임은 숫자로 변환되고, 그 숫자들은 근접성(proximity)을 결정하기 위해 네임스페이스에서 비교된다. 피어 네임 리졸브 요청이 노드에 도달하면, 노드는 숫자와 캐쉬 내의 숫자를 비교하여 희망 노드와 수치적으로 더 가까운 노드를 찾는다. 이러한 방법으로, 리졸브 요청은 노드에서 노드로 전달되고, 각 홉마다 목표에 점점 근접하게 된다.
피어 네임은 위의 출원에서 기술된 해싱 함수(hashing function)를 사용함으로써 P2P ID's라고 불리는 128 비트 숫자(128-bit number)로 변환된다. 동일한 피어 네임은 항상 동일한 P2P ID를 생성한다. 피어 네임 등록의 특정 인스턴스는 또한 서비스 위치(service location)라 불리는 128 비트 숫자를 지닌다. 이 두가지가 함께 PNRP ID라 불리는 256 비트 숫자를 만든다. PNRP ID의 서비스 위치 부분은 피어 네임 등록의 특정 인스턴스를 네트워크에서 유일한 것으로 만든다.
애플리케이션은 PNRP로 피어 네임을 등록할 수 있다. PNRP ID는 네임으로부터 생성되고, 다른 노드에게 이 등록을 알리기 위해 메세지가 전송된다. 동일한 피어 네임이 하나 이상의 노드에 등록될 수 있다. P2P ID는 각 노드에서 동일하지만, PNRP ID는 각 노드에서 유일해야 한다. 애플리케이션은 피어 네임을 어드레스로 해석해달라고 요청할 수 있다. P2P ID는 피어 네임으로부터 파생되고, 이 P2P ID를 등록했던 노드의 위치를 알아내기 위해 메세지가 다른 노드로 전송된다. P2P ID가 어드레스로 해석되면, 공인된 피어 어드레스(certified peer address, 이하 "CPA"라고 함)가 리턴된다. 이 CPA는 목표 PNRP ID의 서비스 위치 부분, 현재 IP 어드레스, 공개 키, 및 기타 많은 필드들을 포함한다. 이 CPA는 변조를 막기 위해 서명되었다.
주어진 P2P ID는 많은 다른 노드에서 등록될 수 있다. PNRP는 '서비스 위치' 접미사를 이용하여 각 등록된 인스턴스가 유일한 PNRP ID를 갖도록 한다. '서비스 위치'는 유일한 네트워크 서비스 끝점에 대응하는 128 비트 숫자이다. 이 값은 IPv6 어드레스, 포트, 프로토콜, 공개 키의 일부를 결합함으로써 생성된다. 서비스 위치는 PNRP 클라이언트에 불투명한 것으로 간주되어야 한다. 서비스 위치는 2개의 중요한 속성을 지닌다. 항상, 서비스 위치는 피어 네임의 유일한 인스턴스를 나타낸다. 2개의 서비스 위치가 비교될 때, 각각의 공통 접두사 길이를 이용하여 네트워크 근접성을 합리적으로 측정한다. 4개의 동일 비트로 시작되는 2개의 서비스 위치는 3개의 동일 비트로 시작하는 2개의 서비스 위치보다 일반적으로 더 가깝다. 이러한 이점은 글로벌 범위 네이티브 유니캐스트 IPv6 어드레스(global scope native unicast IPv6 address)에만 적용될 수 있다.
PNRP ID's를 생성하고 등록하는 것은 PNRP 서비스의 단지 일부일 뿐이다. PNRP 서비스 실행은 4개의 단계(phase)로 나뉘어질 수 있다. 첫번째는 PNRP 클라우드 탐색(discovery)이다. 새 노드는 자신이 가입하고자 하는 클라우드 내의 기존의 노드를 반드시 찾아야 한다. 그 클라우드는 글로벌 PNRP 클라우드, 사이트 로컬(기업(enterprise)) 클라우드, 또는 링크 로컬 클라우드일 수 있다. 두번째 단계는 PNRP 클라우드에 가입하는 것이다. 일단 새 노드가 기존의 노드를 찾았으면, 새 노드는 동기화(SYNCHRONIZE) 프로시져를 수행하여 기존 노드 최상위 캐쉬 레벨(existing nodes top cache level)의 일부를 획득한다. 하나의 캐쉬 레벨(single cache level)의 부분집합은 새 노드가 클라우드에 참여를 시작할 수 있도록 충분한 정보를 제공한다. 세번째 단계는 클라우드 내에서 적극적인 참여를 고려하는 것이다. 초기화가 완료된 후, 노드는 PNRP ID 등록 및 레졸루션에 참가할 수 있다. 이 단계동안, 피어는 또한 정기적인 캐쉬 유지를 수행한다. 마지막 단계는 피어가 클라우드를 떠나는 것에 관한 것이다. 노드는 로컬로 등록된 모든 PNRP ID's의 등록을 해제하고, 종료한다.
PNRP의 다양한 기능을 실시하기 위해, 본 발명의 PNRP 프로토콜은 10가지의 다른 메세지 유형을 포함한다. 상위 레벨에서, 메세지는 목표 PNRP ID를 CPA로 해석하도록 요청하는 데 사용되는 RESOLVE 메세지를 포함한다. RESPONSE 메세지는 완료된 RESOLVE 요청의 결과로서 사용된다. FLOOD 메세지는 수신자 PNRP 캐쉬에 사용될 CPA를 포함한다. SOLICIT 메세지는 PNRP 노드에게 자신의 최상위 레벨 캐쉬를 알리도록(ADVERTISE) 요청하는 데 사용된다. ADVERTISE 메세지는 노드의 최상위 레벨 캐쉬 내의 CPA들에 대한 PNRP ID 리스트를 포함한다. REQUEST 메세지는 노드에게 알려진 CPA의 부분집합을 플러드(flood)하도록 요청하는 데 사용된다. INQUIRE 메세지는 노드에게 특정 PNRP ID가 그 노드에 등록되어 있는지 여부를 묻는 데 사용된다. AUTHORITY 메세지는 PNRP ID의 로컬 등록을 확인하고, 선택적으로 그 ID에 대한 CPA의 유효성 검사를 돕는 인증서 체인(certificate chain)을 제공한다. ACK 메세지는 특정 메세지의 수신 및/또는 성공적인 처리를 확인하는 데 사용된다. 마지막으로, REPAIR 메세지는 분할될 수 있는 클라우드를 병합하고자 하는 데 사용된다.
노드는 본 발명의 메세지가 이용되는 동안 PNRP에서 6가지 기본 유형의 트랜잭션을 개시할 수 있다. 이러한 트랜잭션으로는 클라우드 탐색, 동기화, 레졸루션(resolution), 플러딩(flooding), 아이덴티티 유효성 검사(identity validation), 및 복구(repairing) 등이 있다. 이러한 트랜잭션에 대한 기본적인 이해를 제공하기 위해, 이에 대한 상세사항은 상술된 출원에 설명되어 있으며, 이 트랜잭션들이 본 발명의 메세지 및 메세지 구조와 관련이 있기 때문에 이하에 간략히 기술된다.
클라우드 탐색 트랜잭션은 피어로 하여금 피어 클라우드를 탐색할 수 있도록 한다. 바람직한 실시예에서, 각 노드는 몇몇 클라우드에 가입할 수 있다. 가입될 수 있는 클라우드 집합은 그 노드가 지니는 네트워크 연결성(network connectivity)에 좌우된다. 노드 컴퓨터가 다수의 인터페이스 어댑터를 지니고 있다면, 이것은 다수의 링크 로컬 클라우드에 가입할 수 있다. 노드가 IPv6를 지원하는 사이트의 일부라면, 이것은 사이트 로컬 클라우드에 액세스할 수 있다. 노드가 하나 이상의 그러한 사이트(아마 VPN을 통해)에 접속할 수 있다면, 이것은 다수의 사이트 로컬 클라우드에 액세스 할 수 있을 것이다. 노드가 인터넷으로 접속된다면, 이것은 글로벌 클라우드에 액세스 할 수 있을 것이다.
노드는 자신이 액세스하는 클라우드에 가입할 것인지 여부를 선택할 수 있다. 애플리케이션이 클라우드에 피어 네임을 등록하거나 또는 클라우드에 피어 네임을 해석하는 것을 처음 요청할 때, 노드는 아직 클라우드에 가입을 하지 않았다면 반드시 클라우드에 가입해야 한다. 클라우드에 가입하기 위해, 노드는 동일한 클라우드 내에 있는 적어도 하나의 다른 노드의 위치를 알아내고자 한다. 다른 노드를 찾지 못할 경우, 이 노드를 클라우드 내의 제1 노드라고 가정하고, 그 노드는 다른 노드가 나중에 가입하기를 기다릴 것이다.
PNRP 노드가 클라우드에 가입할 때마다, 노드는 다른 노드를 찾기 위해 클라우드 탐색을 수행해야 한다. 클라우드 탐색은 PNRP 구현이 그 캐쉬가 좋지 못하고, 더 많은 캐쉬 엔트리를 획득할 필요가 있다고 결정한 경우, 나중에 일어날 수도 있다. 최초 캐쉬 탐색 시도가 작동하지 않을 경우, 나중에 추가로 시도할 수 있다. 클라우드 탐색은 다음의 프로시져를 이용하여 수행된다. 먼저, 피어는 지속된 캐쉬로부터 탐색을 수행한다. 이러한 프로시져에서, 피어는 먼저 지속된 캐쉬를 점검한다. 지속된 캐쉬가 없을 경우, 피어는 이하에 설명되는 제공된 노드 어드레스를 이용하여 탐색을 시도해야 한다. 캐쉬 엔트리가 지속되어 왔을 경우, 모든 캐쉬 엔트리에 대해 피어는 아직 만료되지 않은 CPA, 다음으로 긴 수명을 지니는 CPA, 마지막으로 만료 시간이 가장 최근인 CPA 순서로 우선순위를 계산한다. 그리고 나서 피어는 선택된 노드들 중 하나가 일부 캐쉬 엔트리를 제공할 때까지 차례로 선택된 노드들과 동기화를 시도한다.
상술한 대로, 지속된 캐쉬가 없을 경우, 피어는 제공된 노드 어드레스를 이용하여 탐색을 수행하려 한다. 이 프로시져에서 피어는, 관리 구성(administrative configuration)이 접속할 일련의 피어를 지정하는지 여부를 점검한다. 그렇지 않을 경우, 피어는 이하에 설명된 멀티캐스트 탐색(multicast discovery)을 시도한다. 그렇지 않을 경우, 각 지정된 끝점에 대해 피어는 끝점 중 하나가 일부 캐쉬 엔트리를 제공할 때까지 차례로 동기화를 시도한다.
멀티캐스트 탐색의 경우, 단순 서비스 탐색 프로토콜(simple service discovery protocol, 이하 "SSDP"라고 함)이 사용가능하다면, 피어는 원하는 클라우드에서 PNRP 서비스 인스턴스에 대해 SSDP MSEARCH를 생성한다. SSDP 검색 메세지에서 사용되는 검색 대상 문자열(search target string)은 "urn:Microsoft Windows Peer Name Resolution Protocol;<메이저(major)><프로토콜(protocol)><범위(scope)>"이고, 여기서 <메이저>는 버전(version)을 나타내는 숫자이고, 프로토콜은 "IPV6"이고, 범위는 "글로벌(global)","사이트로컬(sitelocal)" 또는 "링크로컬(linklocal)" 중의 하나이다. 이 검색이 미리 발생되어 제 시간에 응답이 가능할 수도 있다. SSDP가 이용가능하지 않다면, 피어는 이러한 기타 탐색 프로토콜을 시도할 수 있다. 사용가능한 것이 아무것도 없다면, 피어는 이하에 기술된 디렉토리 네임 서버(directory name server, 이하 "DNS"라고 함)를 시도해야 할 것이다. 그러나, 응답이 수신된 경우, 응답은 시도될 노드 리스트에 놓여진다. 짧은 시간 내에 사용가능한 응답이 없다면, 노드는 다른 탐색 프로토콜을 시도하려고 한다. 시간 간격은 구현에 의해 결정될 수 있다. 피어는 선택된 노드 중 하나가 일부 캐쉬 엔트리를 제공할 때까지 차례로 선택된 노드와 동기화를 시도할 수 있다.
DNS 탐색의 경우, 피어는 시드 서버(seed server)의 잘 알려진 이름에 대해 DNS 질의를 발생시킨다. 글로벌 클라우드에 대해 이 이름은 예를 들면 SEED.PNRP.NET이 될 수 있다. 성공한 경우, 피어는 이하에 기술된 동기화를 수행한다. 그러나 이 시점까지 클라우드 탐색이 성공하지 못했을 경우, PNRP는 클라우 드 상태가 클라우드의 다른 멤버를 탐색할 수 없는 상태라고 설정하고, 이 피어를 그 클라우드의 제1 노드로 가정한다. 동기화는 이후에 다시 시도될 수 있다.
동기화는 노드로 하여금 다른 노드의 캐쉬로부터 일련의 CPA를 획득할 수 있도록 해 준다. 동기화는 클라우드 탐색 이후에 수행된다. 이것은 클라우드 탐색에 의해 리턴된 일련의 노드로부터 임의로 선택된 하나의 노드와 수행된다. 동기화는 임의의 공격을 완화하도록 보안이 되어 있다. 동기화는 또한 클라우드의 캐쉬가 시간경과(ageing)로 인해 공백이 되었을 경우에도 수행될 수 있지만, 이것은 아주 드문 경우이다. 동기화를 시작하기 전에, 노드는 적어도 하나의 로컬로 등록된 CPA를 지니고 있는지를 반드시 확인해야 한다. 만약 피어 네임이 아직 등록되지 않았다면, 노드는 스스로 클라우드에서 노드 ID를 생성한다. 동기화 과정은 본 발명의 5가지 유형의 메세지, 즉 SOLICIT, ADVERTISE, REQUEST, FLOOD, 및 ACK와 관련되어 있다.
도 3은 동기화를 위한 간단한 메세지 교환을 도시하고 있다. 이 도 3에서, 노드 A(212)가 노드 B(214)와의 동기화를 개시한다고 가정한다. 이러한 상황에서 노드간의 메세지 흐름이 도 3에 도시된 대로 나타날 것이다. 특히, SOLICIT 메세지(216)는 클라우드 탐색 동안 선택된 노드(214)에게 PNRP ID 리스트를 요청한다. 이 SOLICIT 메세지(216)는 표 1에 기술된 대로 채워진다.
SOLICIT 메세지 필드 값
nonce 해쉬 논스(hashed nonce)의 값
source CPA 로컬로 등록된 피어 네임 또는 생성된 노드 ID에 대한 CPA
이 노드는 해쉬 논스를 생성하는 데 사용되는 논스(nonce, 특정한 순간을 증명하기 위해 생성된 값을 의미함) 값을 계속 추적한다. 타이머는 이 상태 및 재시도 횟수와 관련된다. 만약 ADVERTISE 메세지(218)가 전송된 SOLICIT(216)의 응답으로 수신되지 않을 경우, SOLICIT(216)는 재전송될 것이다. 만약 재시도 횟수를 초과했을 경우, 그 상태는 해제되고 트랜잭션은 종료된다.
SOLICIT(216)를 수신한 노드(214)가 ADVERTISE 메세지(218)로 응답한다. ADVERTISE(218)는 PNRP ID 배열을 포함한다. 노드(214)는 먼저 조절하는 발견적 방법(throttling heuristics)을 적용하여 자신이 동기화 트랜잭션 수행을 원하는지 여부를 결정한다. 만약 바쁘다면, 노드(214)는 배열에 PNRP ID가 없는 ADVERTISE 메세지(218)로 응답한다. 그렇지 않다면, 노드(214)는 자신의 캐쉬에서 잘 분산된 PNRP ID 집합을 선택한다. 이것은 최상위 레벨 캐쉬 엔트리를 사용함으로써, 또는 임의의 선택으로 행해진다. 만약 캐쉬에 충분한 엔트리가 없는 경우, 노드(214)는 자신의 로컬에 등록된 ID를 또한 포함해야 한다. ADVERTISE 메세지(218)는 SOLICIT 메세지(216)의 해쉬 논스를 포함한다. ADVERTISE(218)는 SOLICIT(216)의 수신확인으로 간주된다.
PNRP ID 배열이 공백이 아닌 경우, 노드(214)는 또한 해쉬 논스값과 함께 ADVERTISE(218)를 전송한 상태를 유지한다. 이 상태는 비트맵(bitmap)의 한 비트(bit)일 수 있다. 타이머가 이 상태와 관련되어 있기 때문에, 매칭 메세지(matching message)가, 예를 들어 15초 내에 수신되지 않는다면, 트랜잭션은 중단되고 그 상태는 해제된다. 노드(214)는 또한 SOLICIT 메세지(216)의 소스 CPA 를 자신의 캐쉬에 추가한다. ADVERTISE 메세지(218)는 표 2에 나타난 대로 채워진다.
ADVERTISE 메세지 필드 값
nonce SOLICIT로부터 복사된 해쉬 논스(hashed nonce)의 값
ID array PNRP ID 리스트
노드(212)가 ADVERTISE(218)를 수신할 때, 노드는 먼저 자신이 대응하는 SOLICIT(216)를 전송했었는지를 확인한다. 만약 아니라면, 노드는 그 메세지를 버린다. ADVERTISE(218)는 SOLICIT(216)의 수신확인으로서 처리된다. ADVERTISE(218)내의 PNRP ID 배열이 공백이라면, 트랜잭션은 완료된다. 그렇지 않을 경우, 노드(212)는 ADVERTISE(218) 내의 PNRP ID 배열을 조사하고, 자신의 캐쉬에 포함하고자 하는 것들을 선택한다. 선택된 PNRP ID array를 포함하여 REQUEST 메세지(220)를 전송한다. 노드는 REQUEST 메세지(220)에 SOLICIT 메세지(216)에 대한 해쉬 논스를 생성하는데 사용되었던 최초의 논스 값을 배치한다. REQUEST 메세지(220)는 도 3에 나타난 대로 채워진다.
REQUEST 메세지 필드 값
nonce SOLICIT의 해쉬 논스를 생성하는 데 사용된 논스 값
ID array PNRP ID 리스트
REQUEST 메세지(220)는 노드 B(214)로 전송되고, 노드 B(214)는 수신했음을 나타내고 재전송을 막기 위해 ACK(222)로 응답한다. ACK(222)가 적시에 수신되지 않을 경우, 노드 A(212)는 REQUEST를 재전송할 것이다. 모든 재전송이 완료되었음 에도 불구하고 REQUEST에 대한 ACK를 수신하지 못했다면, 이 트랜잭션은 실패한 것이고 종료된다.
트랜잭션이 성공한 경우, 즉, 노드(212)가 노드(214)로부터 ACK(222)를 수신했을 경우, 노드(214)는 nonce가 유효한지 검증한다. 노드는 수신된 nonce를 해슁함으로써 이것을 수행하고, nonce가 앞서 저장된 상태와 매치하는지를 점검한다. 매치하지 않을 경우, 더 이상 처리되지 않는다. 만약 유효하다면, 아직 자신의 캐쉬내에 있는 PNRP ID 배열 각각에 대해 노드(214)는 FLOOD 메세지(2241, 2242, ... 224N)를 전송한다. 이 FLOOD 메세지(224)는 PNRP ID의 CPA를 포함한다. 여기서 주의할 것은 FLOOD 메세지들(224)이 동기식이 아니라는 것이다. FLOOD(ID=1)(2241)는 FLOOD(ID=2)(2242)가 전송되기 전에 수신확인될 필요가 없다. 피어(212)에 의해 FLOOD(224)를 수신하자마자, FLOOD 메세지(224)는 정상적으로 처리된다. 이 처리에는 ACK(226) 발송 및 CPA 유효성 검증이 포함된다.
요청 노드(soliciting node)(212)는 선택된 ID의 수가 그리 크지 않을 경우 이 프로시져의 반복을 결정할 수 있다. 이런 경우, 다른 ID 리스트를 얻기 위해, 다른 노드를 사용하여 동기화해야 한다.
노드에서 RESOLVE 메세지를 전송함으로써 레졸루션 프로세스가 개시된다. RESOLVE는 PNRP ID 등록의 일부로서, 캐쉬 유지의 일부로서 피어 이름을 어드레스로 해석하거나 또는 클라우드 분할(split)을 검출하도록 애플리케이션이 요청하기 때문에 개시될 수 있다. RESOLVE 메세지는 리졸브 처리(resolve processing)를 고 성능으로 조정하고(tune), 리졸브를 시도하는 데 있어 방문 노드 수 제한을 설정하고, ID 매칭 정확도를 관리하는 일부 플래그 및 코드를 포함한다. 이것은 희망 목표 PNRP ID를 지정한다. 각 홉에서, 지금까지 발견되었던 것 중 베스트 매치(best match) CPA 뿐만 아니라 다음 홉의 ID가 삽입된다. 게다가, 방문했던 노드 끝점의 배열이 홉에서 홉으로 RESOLVE 메세지의 경로를 추적하기 위해 포함된다. RESOLVE의 생성자(originator) 그 자신은 경로의 제1 엔트리로서 추가된다. 레졸루션 트랜잭션은 PNRP ID를 CPA로 해석한다. CPA 소유자만이 자신의 CPA에 대한 레졸루션 요청을 수행하는 권한을 지닌다. 캐쉬된 CPA는 RESOLVE 요청을 라우팅하는 힌트로서만 사용될 수 있다. 이들은 RESOLVE 또는 RESPONSE의 "베스트 매치" 필드를 설정하는 데 사용될 수 없다.
목표 PNRP ID를 호스팅하는 노드에 도달했을 때, 또는 방문했던 노드 수가 RESOLVE에 설정된 최대 홉(max hop)과 같을 때, 또는 경로 내의 모든 노드들이 RESOLVE를 더 나은 노드로 더 이상 전송할 수 없을 때에 RESOLVE 메세지는 종료된다. 종료되자마자, RESOLVE에서 새 RESPONSE 메세지로 전달된 내용을 선택하고, 이것은 RESOLVE 개시자(initiator)로 다시 전송된다. RESPONSE는 방문했던 노드 리스트 및 RESOLVE의 '베스트 매치' CPA를 포함한다. 일단 RESPONSE가 RESOLVE의 생성자에게 도달하면, 그 생성자는 '베스트 매치' CPA의 PNRP ID와 목표를 비교함으로써 목표 CPA를 발견했는지 여부를 쉽게 검증할 수 있다.
3개 노드들의 RESOLVE/RESPONSE 트랜잭션 예제가 도 4에 도시되어 있다. 이 간략한 예제에서, 노드 A(228)는 노드 B(230)를 통해 노드 T(232)를 해석하려 한 다. RESOLVE 트랜잭션에 ACK외에 3개의 메세지, 즉 RESOLVE, RESPONSE 및 AUTHORITY가 관련되어 있다. 일단 레졸루션이 완료되면, 노드 A(228)는 노드 T(232)에게 이하에 설명된 대로 INQUIRY 메세지를 직접 전송할 수 있다.
RESOLVE 메세지에 대해, 고려해 볼 3가지 경우가 있으며, 그 중 첫 2가지가 도 4에 도시되어 있다. 이 3가지 경우는 노드 A(228)에서 RESOLVE(234)를 개시하고, RESOLVE(236)를 노드 A(228)에서 다른 노드 B(230)로 전송하고, 노드로부터 RESOLVE를 다시 전송받는 것이다(도 4에서 도시 생략). 이 시나리오 각각은 차례로 설명될 것이다.
첫번째로 노드 A(228)에서 RESOLVE를 개시하는 것을 설명한다. 도 4에 도시된 대로, 노드 A(228)는 어떤 이유로 RESOLVE를 개시한다. 이러한 이유로는 애플리케이션 리졸브 요청, 등록 알림, 캐쉬 폭(breadth) 유지, 또는 클라우드 분할 검출 등이 있다. 개시자(228)는 또한 로컬로 등록된 ID로 RESOLVE를 충족시킬 수 있는지 여부를 나타내는 오퍼레이션 코드(operation code)를 지정한다. 그렇게 할 수 있는 경우, 노드 A(228)는 매치를 위해 로컬로 등록된 일련의 ID를 스캔한다. 하나가 발견될 경우, 그 매칭 ID로 노드 A(228) 그 자체 내에서 RESOLVE가 완료된다. 로컬로 등록된 ID가 받아들여지지 않을 경우, 또는 로컬 ID 중 그 어떤 것도 매치가 아닐 경우, RESOLVE 메세지(234)는 표 4에 도시된 필드로 생성된다. 그리고 나서, 이 RESOLVE 메세지(234)는 이하에 기술된 처리를 위해 어떤 다른 노드(230)로 전달된다.
target ID 원하는 ID로 설정
nexthop 캐쉬에서 선택된 PNRP ID
maxhops 상수이거나 추정된 클라우드 크기에 따라 상대적일 수 있음
bestmatch 로컬로 등록된 피어 네임에 대한 CPA
path 1개의 엔트리이고, 베스트 소스 어드레스 및 포트를 포함함
reasoncode, operationcode, precision 리졸브 개시자에 좌우되는 값
노드 A(228)가 RESOLVE(234)를 다른 노드 B(230)로 전송하고자 하거나 전송할 필요가 있을 때, 먼저 그 다음 노드를 선택해야 한다. 다음 홉을 선택하기 위해 노드 A(228)는, 그 어드레스가 경로에 이미 있는 것과 A의 가장 가까운 로컬로 등록된 ID보다 목표 ID에 가깝지 않은 것들을 제외하고, 목표 ID(노드 T(232))와 가장 가까운 PNRP ID로 3개의 캐쉬된 CPA 리스트 L을 만든다. 목표 ID가 리스트 L에 있다면, 그 엔트리는 다음 홉으로서 선택된다. 그렇지 않다면, 리스트 L이 공백이 아닌 경우, 임의로 하나의 엔트리가 선택된다. 다시 말해, 노드 A(228)는 이 노드보다 목표 노드에 더 가까운 어떤 새 노드를 찾고, 그들 중 하나를 선택하여 RESOLVE 메세지(234)를 전송한다.
노드 A(228)가 다음 홉을 선택할 수 있다면, 노드 A(228)는 '수신된 비트맵(received bitmap)'에 적절한 엔트리를 삽입한다. 노드 A(228)는 자기 자신을 경로에 추가하고, 선택된 다음 홉에 대해 베스트 어드레스를 선택하고, 그 엔트리를 받아들여짐(accepted)으로 표시한다. 노드 A(228)는 다음 홉을 선택된 목적지의 예상 PNRP ID로 설정하고, RESOLVE 메세지(234)를 노드 B(230)로 전송한다. RESOLVE 메세지(234)가 성공적으로 발송된 경우, 전송 노드(228)는 AUTHORITY 메세지(238)의 형태로 수신확인을 기대한다. AUTHORITY(238)가 수신될 경우, 노드(228)는 RESOLVE(234)의 내용을 유지하고, 리턴될 RESPONSE 메세지(240)를 타 임아웃 값까지 기다린다. AUTHORITY(238)가 일정 시간 이후에도 수신되지 않는 경우, RESOLVE(234)가 다시 전송된다. 전체 N번의 재시도 후에 다음 홉이 유효하지 않다고 가정한다. 바람직한 실시예에서, N = 3이다. 재시도 횟수를 초과한 경우, 다음 홉 CPA는 로컬 캐쉬에서 제거되고, 그 엔트리는 실패한 홉으로서 경로에 추가된다. 홉 총수(hop count)를 초과하지 않은 경우, 로컬 캐쉬에서 다른 다음 홉이 선택되고, 프로세스가 반복된다. 경로 내의 엔트리 수가 최대 홉과 같거나 초과할 경우, RESPONSE 메세지는 RESULT_MAX_HOP_LIMIT_HIT의 응답 코드로 생성되고, 경로에서 받아들여짐(accepted)으로 표시된 가장 최근의 엔트리로 전송된다.
노드가 다음 홉을 찾을 수 없을 경우, 노드는 목표 ID가 최하위 캐쉬 레벨에 있어야 하는지 여부를 점검한다. 만약 그래야 한다면, 노드는 목표 ID가 존재하지 않을 수 있다고 의심한다. 노드는 기존의 경로 엔트리를 점검하고 의심(suspicious)으로 표시된 것들의 수를 센다. 그 수가 임계치를 초과할 경우, RESPONSE 메세지는 RESULT_TOO_MANY_MISSES의 응답 코드로 생성되고, 경로에서 받아들여짐(accepted)으로 표시된 가장 최근의 엔트리로 전송된다. 노드가 다음 홉을 찾을 수 없었지만 의심 총수(suspicious count)를 초과하지 않았을 경우, 노드는 경로에서 받아들여짐(accepted)으로 표시된 마지막 노드로 다시 RESOLVE를 전송한다. 노드는 먼저 그 자신을 경로에 추가하고, 목적지 노드에 대해 베스트 어드레스를 선택하고, 그 엔트리를 거절되었음(rejected)으로 표시한다. 노드는 다음 홉을 0으로 설정하고, RF_IGNORE_NEXTHOP 플래그를 역추적(backtracking)을 나타내도록 설정한다. 목표 ID가 노드의 최하위 캐쉬 레벨에 있어야 할 경우, 노드는 목 표 ID가 존재하지 않을 수 있다고 의심한다. 이런 경우, 노드는 또한 그 경로 엔트리를 의심(suspicious)으로 표시한다. 노드가 다음 홉을 찾을 수 없고 경로 내에 (자기 자신 외에)다른 노드가 없을 경우, 노드는 RESOLVE 메세지의 생성자가 된다. 이런 경우, 노드는 호출자에게 RESULT_NO_BETTER_PATH_FOUND의 응답 코드로 해석의 실패를 나타내는 결과를 리턴한다. 베스트 매치 CPA는 호출자에게 사용가능하도록 만들어진다.
노드 B(230)는 목표 PNRP ID, 베스트 매치 CPA, 다음 홉 PNRP ID 및 RESOLVE를 처리했던 모든 노드의 어드레스를 리스트한 경로를 포함하는 RESOLVE 메세지(234)를 수신한다. 플래그 필드가 RF_IGNORE_NEXTHOP 으로 설정되어 있지 않고 베스트 매치가 가지거나 또는 공백일 경우, 노드 B(230)는 자신의 로컬 프로세싱 부하를 점검한다. 부하가 너무 높아서 새 RESOLVE 요청을 처리하지 못할 경우, 노드는 플래그 필드를 "AF_REJECT_TOO_BUSY"로 설정하여 AUTHORITY(238)로 응답하고, 프로세싱은 완료된다. AUTHORITY 수신자는 거절 노드 끝점(rejecting node endpoint)을 경로 배열에 추가하고 RESOLVE 요청을 다른 어떤 곳으로 다시 라우팅하는 것을 담당한다.
수신 노드(230)는 경로 배열이 받아들여짐(accepted)으로 표시된 어드레스를 적어도 하나 포함하는지를 점검하고, 그 최종 어드레스가 메세지의 소스의 것과 동일한지를 점검한다. 그렇지 않을 경우, 더 이상 처리되지 않는다. 수신 노드는 또한 수신된 요청의 매개변수들을 점검한다. 일부 매개변수가 유효한 영역에 있지 않을 경우, 노드는 플래그 필드를 "AF_INVALID_REQUEST"로 설정하여 AUTHORITY 메 세지로 응답하고, 프로세싱은 완료된다. 유효하지 않은 매개변수의 예로는 최대 홉이 너무 큰 경우이다. AUTHORITY 수신자는 거절 노드 끝점을 경로 배열에 추가하고 RESOLVE 요청을 다른 어떤 곳으로 다시 라우팅하는 것을 담당한다.
수신 노드(예를 들어 노드 B(230))는 다음 홉 ID가 로컬에 등록되었는지 여부를 점검한다. 시드 서버는 이 테스트를 생략할 수 있다. 이것이 실패할 경우, 노드는 플래그 필드를 "AF_UNKNOWN_ID"로 설정하여 AUTHORITY로 응답하고, 프로세싱은 완료된다. AUTHORITY 수신자는 RESOLVE 요청을 다른 어떤 곳으로 다시 라우팅하는 것을 담당한다. AUTHORITY 수신자는 또한 AF_UNKNOWN_ID를 수신했을 때 자신의 캐쉬에서 AUTHORITY 전송자의 PNRP ID를 제거해야 한다. 베스트 매치 CPA가 메세지에 포함된 경우, 노드는 가능한 한 베스트 매치의 유효성을 검사한다. CPA가 유효하지 않을 경우, 노드는 메세지에서 그 베스트 매치 CPA를 제거한다. 베스트 매치 CPA가 유효할 경우, 노드는 그 CPA를 자신의 캐쉬에 추가할 것인지 여부를 결정하기 위해 일반적인 규칙을 따른다.
노드는 또한 경로 내에 이미 자신의 엔트리가 있는지 여부를 점검한다. 이미 있다면, 이것이 역추적된 RESOLVE가 아니기 때문에 루프(loop)가 발생한다. 그리고 나서 노드는 플래그 필드를 "AF_REJECT_LOOP"로 설정하여 AUTHORITY로 응답하고, 프로세싱은 완료된다. AUTHORITY 수신자는 거절 노드 끝점을 경로 배열에 추가하고 RESOLVE 요청을 다른 어떤 곳으로 다시 라우팅하는 것을 담당한다.
이전의 모든 점검을 통과했다면, 노드 B(230)는 RESOLVE 메세지(234)의 수신확인으로 AUTHORITY(238)를 전송한다. RESOLVE 플래그 RF_SEND_CHAIN이 설정되었 다면, 다음 홉의 인증서 체인(certificated chain)이 AUTHORITY(238)에 포함되어 있다. 다음 홉 PNRP ID에 대응하는 피어 네임의 분류자 문자열 부분(classifier string portion)이 AUTHORITY 메세지에 포함되어 있다.
노드 B(230)는 현재의 베스트 매치보다 더 나은 매치인 CPA를 로컬에 등록했는지 여부를 점검한다. 등록했을 경우, 노드 B(230)는 베스트 매치를 이것으로 대체한다. 노드는 또한 동작 코드, 정밀도, 및 목표 ID에 기초하여 RESOLVE 기준(criteria)을 충족시키는 CPA를 로컬에 등록했는지 여부를 점검한다. 만약 노드 B가 매치를 지니고 있다면, 또는 경로 내의 엔트리 수 >= 최대 홉이라면, 노드는 현재의 베스트 매치로 RESPONSE 메세지를 생성한다. RESOLVE 메세지의 경로가 RESPONSE 메세지의 경로로 복사된다. 노드는 응답 코드를 RESULT_FOUND_MATCH 또는 RESULT_MAX_HOP_LIMIT_HIT 중 하나를 나타내도록 설정한다. 그리고 나서 노드는 그 어드레스 뿐 아니라 거절되었음(rejected)으로 표시된 이후의 엔트리를 경로에서 제거하고, 경로에서 가장 최근에 받아들여짐(accepted)으로 표시된 엔트리로 RESPONSE를 전송한다.
노드 B(230)가 RESPONSE를 전송하지 않았다면(도 4에 도시된 대로), 노드 B는 RESOLVE 메세지(236)를 다음 노드 T(232)로 전송하려 할 것이다. 이 전송은 상술된 프로시져를 따른다. 즉, 노드 T(232)는 처음에 AUTHORITY 메세지(242)로 응답한다. 그리고 나서 상술된 점검을 수행하고, 그것이 목표와 매치하는지 결정하고, 노드 B(230)에게 자신을 베스트 매치로 하여 RESOPONSE 메세지(244)로 응답한다. RESPONSE 메세지(244)에 응답하여, 노드 B(230)는 ACK 메세지(246)를 다시 전 송한다. 그리고 나서 노드 B(230)는 경로를 점검하고 RESPONSE 메세지(240)를 노드 A(228)로 전송하고, 노드 A는 ACK 메세지(248)로 응답한다.
상술한 바와 같이, 노드는 또한 역추적된 RESOLVE를 처리할 수 있어야 한다. 노드가 RESOLVE 메세지 R을 수신했을 때, 그 메세지에는 목표 ID PNRP ID, 베스트 매치 CPA, 다음 홉 PNRP ID, 및 지금까지 RESOLVE를 처리해 왔던 모든 노드의 어드레스를 리스트한 경로가 포함되어 있다. 역추적된 RESOLVE에 대해, 플래그 필드는 RF_IGNORE_NEXTHOP으로 설정되어 있다. 노드는 먼저 자신의 '수신된 비트맵(received bitmap)'을 점검하여 자신이 이전에 이 RESOLVE를 전송했었는지를 검증한다. 비트가 설정되어 있지 않다면, 메세지는 버려진다. 그리고 나서 노드는 자신의 어드레스가 경로에 있는지 및 경로 내에 받아들여짐(accepted)로 표시된 최상위의 엔트리인지 여부를 확인하기 위해 경로를 점검한다. 그렇지 않다면, 메세지는 버려진다. 메세지가 버려지지 않는다면, 노드는 AUTHORITY를 전송자로 다시 전송하여 메세지를 ACK한다. 여기에는 인증서 체인이 포함되지 않는다.
경로 내의 엔트리 수 >= 최대 홉일 경우, 노드는 현재의 베스트 매치로 RESPONSE 메세지 S를 생성한다. RESOLVE 메세지 R의 경로가 S의 경로로 복사된다. 노드는 응답 코드가 최대 홉을 초과하였음을 나타내도록 설정한다. 그리고 나서 노드는 경로에서 자신의 어드레스를 제거하고, 경로에서 받아들여짐(accepted)으로 표시된 가장 최근의 엔트리로 RESPONSE를 다시 전송한다. 노드가 RESPONSE를 전송하지 않았다면, 노드는 다음 홉으로 RESOLVE를 전송하려 할 것이다. 이것은 일부 예외사항을 제외하고는 상술된 프로시져를 따른다: a) "노드 B(230)는 현재의 베스 트 매치보다 더 나은 매치인 CPA를 로컬에 등록했는지 여부를 점검한다. 등록했을 경우, 노드 B(230)는 베스트 매치를 이것으로 대체한다." 는 적용되지 않음; b) 현재의 노드가 RESOLVE 트랜잭션의 생성자(originator)이고, 그 이유가 REASON_REPAIR_DETECTION이라면, 프로세싱은 완료된다.
간단히 상술한 바와 같이, 노드가 RESPONSE 메세지(244,240)를 수신할 때, 그 메세지에는 목표 ID PNRP ID, 베스트 매치 CPA, 및 지금까지 RESOLVE를 처리해 왔던 모든 노드의 어드레스를 리스트한 경로가 포함되어 있다. 수신 노드는 또한 자신의 '수신된 비트맵(received bitmap)'을 점검하여 이 RESPONSE 메세지(240,244)에 매치하는 RESOLVE(234,236)를 이전에 전송했었는지를 검증한다. 비트가 설정되어 있지 않다면, 메세지는 버려진다. 수신 노드는 또한 자신의 어드레스가 경로에서 마지막(가장 최근)인지 및 받아들여짐(accepted)로 표시되었는지 여부를 확인하기 위해 경로를 점검한다. 그렇지 않다면, 메세지는 버려진다. 메세지가 버려지지 않는다면, 이 수신 노드는 ACK(246,248)를 전송하여 수신을 알린다. 노드는 가능한 한 베스트 매치 CPA의 유효성을 검사하고, 그것을 자신의 캐쉬에 추가한다. CPA를 캐쉬에 추가하는 것은 추가 메세지 교환을 필요로 하는 일련의 규칙에 따르고, 따라서 P는 베스트 매치 CPA의 유효성을 검사할 수 있다. 이것은 상술된 출원에 기술되어 있다.
그리고 나서 노드는 자신을 경로에서 삭제한다. 노드는 또한 받아들여짐(accepted)으로 표시된 엔트리를 만나기까지 또는 리스트가 비워질때까지, 거절되었음(rejected)으로 표시된 이전의 엔트리를 삭제한다. 받아들여짐(accepted)으로 표시된 엔트리가 발견되면, 노드는 이 노드로 RESPONSE를 전송한다. RESPONSE를 전송했던 노드가 ACK 응답을 받지 못하면, 그 노드는 최대 N번까지 RESPONSE를 재전송한다. 재전송이 타임아웃되면, 노드는 경로에서 실패한 목적지 노드를 제거하고, 이 문단에 설명된 RESPONSE 프로세싱을 재시도한다. 경로에 더 이상 엔트리가 없을 경우, 노드는 최초 RESOLVE 메세지(234)의 생성자가 된다. 노드(228)는 자신이 요청을 시작했다는 것에 대해 유효성을 검사한다. 그렇지 않다면, RESPONSE는 버려진다. 응답 코드가 성공을 나타내면, 노드(228)는 베스트 매치 CPA의 소스에 대해 아이덴티티 유효성 검사를 실시한다. 이것은 INQUIRE 메세지(250)를 목표 노드(232)로 전송하고, 리턴된 AUTHORITY 메세지(252)를 검증하는 것을 포함한다. 아이덴티티 유효성 검사가 실패하면, 노드는 응답 코드를 IDENTITY_FAILURE로 변경한다. 노드는 호출자에게 결과를 다시 리턴한다.
AUTHORITY 메세지는 전송자에 의해 조각으로 나뉘어질 수 있다. AUTHORITY 메세지를 처리하기 전 모든 조각이 수신되도록 하는 것은 수신자에게 달려 있다. 적절한 시간 내에 조각이 하나도 수신되지 않았다면, 그리고 재시도 횟수를 초과하지 않았다면, 최초의 메세지(INQUIRE 또는 RESOLVE)는 재전송되어야 한다. AUTHORITY 메세지 플래그가 AF_CERT_CHAIN으로 설정되어 있다면, 노드는 Validate ID에 지정된 PNRP ID에 대해 캐쉬된 CPA 에서 체인 유효성 검사 동작(chain validation operation)을 수행해야 한다. 체인은 그 내의 모든 인증서가 유효하고, 체인의 루트와 종단(leaf)간의 관계가 유효하도록 점검되어야 한다. 체인 루트의 공용 키의 해쉬와 CPA의 피어 네임에 있는 권한이 매치되도록 이 둘을 비교해 야 한다. 체인 종단의 공용 키와 CPA를 서명하는데 사용되었던 키가 매치되도록 이들을 비교해야 한다. 마지막으로, P2P ID를 생성하는 규칙에 따라, P2P ID가 권한(authority) 및 분류자(clssifier)의 해쉬인지 점검되어야 한다. 상술된 점검 중 하나라도 실패하면, CPA는 캐쉬에서 제거되고, RESOLVE 메세지는 AUTHORITY 메세지를 전송했던 노드의 어드레스를 RESOLVE 메세지의 경로에 추가하고 그 엔트리를 거절되었음(rejected)으로 표시함으로써 변경되어야 한다.
AF_UNKNOWN_ID가 설정되었다면, CPA는 캐쉬에서 제거되어야 한다. AF_CERT_CHAIN이 설정되지 않았다면, 그러나 Validate ID PNRP ID에 대응하는 CPA 가 유효성 검사를 할 인증서 체인을 필요로 한다면, CPA는 캐쉬에서 제거되어야 하고, RESOLVE 메세지는 AUTHORITY 메세지를 전송했던 노드의 어드레스를 RESOLVE 메세지 경로에 추가하고 그 엔트리를 거절되었음(rejected)으로 표시함으로써 변경되어야 한다.
Validate ID PNRP ID에 대응하는 CPA의 유효성 검사가 완료되었다면, 이것은 유효성 검사 완료됨(fully validated)으로 표시되어야 한다. 구분자 문자열이 AUTHORITY 메세지에서 추출되어, CPA와 함께 보존된다. AF_REJECT_TOO_BUSY, AF_UNKNOWN_ID, AF_REJECT_LOOP 및 AF_INVALID_REQUEST 모두가 클리어(clear)되었다면, RESOLVE는 처리되기 위해 받아들여졌고, AUTHORITY 프로세싱은 완료되었다.
일부 경우에서 RESOLVE 메세지를 수신한 노드가 전송을 위해 그것을 받아들이지 않을 수 있지만, 여전히 전송 노드에게 다음 홉을 제안한다. 이 경우, 노드는 AUTHORITY 메세지에 제안된 추천 끝점(referral endpoint) 및 추천 PNRP ID(referral PNRP ID)를 리턴한다. 이 경우, AUTHORITY 플래그 값은 AF_REDIRECT를 포함해야만 한다. AF_REDIRECT로 AUTHORITY를 수신하는 노드는 추천 끝점을 RESOLVE 메세지를 전송하는 데 사용할 지 여부를 선택할 수 있다. 둘 중 어떤 경우에서든지, AUTHORITY에 응답하는 노드는 경로에 추가된다. 노드가 추천 끝점을 사용해야만 하는 유일한 경우는, RESOLVE 메세지를 시작한 노드가 클라우드 분할을 검출하기 위해 그것을 하고 있고, REASON_REPAIR라는 이유로 RESOLVE를 PNRP 시드 서버로 이미 전송했을 때이다. 다른 경우, 노드는 추천 끝점을 무시해야 한다.
PNRP는 노드간에 CPA 캐쉬 엔트리를 전파시키기 위해 규제된 플러딩(directed flooding)을 사용한다. 플러딩은 여러 경우에 사용된다. REQUEST 메세지에 응답하여 동기화하는 동안, 요청된 CPA가 REQUEST를 전송한 피어에게 플러드된다. REQUEST 메세지는 SOLICIT 메세지가 받아들여지고 ADVERTISE 메세지가 전송된 이후에만 받아들여진다. CPA가 캐쉬의 최하위 레벨에 추가될 때마다, 추가된 CPA는 로컬로 등록된 ID에 가장 가까운 n개의 피어로 플러드된다. n 값은 조정될 수 있고, 그 값은 4가 바람직하다. CPA를 추가하는 이유가 FLOOD를 수신했기 때문이라면, CPA는 수신된 FLOOD의 플러드된 리스트에 어드레스가 있는 노드로 플러드되어서는 안 된다. 수신된 플러드된 리스트 내의 어드레스는 충분한 공간이 있다면 새 FLOOD 메세지의 플러드된 리스트로 복사되어야 한다. CPA 취소를 포함하는 FLOOD를 수신했을 때 캐쉬의 최하위 레벨에서 CPA가 제거될 때마다, 취소된 CPA는 로컬로 등록된 ID에 가장 가까운 n개의 피어로 플러드된다. 다시 한 번, n 값은 조정될 수 있지만, 그 값은 4가 바람직하다. CPA는 수신된 FLOOD의 플러드 된 리스트에 어드레스가 있는 노드로 플러드되어서는 안 된다. 수신된 플러드된 리스트의 어드레스는 충분한 공간이 있다면 새 FLOOD 메세지의 플러드된 리스트로 복사되어야 한다. 마침내, 새 피어에 대해 FLOOD가 수신되었을 때, CPA가 캐쉬의 최하위 레벨에 추가되고, 이후 FLOOD 메세지는 로컬 노드 ID와 함께 새 피어로 전송된다. FLOOD의 소스가 새 피어라면 예외가 있다.
PNRP는 지속적인 이웃 관계를 생성하지 않는다. 막연하게, CPA 캐쉬에서 CAP에 의해 나타나는 모든 노드는 이웃 노드로 간주될 수 있다. 그러나, CPA들은 CPA 생성자에게 반드시 통보할 필요 없이 캐쉬에 추가되어나 캐쉬에서 제거될 수 있다. 노드의 캐쉬에 피어의 CPA를 보유한다고 해서 그 이웃 노드가 자신의 캐쉬에 그 노드의 CPA를 보유한다는 것을 보증하지는 않는다. 그 관계는 비대칭적(asymmetric)이다. 그러나, 상술된 최종 FLOOD 조건은 서로 가까운 ID들에 대해 대칭성을 생성하려 노력한다.
모든 UDP FLOOD 메세지는 그 메세지에 대해 다른 액션을 취하기 이전에 ACK로 수신확인된다. FLOOD의 전송자는 얼마동안 FLOOD가 전송되었다는 상태를 유지한다. ACK이 수신되면, 그 상태는 해제된다. 일정 시간동안 ACK가 수신되지 않는다면, FLOOD는 재전송되고, 타이머는 다시 설정된다. FLOOD는 주어진 횟수 만큼 재시도되고, 그 횟수는 바람직하게는 3이다. 마지막 재시도 이후에도 ACK가 수신되지 않는다면, 상태는 해제된다. 게다가, FLOOD의 목적지가 전송자의 캐쉬내에 있다면, 앞으로 반응이 늦은 노드로 메세지를 전송하는 것을 피하기 위해 캐쉬 엔트리가 제거된다.
노드가 FLOOD 메세지를 수신하면, 먼저 ACK를 전송하여 FLOOD 메세지의 수신확인을 함으로써 처리된다. Validate ID가 있었고 로컬로 등록되지 않았다면, 플래그 필드는 "KF_NACK"으로 설정된다. 다음, FLOOD 메세지의 유효성이 검사된다. 여기에는 CPA 서명 및 내용의 로컬 검증이 포함된다. CPA의 유효성이 검사되면, CPA가 캐쉬에 추가될 것인지의 여부가 결정된다. CPA가 동일한 노드에 로컬로 등록된 PNRP ID에 대한 것이라면, CPA를 캐쉬에 추가할 필요가 없다. CPA를 서명하는 데에 사용된 아이덴티티가 CPA 하나만으로 검증될 수 없다면, CPA는 캐쉬 뷰의 2개의 최하위 레벨 중 하나에 추가되어 이하에 설명된 대로 아이덴티티 유효성 검사를 수행해야 한다. 유효성 검사가 실패하면, 노드는 FLOOD 메세지를 버린다. 성공한다면, 노드는 계속해서 FLOOD를 처리한다. CPA가 이미 만기가 되었다면, 노드는 FLOOD를 버린다. CPA가 취소 CPA라면, 노드는 대응하는 CPA가 캐쉬에 있을 경우 캐쉬에서 그 CPA를 제거한다. 하나가 발견되었다면, FLOOD 메세지를 전송함으로써 그 취소를 다른 이웃 노드들로 전달한다.
CPA가 취소 CPA가 아니라면, 노드는 캐쉬를 갱신한다. 매칭 CPA가 이미 캐쉬내에 있다면, 노드는 새 CPA 데이터로 캐쉬 엔트리를 갱신한다. 이것이 새 엔트리라면, 노드는 새 엔트리를 생성하고 그것을 캐쉬에 추가하려 한다. 공간을 확보하기 위해 다른 엔트리가 제거되어야 한다면, 이 엔트리는 추가되지 않을 수도 있지만, 그러나 기존의 엔트리가 새 엔트리보다 신뢰도가 더 높거나 또는 더 나은 근접 매트릭스(approximity matrics)이기 때문에 선호된다. 그 엔트리가 최하위 캐쉬 레벨에 속할 경우, 그것은 추가되어야만 한다. CPA가 최하위 캐쉬 레벨에 속할 경우, 비록 그것이 캐쉬에 추가되지 못했다 하더라도, 그것은 일부 이웃 노드들로 전송되어야만 한다. FLOOD가 동기화동안 수신되었다면, 모든 탐색된 CPA가 이미 다른 노드들에게 알려져 있다고 가정되므로, FLOOD 메세지의 전송이 억제된다. FLOOD가 전송될 필요가 있다면, 로컬로 등록된 ID에 가장 가까운 일련의 n개의 PNRP ID가 선택된다. FLOOD 메세지는 새 CPA 및 n개의 이웃 노드 뿐만 아니라 수신된 FLOOD 메세지에 있는 수신된 플러드된 리스트의 내용을 포함하는 플러드된 리스트와 함께 이들 각각으로 전송된다.
아이덴티티 유효성 검사(identity validation)는 CPA의 유효성을 검사하는데 사용되는 위협 완화 장치(threat mitigation device)이다. 여기에는 2가지 목적이 있다. 첫번째로, 아이덴티티 유효성 검사는 CPA에 지정된 PNRP 노드가 로컬로 등록된 그 CPA로부터 PNRP ID를 갖도록 해 준다. 두번째로, 안전한 PNRP ID를 위해, 아이덴티티 유효성 검사는 CPA가 PNRP ID 내의 권한에 대해 암호로 증명할 수 있는 관계에 있는 키로 서명되도록 한다. 아이덴티티 유효성 검사가 어떻게 이 두 목적을 달성하는지에 대한 상세사항이 앞서 기술된 보류중인 특허에 나타나 있다.
아이덴티티 유효성 검사(identity validation check)는 2가지 다른 경우에 발생한다. 첫번째로, 아이덴티티 유효성 검사는 CPA를 2개의 최하위 캐쉬 레벨에 추가할 때 발생한다. 2가지 최하위 캐쉬 레벨에서의 CPA 유효성은 PNRP ID를 해석하는 PNRP 기능에 결정적이다. CPA를 이 2가지 레벨 중 하나에 추가하기 전에 아이덴티티 유효성 검사를 수행하는 것은 몇몇 공격을 완화시킨다. 이 경우, CPA는 AUTHORITY 메세지를 기다리면서 예를 들어, 30초 정도까지 리스트에서 보류될 것이 다. 두번째로, 아이덴티티 유효성 검사는 RESOLVE 동안 기회주의적으로 발생한다. PNRP 캐쉬는 회전율(rate of turnover)이 높다. 그 결과, 대부분의 캐쉬 엔트리가 사용되기 전에 캐쉬에서 겹쳐 써진다. PNRP는 CPA가 실제로 사용된 이후에 대부분의 CPA의 유효성을 검사한다. CPA가 RESOLVE 경로를 라우팅하는 데 사용될 때, PNRP는 RESOLVE 메세지의 최상단(top)에서 아이덴티티 유효성 검사를 피기백 방식으로 수송한다(piggyback). RESOLVE는 INQUIRE 메세지의 '목표 ID'와 동일하게 간주되는 '다음 홉' ID를 포함한다. RESOLVE는 AUTHORITY 메세지로 수신확인되고, INQUIRE에 대해 동일한 것이 예상된다. 기회주의적인 아이덴티티 유효성 검사가 실패하면, RESOLVE의 수신자는 전송자가 생각하는 수신자가 아니다. 그 결과, RESOLVE는 다른 어떤 곳으로 라우팅되고, 유효하지 않은 CPA는 캐쉬에서 제거된다.
이 유효성 검사를 도시하기 위해, P가 PNRP ID 'T'에 대해 아이덴티티 유효성 검사를 요청한 노드이고, N은 아이덴티티 유효성 검사 요청을 수신하는 노드라고 가정한다. P는 목표 ID = T라는 INQUIRE 메세지 또는 다음 홉 = T(및 RF_IGNORE_NEXTHOP은 설정되지 않음)라고 하는 RESOLVE 메세지 둘 중 하나를 생성한다. N은 로컬로 등록된 PNRP ID's의 리스트를 점검한다. T가 그 리스트에 없다면, N은 ID T가 로컬로 등록되지 않았음을 나타내는 AUTHORITY 메세지로 응답한다. 수신된 메세지가 RESOLVE였다면, P가 RESOLVE를 다른 어떤 곳으로 전송할 것이므로 그 RESOLVE는 폐기된다. T가 N의 PNRP ID 리스트에 있다면, N은 AUTHORITY 메세지를 구성하고, 목표 ID를 T로 설정한다. RF_SEND_CHAIN 플래그가 설정되었다면, N은 PNRP ID T의 권한에 대해 CPA를 서명하는데 사용되는 키와 관련된 (만약 있다 면)인증서 체인을 검색한다. 인증서 체인은 AUTHORITY 메세지에 삽입된다. 피어 네임의 분류자 부분 또한 AUTHORITY 메세지에 추가된다.
N이 P로 AUTHORITY 메세지를 전송한다. AUTHORITY 메세지가 1216 바이트보다 길다면, 메세지는 1216 바이트 또는 이보다 작은 여러 조각(fragment)으로 분할되고, 각 조각이 전송된다. T가 안전이 보장되지 않은 ID라면, 또는 CPA의 유효성이 이미 검사되었다면(RF_SEND_CHAIN을 클리어하여 RESOLVE를 전송했다면), 프로세싱은 완료된다. P는 CPA 서명 키(signing key)와 PNRP ID T를 생성하는 데 사용된 권한 간의 관계의 유효성을 검사한다. 유효성 검사가 실패하면, CPA는 폐기된다. 유효성 검사가 실패하고 개시 메세지가 RESOLVE였다면, P는 RESOLVE를 다른 어떤 곳으로 전송한다.
위에서 기술된 출원에서 설명된 대로 및 간단히 상술된 대로, PNRP 클라우드를 분할하는 것은 가능하다. 이것은 2가지 방식으로 일어난다. 첫번째로, 클라우드는 별도로 시작할 수 있고, 병합될 필요가 있다. 두번째, 클라우드는 하나로서 시작하지만, 클라우드의 일부 조각들이 클라우드의 나머지로부터 고립된다. 모든 가능한 분할을 연결하기 위해, 클라우드는 지정된 시드 서버를 보유한다고 가정한다. 이것은 DNS를 통해 부트스트랩(bootstrap)하는데 사용되었던 것과 동일한 서버이다. 클라우드에 다수의 시드 서버가 있다면, 시드 서버들은 반드시 정기적으로 서로 통신하여 캐쉬에 있는 ID를 교환해야 한다. 이것은 동기화 프로세스를 이용하여 수행될 수 있다. 이로서 섬(island)의 생성을 막을 수 있다.
클라우드 내의 노드들은 주기적으로 시드 서버를 폴링하여 노드가 주 클라우 드에서 고립되었는지 여부를 테스트하고, 필요하다면 다시 병합을 시도한다. 노드가 분할을 테스트하는 빈도는 클라우드 크기의 추정에 반비례한다. 이것은 분할 테스트가 너무 빈번히 발생하는 것을 방지한다. 최근에 클라우드에 가입한 노드는 클라우드 크기를 추정할 수 있다고 가정하기 전에 캐쉬가 활성화 될 수 있도록 어느 정도 기다려야 한다.
클라우드 병합이 가능하도록 하기 위해, PNRP REPAIR 메세지를 사용한다. REPAIR는 PNRP ID, 노드의 IP 어드레스, 및 복구 레벨 번호(repair leve number)를 보유한다. 캐쉬 레벨은 0이 최상위 수준이 되도록 숫자가 매겨지고(가장 넓은 숫자 영역), 각 이어지는 레벨(더 작은 영역)은 1씩 높아진다. 분할이 맨 처음 검출되면, 복구 레벨 값을 0으로 초기화한다. 노드가 분할 코드(split code)에 대해 테스트를 수행해야 한다고 결정하면, 노드는 IP 어드레스로서 알려진 시드 서버의 어드레스, 로컬로 등록된 PNRP ID, 및 레벨 0을 사용하여 내부적으로 REPAIR를 생성한다. 노드는 이 REPAIR 그 자체를 처리한다.
REPAIR가 처리될 때, 노드는 분할을 테스트한다. 노드는 먼저 REPAIR 메세지의 ID에 가장 가깝고 로컬로 등록된 ID를 찾는다. 그리고 나서 노드는 이 ID+1의 RESOLVE를 REPAIR 메세지에 지정된 IP 어드레스로 전송한다. 이 RESOLVE는 복구(repairing)의 이유 코드(reason code)를 포함해야 한다. 이것이 알려진 노드에 대해 해석한다면, 분할은 없다. 이것이 새 노드에 대해 해석한다면, 분할이 있을 수 있다. 탐색된 새 노드가 가장 아래의 캐쉬 레벨(가장 높은 수)이라면, 플러딩이 평소와 같이 수행된다. 복구의 이유 코드는 FLOOD 메세지에 설정된다. 게다 가, RESOLVE를 수신한 노드가 소스 ID를 최하위 캐쉬 레벨에 둔다면, 노드는 엔트리를 소스로 플러드할 것이다. 이 모든 플러딩으로 인해 새 클라우드와 함께 몇몇 ID의 교환이 발생한다. 플러딩을 통해 탐색된 모든 새 노드들은 이런 방식으로 계속 추적된다.
탐색된 새 노드가 이전에 알려진 노드보다 더 가깝고, 수신된 복구 레벨에 캐쉬 엔트리가 있다면, 노드는 복구 레벨의 캐쉬 내 엔트리로 REPAIR 메세지를 전송한다. 전송된 각각의 REPAIR에 대해, 노드는 새로이 탐색된 노드 ID 및 IP 어드레스 하나를 선택하고, 복구 레벨 + 1에서 전달한다. 탐색된 새 노드가 이전에 알려진 노드보다 더 멀다면, 노드는 새 노드로 REPAIR를 전송하고, 로컬 캐쉬에서 일부 ID 및 어드레스, 및 수신된 복구 레벨에서 전달한다. REPAIR 메세지를 수신한 각각의 노드는 동일한 방식으로 처리한다.
PNRP 프로토콜이 10가지 메세지 유형으로 구성된다는 것은 명백하다. 각 메세지는 PNRP 헤더로 시작되고, 그 메세지 유형의 고유 필드가 이어진다. (필드 설명과 같은) 오버헤드(overhead)는 각 메세지 필드 테이블의 '길이(length)' 열에서 별도로 계산된다. 이하의 설명에서, 이들 모든 메세지가 공유하는 일반적인 메세지 데이터 구조가 설명되고, 이어서 본 발명의 프로토콜에 포함된 10가지 메세지 각각의 메세지 데이터 구조에 대한 상세한 설명이 이어진다. 이하의 설명에서, 본 발명의 메세지를 구성하는 데 사용되는 필드 데이터 구조 각각에 대한 설명이 제공될 것이다.
도 5에 본 발명의 10가지 PNRP 메세지를 구성하는 데 사용되는 기본 메세지 데이터 구조(260)를 도시한 예시적인 데이터 구조도가 도시되어 있다. 보여지는 바와 같이, 메세지 데이터 구조(260)는 다수의 필드(2621-N)로 구성된다. 바람직한 실시예에서, 제1 필드(2621)는 PNRP 헤더용으로 예약된다. 메세지(260)를 구성하는데 사용되는 개별 필드(2621-N) 각각에 대한 필드 데이터 구조(264)는 유형 컴포넌트(type component)(266), 길이 컴포넌트(length component)(268), 및 필드 데이터 구조(264)의 실제 내용 또는 유료 부하(payload)(270)를 포함한다. 길이 컴포넌트(268)는 전체 필드(264)의 길이(272)로서 계산된다. 이런 방식으로, 프로토콜은 완벽하게 확장 가능하다.
본 발명의 데이터 구조에 따라, RESOLVE 메세지가 구성된다. 도 6의 간략한 데이터 구조도에서 보여지듯이, RESOLVE 메세지(280)는 다수의 필드(282-292)로 구성된다. 또한 본 발명의 필드 데이터 구조에 따라, 각종 필드가 구성된다. 예를 들어, PNRP_HEADER 필드(282)는 필드 데이터 구조(294)를 포함한다. 이 데이터 구조(294)의 컴포넌트로는 유형(필드 ID 296), 길이(298)가 있다. 이 PNRP_HEADER 데이터 구조(294)의 내용으로는 프로토콜 컴포넌트(300), 메이저 버전 컴포넌트(major version component)(302), 마이너 버전 컴포넌트(minor version component)(304), 메세지 유형 컴포넌트(306), 및 메세지 ID 컴포넌트(308)가 있다. 유사하게, VALIDATE_PNRP_ID 필드(288)는 필드 데이터 구조(310)를 포함한다. 다른 모든 필드 데이터 구조와 마찬가지로, VALIDATE_PNRP_ID 데이터 구조(310)도 유형 컴포넌트(필드 ID 312) 및 길이 컴포넌트(314)로 시작된다. 이 필드 데이터 구조의 내용은 P2P ID 컴포넌트(316) 및 서비스 위치 컴포넌트(318)를 포함한다. 다른 필드 각각은 도 5에 도시된 대로 유사한 방식으로 구성되고, 각각에 대해 이하에 기술된다.
지금까지 명백하고 이하에 도시되듯이, 이 RESOLVE 메세지는 해석할 target PNRP ID, RESOLVE 생성자의 CPA, 'best match'의 CPA, 및 RESOLVE를 처리했던 노드 리스트를 포함한다. RESOLVE는 'flags' 필드를 포함한다. resolve_controls 필드의 플래그 서브필드에 2개의 플래그, 즉 RF_SEND_CHAIN(0x0001이고, 수신자에게 AUTHORITY 응답에 (만약 있다면) 인증서 체인을 전송할 것을 요청함) 및 RF_IGNORE_NEXTHOP(0x0004이고, RESOLVE 경로를 역추적하는 데 사용됨)이 정의되어 있다. 노드가 역추적의 일부로서 RESOLVE를 수신한다면, 전송자는 이 노드의 PNRP ID를 모른다. 'next hop' 필드는 0으로 설정되고, RF_IGNORE_NEXTHOP은 AUTHORITY가 RESOLVE에 대한 '수신확인'으로서만 사용될 것이라는 것을 나타내도록 설정된다. 상술된 바와 같이, RESOLVE 수신은 AUTHORITY 메세지로 수신확인된다. 본 발명의 바람직한 실시예에서 헤더의 메세지 유형은 5로 설정된다. 본 발명의 내용에 따라 구성된 RESOLVE 메세지의 상세한 데이터 구조가 표 5에 나타나 있다.
오프셋 길이 유형 이름 설명
0 4+8 PNRP_HEADER header 헤더
12 4+12 RESOLVE_CONTROLS controls 플래그들이며,
RESOLVE 요청을 허용하는 유일한 홉들, 해석을 제어하는 opcode 및 매치의 정밀도. 또한 해석의 이유.
28 4+32 TARGET_PNRP_ID target 해석할 PNRP_ID
64 4+32 VALIDATE_PNRP_ID nexthop 예상 다음 홉 PNRP ID
100 4+P CPA_BEST_MATCH best match CPA 지금까지 목표에 가장 가까운 PNRP ID를 지닌 노드의 CPA
104+P 4+8+A*20 IPV6_ENDPOINT_ARRAY flagged path RESOLVE를 처리했던 노드의 배열
116+P+A*20
이 표 5에서, P는 암호화된 CPA의 바이트 길이이고, 가장 근접한 DWORD 경계에서 반올림되었다. A는 플래그된 배열 내의 엔트리 수이다. 이것은 최대 홉(max hop) 값을 초과해서는 안 된다.
RESPONSE는 RESOLVE가 target PNRP ID를 소유하고 있는 노드에 도달했을 때, 또는 flagged path의 크기가 RESOLVE 최대 홉과 같을 때 생성된다. RESPONSE가 생성될 때, 대응하는 RESOLVE의 flagged path 내의 모든 엔트리가 RESOPONSE 경로로 복사된다. RESPONSE 메세지는 적절한 네트워크 끝점 각각이 RESPONSE를 처리할 때까지, 및 그것이 RESOLVE 생성자에게로 리턴될 때까지, 아래에서 위로, 경로에서 '받아들임(accept)'으로 표시된 모든 어드레스를 통해 라우팅된다. 상술된 바와 같이, RESOPONSE 수신은 ACK 메세지로 수신확인된다. 바람직한 실시예에서, 헤더의 메세지 유형은 6으로 설정된다. 본 발명의 내용에 따라 구성된 RESPONSE 메세지의 상세한 데이터 구조가 표 6에 나타나 있다.
오프셋 길이 유형 이름 설명
0 4+8 PNRP_HEADER header 헤더
12 4+12 RESOLVE_CONTROLS controls 최초 RESOLVE의 이유 및 RESPONSE 유형
28 4+32 TARGET_PNRP_ID target 해석이 요청된 PNRP ID
64 4+P CPA_BEST_MATCH best match cpa 목표에 가장 가까운 CPA
68+P 4+8+B*20 IPV6_ENDPOINT_ARRAY flagged path 현재 노드 이전에 RESOLVE를 처리했던 노드들의 배열
80+P+B*20
이 표 6에서, P는 암호화된 소스 CPA의 바이트 길이이고, 가장 근접한 DWORD 경계에서 반올림되었다. B는 끝점 배열에 있는 엔트리의 수이다.
SOLICIT 메세지는 수신자에게 자신의 캐쉬에 있는 일부 엔트리를 전송자에게 알리도록 요청한다. 전송자는 수신자 자신의 캐쉬에 추가할 수 있는 CPA를 포함한다. hashed nonce는 ADVERTISE 메세지에 반드시 리턴되어야 한다. SOLICIT 수신은 ADVERTISE 메세지로 수신확인된다. 바람직한 실시예에서, 헤더의 메세지 유형은 1로 설정된다. 본 발명의 내용에 따라 구성된 SOLICIT 메세지의 상세한 데이터 구조가 표 7에 나타나 있다. 이 표 7에서, P는 암호화된 소스 CPA의 바이트 길이이고, 가장 근접한 DWORD 경계에서 반올림되었다.
오프셋 길이 유형 이름 설명
0 4+8 PNRP_HEADER header 헤더
12 4+P CPA_SOURCE source cpa SOLICIT 생성자의 CPA
16+P 4+4 HASHED_NONCE hashed nonce 해쉬된 논스
24+P
ADVERTISE 메세지는 SOLICIT 메세지에 응답하여 생성된다. ADVERTISE는 광 고자(advertiser)의 캐쉬에서 일부 PNRP ID를 리스트한다. 이것은 ADVERTISE 수신자가 자신의 캐쉬를 활성화할(populate) CPA를 선택적으로 요청할 수 있게 해 준다. ADVERTISE 수신은 SOLICIT의 수신확인으로서 행해진다. ADVERTISE에 대한 수신확인은 생성되지 않는다. SOLICIT의 수신확인으로서 행해지지 않는 모든 ADVERTISE는 조용히 폐기된다. hashed nonce 값은 SOLOCIT 메세지내의 수신된 것과 반드시 동일해야 한다. ADVERTISE를 수신한 노드는 hashed nonce가 유효한지에 대해 반드시 유효성 검사를 할 수 있어야 한다. 바람직한 실시예에서, 헤더의 메세지 유형은 2로 설정된다. 본 발명의 내용에 따라 구성된 ADVERTISE 메세지의 상세한 데이터 구조가 표 8에 나타나 있다. 이 표에서, A는 ID 배열 내의 엔트리 수이다.
오프셋 길이 유형 이름 설명
0 4+8 PNRP_HEADER header 헤더
12 4+4 PNRP_HEADER_ACKED ackd header 암시적으로 ACK된 SOLOCIT의 헤더
20 4+8+A*32 PNRP_ID_ARRAY ID array REQUEST 가능한 PNRP ID의 정렬된 리스트
32+A*32 4+4 HASHED_NONCE hashed nonce 암호화된 논스 값
40+A*32
REQUEST 메세지는 알림자(advertiser)에게 알려진 CPA의 부분집합을 플러드하도록 요청하는 데 사용된다. 논스는 해쉬되어야 하며, 최초의 SOLOCIT에 수신된 hashed nonce와 비교되어야 한다. ID 배열은 전송자가 CPA를 얻을 수 있도록 전송자에게 다시 플러드되었으면 하는 PNRP ID를 포함한다. REQUEST 수신은 ACK 메세 지로 수신확인된다. 본 발명의 바람직한 실시예에서, 헤더의 메세지 유형은 3으로 설정된다. 본 발명의 내용에 따라 구성된 REQUEST 메세지의 상세한 데이터 구조가 표 9에 나타나 있다. 이 표에서, A는 ID 배열 내의 엔트리 수이다.
오프셋 길이 유형 이름 설명
0 4+8 PNRP_HEADER header 헤더
12 4+4 NONCE nonce 해독된 논스 값
20 4+8+A*32 PNRP_ID_ARRAY ID array 요청된 CPA에 대한 정렬된 PNRP ID의 배열
32+A*32
FLOOD 메세지는 피어를 선택하는 캐쉬된 CPA를 전파하기 위해 PNRP에 의해 사용된다. FLOOD는 새 CPA를 최하위 캐쉬 레벨에 추가할 때 또는 최하위 캐쉬 레벨에서 이전 버전으로 취소된 CPA를 처리할 때, REQUEST 메세지에 응답하여 개시된다. FLOOD는 중복된 FLOOD, 즉 'flooded list'를 방지하도록 돕는 어드레스 리스트를 포함한다. flooded list는 전송자의 어드레스, 전송자가 직접적으로 FLOOD를 전송하고자 하는 모든 목적지, 및 전송자가 이미 FLOOD를 수신했다고 알고 있는 기타 모든 PNRP 노드의 어드레스를 포함한다. 'flooded list'는 엔트리의 최대 수를 지니고 있다. 리스트가 꽉 차게 되면, 엔트리는 FIFO 방식에 따라 교체된다. 이것은 FLOOD 수신자가 더 먼 노드보다는 '근접한' 이웃 노드에게 그 FLOOD를 더 전파하고자 한다는 것을 가정한다. FLOOD 수신은 ACK 메세지로 수신확인된다. Validate ID는 옵션 필드(opntional field)이다. 이 필드가 있을 경우, 지정된 PNRP ID를 지닌 CPA가 로컬에 캐쉬되었다면, 수신자가 ACK로 응답하고, 그렇지 않다면 NACK으로 응답할 것을 요청한다. 바람직한 실시예에서, 헤더의 메세지 유형 은 4로 설정된다. 본 발명의 내용에 따라 구성된 FLOOD 메세지의 상세한 데이터 구조가 표 10에 나타나 있다. 이 표에서, P는 암호화된 CPA의 바이트 길이이고, 가장 근접한 DWORD 경계에서 반올림되었으며, A는 ID 배열 내의 엔트리 수이다.
오프셋 길이 유형 이름 설명
0 4+8 PNRP_HEADER header 헤더
12 4+2+2 FLOOD_CONTROLS controls FLOOD 이유를 기술하는 코드. FLOOD를 처리하는 데 사용될 수 있음. 또한 4 바이트 경계로 이동하기 위해 패딩됨.
20 (4+32) VALIDATE_PNRP_ID validate ID 검증할 PNRP ID. 옵션 필드
20(+36) 4+P CPA_BEST_MATCH CPA 플러드되는 CPA
20+P(+36) 4+8+A*20 IPV6_ENDPOINT_ARRAY flooded list
36+P+A*20(+36)
INQUIRE 메세지는 선택된 CPA를 로컬 캐쉬에 넣기 전 그들에 대해 아이덴티티 유효성 검사를 수행하기 위해 PNRP 노드에 의해 사용된다. 아이덴티티 유효성 검사는 CPA가 아직 최초의 노드에서 유효한지를 확인하고, 그 CPA를 등록하기 위해 시작 노드의 권한 유효성 검사를 돕는 정보를 요청한다. 하나의 플래그, RF_SEND_CHAIN(수신자에게 AUTHORITY 응답에 (만약 존재한다면) 인증서 체인을 전송하도록 요청함)이 'flags' 필드에 정의된다. PNRP ID가 로컬로 등록되어 있다면, INQUIRE 수신은 AUTHORITY 메세지로 수신확인된다. 그렇지 않다면, INQUIRE 메세지는 조용히 무시된다. 바람직한 실시예에서, 헤더의 메세지 유형은 7로 설정된다. 본 발명의 내용에 따라 구성된 INQUIRE 메세지의 상세한 데이터 구조가 표 11에 나타나 있다. 이 표에서 명백하게 나타나듯이, 다음 필드를 DWORD 경계에 두 기 위해 FLAGS_FIELD 뒤에 2 바이트가 추가된다.
오프셋 길이 유형 이름 설명
0 4+8 PNRP_HEADER header 헤더
12 4+2+2 FLAGS_FIELD flags 인증서 체인 또는 로컬 등록의 단순한 확인이 요망되는지 여부를 나타냄. 또한 4바이트 경계로 이동하기 위해 패딩됨.
20 4+32 VALIDATE_PNRP_ID validate 존재에 대해 유효성 검증을 할 PNRP ID
56
AUTHORITY 메세지는 PNRP ID가 여전히 로컬 노드에 등록되어 있는지를 확인 또는 부인하는 데 사용되고, 선택적으로 인증서 체인을 제공하여 AUTHORITY 수신자로 하여금 target ID에 대응하는 CPA를 등록하는 노드의 권리에 대한 유효성 검사를 가능하도록 한다. 다음의 플래그들이 'flags' 필드에 정의된다: AF_UNKNOWN_ID( 0x0001이고, 지정된 'validate' PNRP ID가 이 호스트에 등록되지 않았다는 것을 나타냄), AF_INVALID_SOURCE(0x0002이고, 사용되지 않음), AF_INVALID_BEST_MATCH(0x0004이고, 또한 사용되지 않음), AF_REJECT_TOO_BUSY(0x0008이고, RESOLVE에 응답할 때만 유효하고, 호스트가 너무 바빠서 RESOLVE를 받아들일 수 없고, 전송자는 반드시 그것을 프로세싱을 위해 다른 어떤 곳으로 전송해야만 한다는 것을 나타냄), AF_REJECT_DEADEND(0x0010이고, 사용되지 않음), AF_REJECT_LOOP(0x0020이고, 노드가 RESOLVE 메세지를 이미 처리했고, 여기로 전송되어서는 안된다는 것을 나타냄), AF_TRACING_ON(0x0040이고, 디 버깅용으로만 사용됨), AF_REDIRECT(0x0080이고, 그 노드가 RESOLVE 메세지를 전달하지 않지만, AUTHORITY 메세지에 참조 어드레스를 포함하고 있다는 것을 나타냄), AF_INVALID_REQUEST(0x0100이고, 최대 홉이 너무 크면 RESOLVE 메세지가 유효성 검사를 실패할 수 있다는 것을 나타냄) 및 AF_CERT_CHAIN(0x8000이고, 인증서 체인이 포함되어 validate PNRP ID 및 그 CPA를 서명하는 데 사용되는 공용 키 간의 관계에 대해 유효성 검사를 가능하게 해 준다는 것을 나타냄).
validate PNRP ID는 AUTHORITY가 전송될 ID를 지닌다. cert chain은 옵션 필드이다. AF_CENT_CHAIN 플래그가 이것이 존재하는지 여부를 나타낸다. referral endpoint 또한 옵션 필드이다. 이 필드는 RESOLVE 메세지를 전송할 수는 없지만, RESOLVE가 전송될 수 있는 다른 노드를 알고 있는 노드에 의해 사용된다. endpoint는 RESOLVE가 전송될 피어 노드의 IPv6 어드레스 및 포트를 포함한다. 현재 이 필드는 노드가 시드 서버를 통해 클라우드 분할을 검출하고자 하는 경우 이외에는 무시된다. classifier 필드는 PNRP ID를 생성하는 데 사용되는 피어 네임의 일부인 실제 분류자 문자열(classifier string)을 포함한다. AUTHORITY 수신은 명시적으로 수신확인되지 않는다. AUTHORITY는 INQUIRE 또는 RESOLVE 메세지 둘 중 하나에 대한 수신확인/응답으로서만 전송된다. AUTHORITY가 이 이외의 정황에서 수신될 경우, 그것은 반드시 폐기되어야 한다. 바람직한 실시예에서, 헤더의 메세지 유형은 8로 설정된다. 본 발명의 내용에 따라 구성된 AUTHORITY 메세지의 상세한 데이터 구조가 표 12에 나타나 있다. 이 테이블에서, C는 암호화된 인증서 체인의 바이트 길이이고, 가장 근접한 DWORD 경계에서 반올림되었고, S는 분류자 문자열의 바이트 길이이다.
오프셋 길이 유형 이름 설명
0 4+8 PNRP_HEADER header 헤더
12 4+4 PNRP_HEADER_ACKED ackd header RESOLVE의 헤더 또는 암시적으로 ACK된 INQUIRE의 헤더
20 4+4 SPLIT_CONTROLS splitcontrol 조각에 대한 분할 제어. 옵션 필드
20(+8) 4+2+2 FLAGS_FIELD flags RESOLVE/INQUIRE의 내용 및 가능한 결과를 나타내는 플래그. 또한 4바이트 경계로 이동하기 위해 패딩됨.
28(+8) 4+32 VALIDATE_PNRP_ID validate 권한이 속해 있는 PNRP ID
64(+8) (4+20) IPV6_REFERRAL_ADDRESS referral endpoint IPv6 끝점. 옵션 필드
64(+32) (4+32) IPV6_REFERRAL_ID referral PNRP ID IPv6 끝점의 PNRP ID. 옵션 필드
64(+68) 4+C CERT_CHAIN cert chain 등록된 ID에 대한 CPA를 서명하는 데 사용되는 공용 키에 관한 인증서 체인
68+C(+68) (4+8+S) CLASSIFIER classifier 분류자 문자열. 옵션 필드
68+C(+S+80)
AUTHORITY 메세지는 인증서 체인 및 분류자 문자열을 포함하기 때문에 매우 길 수 있다. 네트워크를 통해 용이하게 전송하기 위해서, 전송 시 명시적으로 여러 조각들로 나뉘어 질 수 있다. 수신자는 그 메세지를 처리하기 전에 조각들을 모을 수 있어야 한다. 메세지가 분할되면, 헤더 및 ACK된 헤더 필드가 각 조각에서 반복된다. 각 조각은 또한 split control 필드를 포함한다. 각 조각에서 split control의 오프셋 값은 조각의 오프셋을 반영하도록 변경된다. split controls의 크기 값은 헤더, ACK된 헤더 및 split control 필드 크기를 제외한 전체 메세지의 크기이다. 맨 마지막을 제외하고 모든 조각들은 동일한 크기를 갖는다. 메세지가 분할되지 않을 경우, split controls 필드는 옵션 필드이다.
ACK 메세지는 요청/응답 프로토콜로서 PNRP에 의해 사용된다. 어떤 환경에서, 응답 대신 ACK를 사용하면 프로토콜이 단순해진다. ACK는 REQUEST, RESPONSE 및 FLOOD 메세지를 수신하면 항상 전송된다. 다른 메세지는 적절한 응답 메세지 유형으로 수신확인된다. ACK는 ACK로서 작용하고, 또는 validate ID 집합을 지닌 FLOOD의 경우, flag 필드를 KF_NACK=1로 설정하여 NACK로서 작용할 수 있다. 바람직한 실시예에서, 헤더 메세지 유형은 9로 설정된다. 본 발명의 내용에 따라 구성된 ACK 메세지의 상세한 데이터 구조가 표 13에 나타나 있다.
오프셋 길이 유형 이름 설명
0 4+8 PNRP_HEADER header 헤더
12 4+4 PNRP_HEADER_ACKED ackd header ACK된 메세지의 헤더
20 (4+2+2) FLAGS_FIELD flags 플래그 필드. 또한 4바이트 경계로 이동하기 위해 패딩됨. 옵션 필드
20(+8)
REPAIR 메세지는 PNRP 클라우드가 일부 경우에서 분할을 경험하기 때문에 사용된다. 이 메세지는 분할을 테스트하고 필요 시 REPAIR을 개시하기 위해 사용된다. REPAIR는 다른 노드에게 다른 캐쉬 레벨에 REPAIR를 전파하도록 요청한다. 바람직한 실시예에서, 헤더의 메세지 유형은 10으로 설정된다. 본 발명의 내용에 따라 구성된 REPAIR 메세지의 상세한 데이터 구조가 표 14에 나타나 있다. 이 표 에서 명백하게 나타나듯이, 다음 필드를 DWORD 경계에 두기 위해 CACHE_LEVEL 뒤에 2 바이트가 추가된다.
오프셋 길이 유형 이름 설명
0 4+8 PNRP_HEADER header 헤더
12 4+32 TARGET_PNRP_ID PNRP_ID 위치를 알아낼 ID
48 4+2+2 CACHE_LEVEL repair level 복구 테스트에 사용되는 캐쉬 레벨. 또한 4바이트 경계로 이동하기 위해 패딩됨.
56 4+20 IPV6_ENDPOINT repair address 복구 테스트에서 사용될 IP 끝점
80
지금까지 메세지 및 그 데이터 구조에 대해 설명했고, 이제부터는 이러한 메세지를 구성하는 데 사용되는 메세지 엘리먼트에 대해 설명할 것이다. 이하는 PNRP 메세지에서 전송되는 구조의 바이트 코드에 대해 상세히 설명하고 있다. 다른 언급이 없다면, 네트워크에서 모든 숫자는 바이트 상태로 전송되고, 모든 텍스트는 전송 전에 UTF-8로 암호화된다. 이들 메세지 엘리먼트는 지금까지 설명되었던 메세지에 대해 블록을 구축한다. 기본 메세지 엘리먼트는 필드 설명(field description)이다. 각 필드 엘리먼트는 메세지 내에서 4 바이트 경계에서 시작해야 한다. 이것은 필드 간에 간격이 있을 수 있다는 것을 의미한다.
MESSAGE_FIELD 엘리먼트는 PNRP가 추후에 쉽게 확장 가능하도록 하는 데에 사용되는 필드 설명이다. 메세지 내의 각 데이터 집합에 대해, 이것은 필드 유형을 실별하는 16 비트 'field ID' 및 그 필드에 대한 16 비트 바이트 총계(count)를 제공한다. 본 발명의 내용에 따라 구성된 MESSAGE_FIELD 엘리먼트의 상세한 데이 터 구조가 표 15에 나타나 있다.
오프셋 길이 유형 이름 설명
0 2 USHORT field ID
2 2 USHORT length MESSAGE_FIELD를 포함한 필드 길이(바이트)
4
PNRP_HEADER(유형 0x0010)는 모든 PNRP 메세지를 시작하는 데 사용된다. protocol+version은 4 바이트 식별자를 만들고, 이는 수신된 메세지가 정말로 PNRP를 위해 의도된 것인지를 결정하는데 유용하다. 본 발명의 내용에 따라 구성된 PNRP_HEADER 엘리먼트의 상세한 데이터 구조가 표 16에 나타나 있다.
오프셋 길이 유형 이름 설명
0 1 BYTE protocol PNRP 프로토콜을 식별하는 8비트 수. 값=0x51
1 1 BYTE version major 메이저 프로토콜 버전. 예를 들어, v1.2의 '1'.
2 1 BYTE version minor 마이너 프로토콜 버전. 예를 들어, v1.2의 '2'
3 1 BYTE message type 이 사양에서 정의된 메세지 1-10
4 2 ULONG message ID ACK 추적에 도움을 주는 번호. 임의의 수일 수 있음. 하나씩 증가하는 서수를 추천함.
8
PNRP_HEADER의 message ID는 한 노드가, 수신된 메세지가 자신이 전송했던 메세지에 대한 응답을 취지로 하는 것이고, 실제로 그러한 응답이라는 것을 확실히 확인하는 데 사용된다. 예를 들어, 노드가 다른 노드로 RESOLVE 메세지를 전송했 다고 가정한다. 이 제 1노드는 도 4에 도시된 대로 AUTHORITY 메세지를 이어 수신하기를 기대한다. 그러나, 최초의 RESOLVE에 대한 응답을 찾고 추적하는 방법이 없으므로, 수신된 AUTHORITY 메세지가 적합한 것인지 또는 클라우드 내의 악의 있는 노드가 속인 것인지는 장담할 수 없다. RESOLVE 메세지에 message ID를 포함함으로써, AUTHORITY 메세지를 생성한 노드는 이하에 설명되는 PNRP_HEADER_ACKED 필드에 그 응답으로 이 메세지 ID를 포함할 수 있다.
PNRP_HEADER_ACKED(유형 0x0018)는 전체 PNRP 메세지의 헤더이고, 메세지가 ACK되었음을 식별하는 데 사용된다. 본 발명의 내용에 따라 구성된 PNRP_HEADER_ACKED 엘리먼트의 상세한 데이터 구조가 표 17에 나타나 있다.
오프셋 길이 유형 이름 설명
0 4 ULONG acked message ID ACK된 메세지의 ID
4
IPV6_ENDPOINT(유형 0x0021) 엘리먼트는 PNRP가 IPv6 클라우드에서 작동하도록 지정되었기 때문에 사용된다. 이 구조는 IPv6 네트워크 끝점을 지정한다. 또한 진행 중에 RESOLVE에 대한 노드 유용성(utility)을 나타내는 데 사용될 수 있는 플래그가 있다. path flag는 어드레스로 전송된 RESOLVE가 받아들여짐(accepted)이거나 거절됨(rejected)인지 여부를 나타내는 데 사용된다. 게다가, 어드레스가 가까운 이웃 노드라면, 노드는 자신의 가까운 이웃 노드들 모두를 알아야 하기 때문에 의심(suspect) 플래그가 설정될 수 있다. addressremoved 지시자는 디버깅 시 사용되어 그 엔트리를 실제로 제거하기 않고 제거됨(removed)으로 표시한다. 이들 지시자는 다음과 같다.:
PNRP_FLAGGED_ADDRESS_ACCEPTED(0x01);
PNRP_FLAGGED_ADDRESS_REJECTED(0x02);
PNRP_FLAGGED_ADDRESS_UNREACHABLE(0x04);
PNRP_FLAGGED_ADDRESS_LOOP(0x08);
PNRP_FLAGGED_ADDRESS_TOO_BUSY(0x10);
PNRP_FLAGGED_ADDRESS_BAD_VALIDATE_ID(0x20);
PNRP_FLAGGED_ADDRESS_REMOVED(0x80); 및
PNRP_FLAGGED_SUSPECT_UNREGISTERED_ID(0x40). 본 발명의 내용에 따라 구성된 IPV6_ENDPOINT 엘리먼트의 상세한 데이터 구조가 표 18에 나타나 있다.
오프셋 길이 유형 이름 설명
0 1 BYTE pathflag 이 노드 끝점의 플래그
1 1 BYTE protocol IP 프로토콜 번호로서, UDP로 설정되어야 함
2 2 USHORT port IPv6 포트
4 16 BYTE[16] address IPv6 어드레스
20
PNRP ID(유형 0x0030) 엘리먼트는 128 비트 p2p ID와 128 비트 서비스 위치를 연결한 것이다. 본 발명의 내용에 따라 구성된 PNRP_ID 엘리먼트의 상세한 데이터 구조가 표 19에 나타나 있다.
오프셋 길이 유형 이름 설명
0 16 BYTE[16] p2p ID 피어 네임의 16 바이트(128 비트) 해쉬
16 16 BYTE[16] service location 16 바이트(128 비트) 서비스 위치(알려진 서비스 어드레스로부터 파생됨)
32
TARGET_PNRP_ID(유형 0x0038)는 RESOLVE 요청 또는 그에 대응하는 RESPONSE 에 대한 target ID다. 본 발명의 내용에 따라 구성된 TARGET_PNRP_ID 엘리먼트의 상세한 데이터 구조가 표 20에 나타나 있다.
오프셋 길이 유형 이름 설명
0 16 BYTE[16] p2p ID 피어 네임의 16 바이트(128 비트) 해쉬
16 16 BYTE[16] service location 16 바이트(128 비트) 서비스 위치(알려진 서비스 어드레스로부터 파생됨)
32
VALIDATE_PNRP_ID(유형 0x0039)는 유효성 검증 및 권한이 요청된 PNRP ID다. 본 발명의 내용에 따라 구성된 VALIDATE_PNRP_ID 엘리먼트의 상세한 데이터 구조가 표 21에 나타나 있다.
오프셋 길이 유형 이름 설명
0 16 BYTE[16] p2p ID 피어 네임의 16 바이트(128 비트) 해쉬
16 16 BYTE[16] service location 16 바이트(128 비트) 서비스 위치(알려진 서비스 어드레스로부터 파생됨)
32
FLAGS_FIELD(유형 0x0040)는 컨텍스트 고유의 목적으로 사용되는 1 비트 필드인 플래그를 나타낸다. 본 발명의 내용에 따라 구성된 FLAGS_FIELD 엘리먼트의 상세한 데이터 구조가 표 22에 나타나 있다.
오프셋 길이 유형 이름 설명
0 2 USHORT flags 컨텍스트 고유의 플래그용 비트 필드
2
RESOLVE_CONTROLS(유형 0x0041) 필드는 RESOLVE 또는 RESPONSE를 처리하는 데 사용되는 정보를 포함한다. RESOLVE가 역추적되고 있는지 또는 AUTHORITY 메세지가 요청되었는지 여부를 나타내는 데 flags가 사용된다. 플래그로는 RF_IGNORE_NEXT_HOP(0x0001), RF_SEND_CHAIN(0x0004), RF_DONT_REMOVE_PATH_ENTRIES(0x0008, 디버깅용으로만 사용됨) 및 RF_TRACING_ON(0x0010, 디버깅용으로만 사용됨)이 있다. max hops은 RESOLVE를 완료하기 전 홉의 수를 제한한다. operation code는 매칭이 어떻게 수행되어야 하는지를 기술한다. 매치는 모든 코드의 최상위 128 비트(P2P ID)만일 수 있고, 또는 가장 근접한 코드의 서비스 위치(service location)을 또한 고려할 수 있다. operation code는 또한 매치가 동일한 노드에 등록된 ID를 RESOLVE의 생성자로 간주해야 하는지 여부를 결정한다. operation code로는 SEARCH_OPCODE_NONE(0), SEARCH_OPCODE_ANY_PEERNAME(1), SEARCH_OPCODE_NEAREST_PEERNAME(2), SEARCH_OPCODE_NEAREST64_PEERNAME(4), 및 SEARCH_OPCODE_UPPER_BITS(8)가 있다. precision은 비트의 실제 수에 매칭하는 ID의 정밀도(precision)를 설정한다. 이 값은 operation code가 SEARCH_OPCODE_UPPER_BITS일 때 사용된다.
reason은 RESOLVE가 캐쉬 유지(cache maintenance)로 인해 복구 프로세스의 일부로서 전송되었는지, 또는 애플리케이션 요청으로 인해 등록의 일부로서 전송되는지를 나타내는 데 사용된다. reason으로는 REASON_APP_REQUEST(0), REASON_REGISTRATION(1), REASON_CACHE_MAINTENANCE(2), REASON_REPAIR_DETECTION(3), REASON_SYNC_REQUEST(4), REASON_CPA_VIA_RESOLVE(5), REASON_CPA_VIA_FLOOD(6), REASON_REPAIR(7) 및 REASON_CPA_VIA_BACK_FLOOD(8)가 있다.
result code는 RESOLVE가 완료된 이유 및 RESPONSE로 변환된 이유를 나타낸다. 이것은 성공 또는 홉의 총수가 초과되었거나, 더 나은 경로를 찾을 수 없거나, 목표를 발견하는데 너무 많은 이웃 노드들이 실패했기 때문에 실패했다는 것을 나타낼 수 있다. 이러한 result code로는 RESULT_NONE(0), RESULT_FOUND_MATCH(1), RESULT_MAX_HOP_LIMIT_HIT(2), RESULT_NO_BETTER_PATH_FOUND(3), 및 RESULT_TOO_MANY_MISSES(4)가 있다. transaction ID는 RESPONSE를 연관시키기 위해 요청의 생성자에 의해 사용된다. RESOLVE 생성자는 trans ID 값을 설정하고, RESOPONSE를 개시한 노드는 RESPONSE 메세지에 그 값을 그대로 다시 전송(echo)한다. 중간 노드들은 이 값을 변경해서는 안 된다. 본 발명의 내용에 따라 구성된 RESOLVE_CONTROLS 엘리먼트의 상세한 데이터 구조가 표 23에 나타나 있다.
오프셋 길이 유형 이름 설명
0 2 USHORT flags 컨텍스트 고유의 플래그 용 비트 필드
2 1 BYTE max hops 메세지가 방문할 수 있는 PNRP 노드 수
3 1 BYTE operation code RESOLVE 동작을 제어하는 코드. RESOLVE가 생성자로 전송되어야 하는가? ID의 상위 128 비트가 특별한 것으로 간주되어야 하는가?
4 2 USHORT precision 매치할 유효 비트 수
6 1 BYTE reason code RESOLVE를 개시하는 이유를 기술하는 코드 - 애플리케이션 요청, 복구 검출, 등록, 캐쉬 유지 등.
7 1 BYTE result code RESPONSE를 리턴하는 이유를 기술하는 코드- 발견된 매치, 최대 홉 한도 적중, 더 나은 경로를 찾을 수 없음 등.
8 4 ULONG trans ID 트랜잭션 ID 값
12
CACHE_LEVEL(유형 0x0042) 엘리먼트는 REPAIR를 실행할 때 어떤 캐쉬 레벨이 사용될 것인지를 기술한다. 이것은 분할 캐쉬 복구를 수행할 때 사용된다. 본 발명의 내용에 따라 구성된 CACHE_LEVEL 엘리먼트의 상세한 데이터 구조가 표 24에 나타나 있다.
오프셋 길이 유형 이름 설명
0 2 USHORT cache level 캐쉬 레벨 번호(0이 최상위 캐쉬임)
1
FLOOD_CONTROLS(유형 0x0043) 엘리먼트는 FLOOD를 처리하는 데 사용되는 정보를 포함한다. FLOOD를 전송했던 이유가 유일하게 사용되는 코드다. 본 발명의 내용에 따라 구성된 FLOOD_CONTROLS 엘리먼트의 상세한 데이터 구조가 표 25에 나타나 있다.
오프셋 길이 유형 이름 설명
0 2 USHORT flags 컨텍스트 고유의 플래그용 비트 필드
2 1 BYTE reason code FLOOD를 개시한 이유를 기술하는 코드 - 동기화 요청, RESOLVE를 통해 탐색된 CPA, FLOOD를 통해 탐색된 CPA, 복구하기 등.
3
CPA_SOURCE(유형 0x0058)은 SOLICIT 메세지에서 소스 CPA로서 사용되는 CPA이다. CPA는 네트워크 전송을 위해 암호화된다. 본 발명의 내용에 따라 구성된 CPA_SOURCE 엘리먼트의 상세한 데이터 구조가 표 26에 나타나 있다.
오프셋 길이 유형 이름 설명
O P CPA encoded CPA 암호화된 CPA
P
CPA_BEST_MATCH(유형 0x0059) 엘리먼트는 RESOLVE 또는 RESPONSE에서 '베스트 매치'로서 사용되는 CPA이다. CPA는 네트워크 전송을 위해 암호화된다. 본 발 명의 내용에 따라 구성된 CPA_BEST_MATCH 엘리먼트의 상세한 데이터 구조가 표 27에 나타나 있다.
오프셋 길이 유형 이름 설명
0 P CPA encoded CPA 암호화된 CPA
P
PNRP_ID_ARRAY(유형 0x0060) 엘리먼트는 배열에 저장된 ADVERTISE 및 REQUEST 메세지에 대한 PNRP ID를 포함한다. 배열 크기를 포함한 데이터가 이하에 기술된다. 본 발명의 내용에 따라 구성된 PNRP_ID_ARRAY 엘리먼트의 상세한 데이터 구조가 표 28에 나타나 있다.
오프셋 길이 유형 이름 설명
0 2 USHORT num entries ID 배열 내의 엔트리 수. A로 설정되어야 함.
2 2 USHORT array length 헤더를 포함한 배열의 전체 길이(바이트). 12+(A*32)이어야 함.
4 2 USHORT element field type 각 배열 엔트리의 유형에 대한 식별자. 0x0030, PNRP_ID이어야 함.
6 2 USHORT entry length 각 배열 엘리먼트의 길이(바이트). 32이어야 함.
8 A*32 PNRP_ID ID list PNRP ID's의 배열
8+A*32
IPV6_ENDPOINT_ARRAY(유형 0x0071)는 이미 방문한 모든 노드의 배열이다. 플러드된 메세지는 여러 노드를 방문한다. 이미 방문한 각 노드 및 전송된 각 노 드가 이 배열에 들어온다. 배열 크기를 포함한 데이터가 이하에 기술된다. 본 발명의 내용에 따라 구성된 IPV6_ENDPOINT_ARRAY 엘리먼트의 상세한 데이터 구조가 표 29에 나타나 있다.
오프셋 길이 유형 이름 설명
0 2 USHORT num entries 어드레스 배열 내의 엔트리 수. A로 설정되어야 함.
2 2 USHORT array length 헤더를 포함한 배열의 전체 길이(바이트). 12+(A*20)이어야 함.
4 2 USHORT element field type 각 배열 엔트리의 유형에 대한 식별자. 0x0021, IPV6_ADDRESS이어야 함.
6 2 USHORT entry length 각 배열 엘리먼트의 길이(바이트). 19이어야 함.
8 A*20 IPV6_ENDPOINT[] endpoint array 끝점의 배열
8+A*20
IPV6_REFERRAL_ADDRESS(유형 0x0072) 엘리먼트는 RESOLVE를 전송하기 위해 대체 어드레스(alternate address)를 제공하는 데 특별히 사용되는 IPv6 끝점이다. 이 필드는 노드가 RESOLVE를 전송하기를 원치 않을 때, 그러나 일부 다른 노드가 시도할 수 있는 어드레스를 제공하고자 할 때 AUTHORITY 메세지에서 사용된다. 본 발명의 내용에 따라 구성된 IPV6_REFERRAL_ADDRESS 엘리먼트의 상세한 데이터 구조가 표 30에 나타나 있다.
오프셋 길이 유형 이름 설명
0 1 BYTE pathflag 이 노드 끝점의 플래그
1 1 BYTE protocol IP 프로토콜 번호로서, UDP로 설정되어야 함.
2 2 USHORT port IPv6 포트
4 16 BYTE[16] address IPv6 어드레스
20
IPV6_REFERRAL_ID(유형 0x0073)엘리먼트는 IPV6_REFERRAL_ADDRESS와 함께 사용되어 참조용으로 사용되는 PNRP ID를 나타낸다. 본 발명의 내용에 따라 구성된 IPV6_REFERRAL_ID 엘리먼트의 상세한 데이터 구조가 표 31에 나타나 있다.
오프셋 길이 유형 이름 설명
0 16 BYTE[16] p2p ID 피어 네임의 16 바이트(128 비트) 해쉬
16 16 BYTE[16] service location 16 바이트(128 비트) 서비스 위치(알려진 서비스 어드레스로부터 파생됨)
32
Cert Chain(CERT_CHAIN)(유형 0x0080) 엘리먼트는 Windows CAPI API를 사용하여 구축된다. 먼저, 체인을 구성하는 인증서들이 메모리 인증서 저장소 내의 CAPI에 넣어지고, 그 후에 PKCS7 암호화된 인증서 저장소로서 반출된다(export). 이 반출된 저장소는 변경없이 전송된다.
WCHAR(유형 0x0084) 엘리먼트는 하나의 UNICODE 문자를 수용하도록 정의된다. 이것은 분류자(classifier)와 같이, UNICODE 배열 필드의 일부로서만 사용된다.
CLASSIFIER(유형 0x0085) 엘리먼트는 피어 네임의 기초로서 사용되었던 UNICODE 분류자 문자열이다. 이것은 WCHAR 엘리먼트 배열로서 암호화된다. 본 발명의 내용에 따라 구성된 CLASSIFIER 엘리먼트의 상세한 데이터 구조가 표 32에 나타나 있다.
오프셋 길이 유형 이름 설명
0 2 USHORT num entries 어드레스 배열 내의 엔트리 수. A로 설정되어야 함.
2 2 USHORT array length 헤더를 포함한 배열의 전체 길이(바이트). 12+(A*2)로 설정되어야 함.
4 2 USHORT element field type 각 배열 엔트리의 유형에 대한 식별자. 0x0084, WCHAR이어야 함.
6 2 USHORT entry length 각 배열 엘리먼트의 길이(바이트). 2이어야 함.
8 A*2 WCHAR[] wide character array UNICODE 문자열의 배열
8+A*2
HASHED_NONCE(유형 0x0092) 엘리먼트는 ADVERTISE 메세지에 포함된 암호화된 논스 값이다. 수신자는 이 논스를 해독할 열쇠를 지닌 것으로 예상된다. 본 발명의 내용에 따라 구성된 HASHED_NONCE 엘리먼트의 상세한 데이터 구조가 표 33에 나타나 있다.
오프셋 길이 유형 이름 설명
0 4 ULONG encrypted nonce 암호화 후의 논스 값
4
NONCE(유형 0x0093) 엘리먼트는 REQUEST 메세지에 포함된 해독된 논스 값이 다. 수신자는 이 해독된 논스가 암호화 되기 전에 전송된 값과 매치하는지에 대해 유효성 검사를 할 것으로 예상된다. 본 발명의 내용에 따라 구성된 NONCE 엘리먼트의 상세한 데이터 구조가 표 34에 나타나 있다.
오프셋 길이 유형 이름 설명
0 4 ULONG decrypted nonce 논스 값
4
SPLIT_CONTROLS(유형 0x0098) 엘리먼트는 긴 메세지가 하나의 메세지가 아니라, 일련의 조각들로 전송될 때 사용된다. 각각의 조각들은 메세지가 수신자에 의해 구성될 수 있도록 split controls 필드를 포함한다. 본 발명의 내용에 따라 구성된 SPLIT_CONTROLS 엘리먼트의 상세한 데이터 구조가 표 35에 나타나 있다.
오프셋 길이 유형 이름 설명
0 2 USHORT size 조각의 크기
2 2 USHORT offset 조각의 오프셋
4
PNRP_TRACE(유형 0x0099) 엘리먼트는 디버깅동안 RESOLVE와 RESPONSE 메세지간에 홉에서 홉으로 전달될 수 있는 데이터를 수용하는 데 사용된다. 이것은 추적 데이터를 저장하는 데 사용된다. 프로토콜의 최종 버전에서는 지원되지 않을 수 있다.
본 발명의 다양한 실시예에 대한 상기 기술은 도시 및 설명을 위해 제공되었다. 이것은 개시된 명확한 실시예에 대해 본 발명을 총망라하거나 제한하고자 하는 것이 아니다. 상술된 내용에 비추어 많은 변경 및 변형이 가능하다. 상술된 실시예는 본 발명의 원리 및 그의 실질적인 응용을 가장 잘 도시하기 위해 선택되 고 기술되었으며, 그렇게 함으로써 당업자라면 다양한 실시예에서 및 특별히 고려된 사용에 적합하도록 다양하게 변경하여 본 발명을 활용할 수 있을 것이다. 이러한 모든 변경 및 변형은 명백히, 합법적으로, 및 공정하게 권리가 주어지는 범위에 따라 해석된 첨부된 청구항에 의해 결정되는 본 발명의 범위 내에 있다.
PNRP에서 사용되기에 적합한 메세지 데이터 구조는 PNRP에 유용한 다양한 메세지를 구성하기 위해 메세지 데이터 필드를 이용한다. 이 메세지 데이터 필드 각각은 메세지 엘리먼트를 포함한다. 이러한 메세지 데이터 구조 덕분에 PNRP에서 사용되는 메세지는 확장가능하다.

Claims (101)

  1. 피어 투 피어 네임 레졸루션 프로토콜(peer to peer name resolution protocol: PNRP)에서 사용되기 위한 피어 투 피어 프로토콜 메세지를 생성하고 발송하기 위한 방법으로서,
    PNRP 메세지 유형을 포함하는 PNRP 헤더(header)를 포함하는 제1 필드 및 상기 PNRP 메세지 유형에 대응하는 적어도 하나의 추가 필드를 포함하는 확장 가능한(extensible) 데이터 구조를 생성하는 단계 - 상기 PNRP 메세지 유형은 RESOLVE, RESPONSE, SOLICIT, ADVERTISE, REQUEST, FLOOD, INQUIRE, AUTHORITY, 또는 REPAIR 메세지 중 하나를 포함함 -;
    PNRP 기능(function)에 대응하는 상기 확장 가능한 데이터 구조를 활성화(populating)하는 단계; 및
    상기 활성화된 확장 가능한 데이터 구조를 포함하는 상기 피어 투 피어 프로토콜 메세지를 발송하는 단계
    를 포함하는 방법.
  2. 삭제
  3. 제1항에 있어서,
    상기 제1 필드는 헤더 ID(header identification), 헤더 길이 (header length), 프로토콜 식별자(protocol identifier), 버전 주 식별자(version major identifier), 버전 부 식별자(version minor identifier) 및 메세지 ID 지시자(message identification indicator)를 더 포함하는, 방법.
  4. 삭제
  5. 제1항에 있어서,
    상기 PNRP 기능이 공인된 피어 어드레스 (certified peer address: CPA)로 타겟 PNRP ID (target PNRP identification)의 레졸루션(resolution)을 요청하는 것을 포함하면, 상기 확장 가능한 데이터 구조를 활성화하는 단계는,
    RESOLVE 메세지를 포함하는 상기 PNRP 메세지 유형을 활성화하는 단계;
    리졸브 컨트롤즈(resolve controls) 메세지 엘리먼트를 포함하는 제1 추가 필드를 활성화하는 단계;
    타겟 PNRP ID(target PNRP identification) 메세지 엘리먼트를 포함하는 제2 추가 필드를 활성화하는 단계;
    유효성검사 PNRP ID(validate PNRP identification) 메세지 엘리먼트를 포함하는 제3 추가 필드를 활성화하는 단계;
    공인된 피어 어드레스(CPA) 베스트 매치(best match) 메세지 엘리먼트를 포함하는 제4 추가 필드를 활성화하는 단계; 및
    IPV6 끝점 배열(IPV6 endpoint array) 메세지 엘리먼트를 포함하는 제5 추가 필드를 활성화하는 단계를 포함하는, 방법.
  6. 제5항에 있어서,
    상기 리졸브 컨트롤즈 메세지 엘리먼트는, 컨텍스트 고유의 플래그용 비트 필드, 상기 RESOLVE 메세지가 방문할 수 있는 노드의 최대 개수, 리졸브 동작(resolve operation)을 제어하는 하나 이상의 오퍼레이션 코드(operation codes), 매치할 유의 비트(significant bit)들의 정확한 개수(precision number), 상기 RESOLVE 메세지를 개시하는 이유를 기술하는 이유 코드(reason code), 응답이 리턴된 이유를 기술하는 결과 코드(result code) 및 트랜잭션 ID 값(transaction identification value)을 포함하는, 방법.
  7. 제5항에 있어서,
    상기 타겟 PNRP ID 메세지 엘리먼트는 타겟 피어의 피어 네임의 해쉬 및 알려진(advertised) 서비스 어드레스로부터 도출된 서비스 위치(service location)를 포함하는, 방법.
  8. 제5항에 있어서,
    상기 유효성검사 PNRP ID 메세지 엘리먼트는, 유효화 및 권한이 요청된 노드의 피어 네임의 해쉬 및 유효화 및 권한이 요청된 상기 노드의 알려진(advertised) 서비스 어드레스로부터 도출된 서비스 위치를 포함하는, 방법.
  9. 제5항에 있어서,
    상기 CPA 베스트 매치 메세지 엘리먼트는 암호화된(encoded) CPA를 포함하는, 방법.
  10. 제5항에 있어서,
    상기 IPV6 끝점 배열 메세지 엘리먼트는, 배열 내의 엔트리들의 개수, 상기 배열의 총 길이, 각 배열 엔트리의 유형에 대한 식별자, 각 배열 엘리먼트의 길이 및 이미 방문했거나 상기 RESOLVE 메세지가 전송되었던 각 노드에 대한 어드레스들의 배열을 포함하는, 방법.
  11. 제1항에 있어서,
    상기 PNRP 기능이 RESOLVE 요청의 완료에 응답하는 것을 포함하는 경우, 상기 확장 가능한 데이터 구조를 활성화하는 단계는,
    RESPONSE 메세지를 포함하는 상기 PNRP 메세지 유형을 활성화하는 단계;
    리졸브 컨트롤즈(resolve controls) 메세지 엘리먼트를 포함하는 제1 추가 필드를 활성화하는 단계;
    타겟 PNRP ID(target PNRP identification) 메세지 엘리먼트를 포함하는 제2 추가 필드를 활성화하는 단계;
    CPA 베스트 매치(best match) 메세지 엘리먼트를 포함하는 제3 추가 필드를 활성화하는 단계; 및
    IPV6 끝점 배열(IPV6 endpoint array) 메세지 엘리먼트를 포함하는 제4 추가 필드를 활성화하는 단계를 포함하는, 방법.
  12. 제11항에 있어서,
    상기 리졸브 컨트롤즈 메세지 엘리먼트는, 컨텍스트 고유의 플래그용 비트 필드, 상기 RESOLVE 요청이 방문할 수 있는 노드의 최대 개수, 리졸브 동작을 제어하는 하나 이상의 오퍼레이션 코드, 매치할 유의 비트들의 정확한 개수, 상기 RESOLVE 요청을 개시한 이유를 기술하는 이유 코드, 응답이 리턴된 이유를 기술하는 결과 코드 및 트랜잭션 ID 값(transaction identification value)을 포함하는, 방법.
  13. 제11항에 있어서,
    상기 타겟 PNRP ID 메세지 엘리먼트는 타겟 피어의 피어 네임의 해쉬 및 알려진(advertised) 서비스 어드레스로부터 도출된 서비스 위치를 포함하는, 방법.
  14. 제11항에 있어서,
    상기 CPA 베스트 매치 메세지 엘리먼트는 암호화된(encoded) CPA를 포함하는, 방법.
  15. 제11항에 있어서,
    상기 IPV6 끝점 배열 메세지 엘리먼트는 배열 내의 엔트리들의 개수, 상기 배열의 총 길이, 각 배열 엔트리의 유형에 대한 식별자, 각 배열 엘리먼트의 길이 및 이미 방문하였거나 상기 RESPONSE 메세지가 전송되었던 각 노드에 대한 어드레스들의 배열을 포함하는, 방법.
  16. 제1항에 있어서,
    상기 PNRP 기능이 하나 이상의 엔트리를 그의 캐쉬로부터 알릴(advertise) 것을 PNRP 노드에게 요청하는 것을 포함하는 경우, 상기 확장된 데이터 구조를 활성화하는 단계는,
    SOLICIT 메세지를 포함하는 상기 PNRP 메세지 타입을 활성화하는 단계;
    공인된 피어 어드레스(CPA) 소스 메세지 엘리먼트를 포함하는 제1 추가 필드를 활성화하는 단계; 및
    해쉬 논스(hashed nonce) 메세지 엘리먼트를 포함하는 제2 추가 필드를 활성화하는 단계를 포함하는, 방법.
  17. 제16항에 있어서,
    상기 CPA 소스 메세지 엘리먼트는 암호화된(encoded) 소스 CPA를 포함하는, 방법.
  18. 제16항에 있어서,
    상기 해쉬 논스 메세지 엘리먼트는 암호화된(encrypted) 논스(nonce) 값을 포함하는, 방법.
  19. 제1항에 있어서,
    상기 PNRP 기능이 PNRP 노드의 캐쉬로부터 PNRP ID(identification)들의 리스트를 생성하는 것을 포함하는 경우, 상기 확장 가능한 데이터 구조를 포함하는 단계는,
    ADVERTISE 메세지를 포함하는 상기 PNRP 메세지 타입을 활성화하는 단계;
    PNRP 헤더 수신확인(header acknowledged) 메세지 엘리먼트를 포함하는 제1 추가 필드를 활성화하는 단계;
    PNRP ID 배열 (PNRP identification array) 메세지 엘리먼트를 포함하는 제2 추가 필드를 활성화하는 단계; 및
    해쉬 논스(hashed nonce) 메세지 엘리먼트를 포함하는 제3 추가 필드를 활성화하는 단계를 포함하는, 방법.
  20. 제19항에 있어서,
    상기 PNRP 헤더 수신확인 메세지 엘리먼트는, 수신확인된 수신 메세지의 메세지 ID(identification)를 포함하는, 방법.
  21. 제19항에 있어서,
    상기 PNRP ID 배열 메세지 엘리먼트는 PNRP ID 배열 내의 엔트리들의 개수, 상기 배열의 총 길이, 각 배열 엔트리의 유형에 대한 식별자, 각 배열 엘리먼트의 길이, 및 PNRP ID들의 배열을 포함하는, 방법.
  22. 제19항에 있어서,
    상기 해쉬 논스 메세지 엘리먼트는 암호화된(encrypted) 논스 값을 포함하는, 방법.
  23. 제1항에 있어서,
    상기 PNRP 기능이 한 세트의 알려진(advertised) 공인된 피어 어드레스(CPAs)들을 플러드(flood)하도록 PNRP 노드에게 요청하는 것을 포함하는 경우, 상기 확장 가능한 데이터 구조를 활성화하는 단계는,
    REQUEST 메세지를 포함하는 상기 PNRP 메세지 유형을 활성화하는 단계;
    논스(nonce) 메세지 엘리먼트를 포함하는 제1 추가 필드를 활성화하는 단계; 및
    PNRP ID 배열(PNRP identification array) 메세지 엘리먼트를 포함하는 제2 추가 필드를 활성화하는 단계를 포함하는, 방법.
  24. 제23항에 있어서,
    상기 논스 메세지 엘리먼트는 복호화된(decrypted) 논스 값을 포함하는, 방법.
  25. 제23항에 있어서,
    상기 PNRP ID 배열 메세지 엘리먼트는, PNRP ID 배열 내의 엔트리들의 개수, 상기 배열의 총 길이, 각 배열 엔트리의 유형에 대한 식별자, 각 배열 엘리먼트의 길이, 및 PNRP ID들의 배열을 포함하는, 방법.
  26. 제1항에 있어서,
    상기 PNRP 기능이 PNRP 피어들을 선택하도록 공인된 피어 어드레스(CPA)를 전파(propagate)하는 것을 포함하는 경우, 상기 확장 가능한 데이터 구조를 활성화하는 단계는,
    FLOOD 메세지를 포함하는 상기 PNRP 메세지를 활성화하는 단계;
    플러드 컨트롤즈(flood controls) 메세지 엘리먼트를 포함하는 제1 추가 필드를 활성화하는 단계;
    CPA 베스트 매치(best match) 메세지 엘리먼트를 포함하는 제2 추가 필드를 활성화하는 단계; 및
    IPV6 끝점 배열(IPV6 endpoint array) 메세지 엘리먼트를 포함하는 제3 추가 필드를 활성화하는 단계를 포함하는, 방법.
  27. 제26항에 있어서,
    상기 플러드 컨트롤즈 메세지 엘리먼트는, 컨텍스트 고유의 플래그용 비트 필드, 및 상기 FLOOD 메세지를 개시하는 이유를 기술하는 이유 코드를 포함하는, 방법.
  28. 제26항에 있어서,
    상기 CPA 베스트 매치 메세지 엘리먼트는 암호화된(encoded) CPA를 포함하는, 방법.
  29. 제26항에 있어서,
    상기 IPV6 끝점 배열 메세지 엘리먼트는, 배열 내의 엔트리들의 개수, 상기 배열의 총 길이, 각 배열 엔트리의 유형에 대한 식별자, 각 배열 엘리먼트의 길이, 및 상기 FLOOD 메세지가 전송된 각 노드 및 상기 FLOOD 메세지를 수신한 것으로 이미 알려진 각 노드의 어드레스들의 배열을 포함하는, 방법.
  30. 제1항에 있어서,
    상기 PNRP 기능이 고유의 PNRP ID(identification)이 PNRP 노드에 등록되었는지를 요청하는 단계를 포함하는 경우, 상기 확장 가능한 데이터 구조를 활성화하는 단계는,
    INQUIRE 메세지를 포함하는 상기 PNRP 메세지 유형을 활성화하는 단계;
    플래그즈 필드(flags field) 메세지 엘리먼트를 포함하는 제1 추가 필드를 활성화하는 단계; 및
    유효성검사 PNRP ID(validate PNRP identification) 메세지 엘리먼트를 포함하는 제2 추가 필드를 활성화하는 단계를 포함하는, 방법.
  31. 제30항에 있어서,
    상기 플래그즈 필드 메세지 엘리먼트는 컨텍스트 고유의 플래그용 비트 필드를 포함하는, 방법.
  32. 제30항에 있어서,
    상기 유효성검사 PNRP ID 메세지 엘리먼트는, 유효화 및 권한이 요청된 노드의 피어 네임의 해쉬 및 유효화 및 권한이 요청된 상기 노드의 알려진(advertised) 서비스 어드레스로부터 도출된 서비스 위치를 포함하는, 방법.
  33. 제1항에 있어서,
    상기 PNRP 기능이 PNRP ID(identification)의 지역 등록(local registration)을 확인하는 것을 포함하는 경우, 상기 확장된 데이터 구조를 활성화하는 단계는,
    AUTHORITY 메세지를 포함하는 상기 PNRP 메세지 유형을 활성화하는 단계;
    PNRP 헤더 수신확인(header acknowledged) 메세지 엘리먼트를 포함하는 제1 추가 필드를 활성화하는 단계;
    분할 컨트롤즈(split controls) 메세지 엘리먼트를 포함하는 제2 추가 필드를 활성화하는 단계;
    플래그즈 필드(flags field) 메세지 엘리먼트를 포함하는 제3 추가 필드를 활성화하는 단계;
    유효성검사 PNRP ID(validate PNRP identification) 메세지 엘리먼트를 포함하는 제4 추가 필드를 활성화하는 단계;
    인증서 체인(certificate chain) 메세지 엘리먼트를 포함하는 제5 추가 필드를 활성화하는 단계;
    IPV6 추천 어드레스(referral address) 메세지 엘리먼트를 포함하는 제6 추가 필드를 활성화하는 단계;
    IPV6 추천 ID(referral identification) 메세지 엘리먼트를 포함하는 제7 추가 필드를 활성화하는 단계; 및
    분류자(classifier) 메세지 엘리먼트를 포함하는 제8 추가 필드를 활성화하는 단계를 포함하는, 방법.
  34. 제33항에 있어서,
    상기 PNRP 헤더 수신확인 메세지 엘리먼트는, 수신확인된, 수신 메세지의 메세지 ID(identification)를 포함하는, 방법.
  35. 제33항에 있어서,
    상기 분할 컨트롤즈 메세지 엘리먼트는, 조각(fragmentation)의 크기 및 상기 조각의 오프셋에 대한 정보를 포함하는, 방법.
  36. 제33항에 있어서,
    상기 플래그즈 필드 메세지 엘리먼트는, 컨텍스트 고유의 플래그용 비트 필드를 포함하는, 방법.
  37. 제33항에 있어서,
    상기 유효성검사 PNRP ID 메세지 엘리먼트는, 유효화 및 권한이 요청된 노드의 피어 네임의 해쉬 및 유효화 및 권한이 요청된 상기 노드의 알려진(advertised) 서비스 어드레스로부터 도출된 서비스 위치를 포함하는, 방법.
  38. 제33항에 있어서,
    상기 인증서 체인 메세지 엘리먼트는 PKCS7 암호화된 인증서 저장소(encoded certificate store)를 포함하는, 방법.
  39. 제33항에 있어서,
    상기 IPV6 추천 어드레스 메세지 엘리먼트는 노드 끝점(endpoint)에 대한 경로 플래그, IP 프로토콜 번호, IPV6 포트, 및 대체 노드의 어드레스로서의 IPV6 어드레스를 포함하는, 방법.
  40. 제33항에 있어서,
    상기 IPV6 추천 ID 메세지 엘리먼트는 피어 네임의 해쉬 및 추천(referral)된 노드에 대한 서비스 위치를 포함하는, 방법.
  41. 제33항에 있어서,
    상기 분류자 메세지 엘리먼트는, 어드레스 배열 내의 엔트리들의 개수, 상기 배열의 총 길이, 각 배열 엔트리의 유형에 대한 식별자, 각 배열 엘리먼트의 길이 및 유니코드 문자열들의 배열을 포함하는 WCHAR 엘리먼트들의 배열로서 암호화된(encoded), 피어 네임의 기초로서 사용되었던 유니코드 분류자 문자열(unicode classifier string)을 포함하는, 방법.
  42. 삭제
  43. 삭제
  44. 제1항에 있어서,
    상기 PNRP 기능이, 클라우드(cloud)들이 분할(split)되었고 복구(repair)가 요구되는지를 판단하는 것을 포함하는 경우, 상기 확장 가능한 데이터 구조를 활성화하는 단계는,
    REPAIR 메세지를 포함하는 상기 PNRP 메세지 유형을 활성화하는 단계;
    타겟 PNRP ID(target PNRP identification) 메세지 엘리먼트를 포함하는 제1 추가 필드를 활성화하는 단계;
    캐쉬 레벨(cache level) 메세지 엘리먼트를 포함하는 제2 추가 필드를 활성화하는 단계; 및
    IPV6 끝점(endpoint) 메세지 엘리먼트를 포함하는 제3 추가 필드를 활성화하는 단계를 포함하는, 방법.
  45. 제44항에 있어서,
    상기 타겟 PNRP ID 메세지 엘리먼트는 타겟 피어의 피어 네임의 해쉬 및 알려진(advertised) 서비스 어드레스로부터 도출된 서비스 위치를 포함하는, 방법.
  46. 제44항에 있어서,
    상기 캐쉬 레벨 메세지 엘리먼트는 복구를 실행할 때 어떤 캐쉬 레벨이 사용되는지를 식별하는 캐쉬 레벨 번호를 포함하는, 방법.
  47. 제44항에 있어서,
    상기 헤더 메세지 엘리먼트는 특정 메세지에 대한 응답의 추적을 허용하기 위해 상기 특정 메세지를 식별하는 정보를 더 포함하는, 방법.
  48. 제1항에 있어서,
    상기 적어도 하나의 추가 필드는, 필드 ID(identification) 필드, 길이 필드 및 페이로드를 포함하는, 방법.
  49. 공인된 피어 어드레스(certified peer address: CPA)로의 타겟 PNRP ID(target PNRP identification)의 레졸루션(resolution)에 대한 요청을 포함하는 RESOLVE 메세지를 포함하는 피어 투 피어 프로토콜(peer to peer protocol) 메세지를 생성하고 발송하기 위한 단계들을 수행하기 위한, 컴퓨터에 의해 실행 가능한 명령의 프로그램을 기록한 컴퓨터 판독가능 기록매체에 있어서,
    상기 단계들은,
    피어 투 피어 네임 레졸루션 프로토콜 (peer to peer name resolution protocol: PNRP)에서 사용되기 위한 RESOLVE 메세지 데이터 구조를 생성하는 단계를 포함하고,
    상기 피어 투 피어 네임 레졸루션 프로토콜에서 사용되기 위한 RESOLVE 메세지 데이터 구조를 생성하는 단계는,
    PNRP 헤더(header) 메세지 엘리먼트를 갖는 제1 메세지 필드를 생성하는 단계;
    리졸브 컨트롤즈(resolve controls) 메세지 엘리먼트를 갖는 제2 메세지 필드를 생성하는 단계;
    타겟 PNRP ID(target PNRP identification) 메세지 엘리먼트를 포함하는 제3 메세지 필드를 생성하는 단계;
    유효성검사 PNRP ID(validate PNRP identification) 메세지 엘리먼트를 포함하는 제4 메세지 필드를 생성하는 단계;
    공인된 피어 어드레스(CPA) 베스트 매치(best match) 메세지 엘리먼트를 포함하는 제5 메세지 필드를 생성하는 단계;
    IPV6 끝점 배열(endpoint array) 메세지 엘리먼트를 포함하는 제6 메세지 필드를 생성하는 단계; 및
    상기 RESOLVE 메세지 데이터 구조를 포함하는 상기 피어 투 피어 프로토콜 메세지를 발송하는 단계
    를 포함하는 컴퓨터 판독가능 기록매체.
  50. 제49항에 있어서,
    각 메세지 엘리먼트는 필드 ID(field identification) 필드, 길이(length) 필드, 및 페이로드(payload)를 포함하는 메세지 엘리먼트 데이터 구조를 포함하는 컴퓨터 판독가능 기록매체.
  51. 제50항에 있어서,
    상기 리졸브 컨트롤즈(resolve controls) 메세지 엘리먼트의 페이로드는, 컨텍스트 고유의 플래그용 비트 필드, 상기 RESOLVE 메세지가 방문할 수 있는 노드들의 최대 개수, 리졸브 동작을 제어하는 하나 이상의 오퍼레이션 코드, 매치할 유의 비트들의 정확한 개수(precision number), 상기 RESOLVE 메세지를 개시한 이유를 기술하는 이유 코드, 응답이 리턴된 이유를 기술하는 결과 코드 및 트랜잭션 ID 값(transaction identification value)을 포함하는, 컴퓨터 판독가능 기록매체.
  52. 제50항에 있어서,
    상기 타겟 PNRP ID 메세지 엘리먼트의 페이로드는 타겟 피어의 피어 네임의 해쉬 및 알려진(advertised) 서비스 어드레스로부터 도출된 서비스 위치를 포함하는 컴퓨터 판독가능 기록매체.
  53. 제50항에 있어서,
    상기 유효성검사 PNRP ID 메세지 엘리먼트의 페이로드는, 유효화 및 권한이 요청된 노드의 피어 네임의 해쉬 및 유효화 및 권한이 요청된 상기 노드의 알려진(advertised) 서비스 어드레스로부터 도출된 서비스 위치를 포함하는, 컴퓨터 판독가능 기록매체.
  54. 제50항에 있어서,
    상기 IPV6 끝점 배열 메세지 엘리먼트의 페이로드는, 배열 내의 엔트리들의 개수, 상기 배열의 총 길이, 각 배열 엔트리의 유형에 대한 식별자, 각 배열 엘리먼트의 길이 및 이미 방문했거나 상기 RESOLVE 메세지가 전송되었던 각 노드에 대한 어드레스들의 배열을 포함하는, 컴퓨터 판독가능 기록매체.
  55. RESOLVE 요청의 완료에 대한 응답을 포함하는 RESPONSE 메세지를 포함하는 피어 투 피어 프로토콜(peer to peer protocol) 메세지를 생성하고 발송하기 위한 단계들을 수행하기 위한, 컴퓨터에 의해 실행 가능한 명령의 프로그램을 기록한 컴퓨터 판독가능 기록매체에 있어서,
    상기 단계들은,
    피어 투 피어 네임 리졸루션 프로토콜(peer to peer name resolution protocol: PNRP)에 사용하기 위한 RESPONSE 메세지 데이터 구조를 생성하는 단계; 및
    상기 RESPONSE 메세지 데이터 구조를 포함하는 상기 피어 투 피어 프로토콜 메세지를 발송하는 단계를 포함하고,
    상기 피어 투 피어 네임 리졸루션 프로토콜(peer to peer name resolution protocol: PNRP)에 사용하기 위한 RESPONSE 메세지 데이터 구조를 생성하는 단계는,
    PNRP 헤더(header) 메세지 엘리먼트를 갖는 제1 메세지 필드를 생성하는 단계;
    리졸브 컨트롤즈(resolve controls) 메세지 엘리먼트를 갖는 제2 메세지 필드를 생성하는 단계;
    타겟 PNRP ID(target PNRP identification) 메세지 엘리먼트를 포함하는 제3 메세지 필드를 생성하는 단계;
    CPA 베스트 매치(best match) 메세지 엘리먼트를 포함하는 제4 메세지 필드를 생성하는 단계;및
    IPV6 끝점 배열(endpoint array) 메세지 엘리먼트를 포함하는 제5 메세지 필드를 생성하는 단계를 포함하는, 컴퓨터 판독가능 기록매체.
  56. 제55항에 있어서,
    각 메세지 엘리먼트는 필드 ID(identification) 필드, 길이 필드, 및 페이로드를 포함하는 메세지 엘리먼트 데이터 구조를 포함하는, 컴퓨터 판독가능 기록매체.
  57. 제56항에 있어서,
    상기 리졸브 컨트롤즈 메세지 엘리먼트의 페이로드는, 컨텍스트 고유의 플래그용 비트 필드, 상기 RESOLVE 요청이 방문할 수 있는 노드의 최대 개수, 리졸브 동작을 제어하는 하나 이상의 오퍼레이션 코드, 매치할 유의 비트의 정확한 수, 상기 RESOLVE 요청을 개시한 이유를 기술하는 이유 코드, 및 응답이 리턴된 이유를 기술하는 결과 코드 및 트랜잭션 ID 값(transaction identification value)을 포함하는, 컴퓨터 판독가능 기록매체.
  58. 제56항에 있어서,
    상기 타겟 PNRP ID(target PNRP identification) 메세지 엘리먼트의 페이로드는, 타겟 피어의 피어 네임의 해쉬 및 알려진(advertised) 서비스 어드레스로부터 도출된 서비스 위치를 포함하는, 컴퓨터 판독가능 기록매체.
  59. 제56항에 있어서,
    상기 CPA 베스트 매치(best match) 메세지 엘리먼트의 페이로드는 암호화된(encoded) CPA를 포함하는, 컴퓨터 판독가능 기록매체.
  60. 제56항에 있어서,
    상기 IPV6 끝점 배열 메세지 엘리먼트의 페이로드는 배열 내의 엔트리들의 개수, 상기 배열의 총 길이, 각 배열 엔트리의 유형에 대한 식별자, 각 배열 엘리먼트의 길이 및 이미 방문했거나 상기 RESPONSE 메세지가 전송되었던 각 노드에 대한 어드레스 배열을 포함하는, 컴퓨터 판독가능 기록매체.
  61. PNRP 노드로 하여금 하나 이상의 엔트리를 그의 케쉬로부터 알리도록(advertise)하는 요청을 포함하는 SOLICIT 메세지를 포함하는 피어 투 피어 프로토콜(peer to peer protocol) 메세지를 생성하고 발송하기 위한 단계들을 수행하기 위한, 컴퓨터에 의해 실행 가능한 명령의 프로그램이 기록된 컴퓨터 판독가능 기록매체에 있어서,
    상기 단계들은,
    피어 투 피어 네임 레졸루션 프로토콜(peer to peer name resolution protocol: PNRP)에 사용되기 위한 SOLICIT 메세지 데이터 구조를 생성하는 단계; 및
    상기 SOLICIT 메세지 데이터 구조를 포함하는 상기 피어 투 피어 프로토콜 메세지를 발송하는 단계를 포함하고,
    상기 피어 투 피어 네임 레졸루션 프로토콜에 사용되기 위한 SOLICIT 메세지 데이터 구조를 생성하는 단계는,
    PNRP header 메세지 엘리먼트를 갖는 제1 메세지 필드를 생성하는 단계;
    공인된 피어 어드레스(CPA) 소스(source) 메세지 엘리먼트를 갖는 제2 메세지 필드를 생성하는 단계; 및
    해쉬 논스(hashed nonce) 메세지 엘리먼트를 포함하는 제3 메세지 필드를 생성하는 단계를 포함하는, 컴퓨터 판독가능 기록매체.
  62. 제61항에 있어서,
    각 메세지 엘리먼트는, 필드 ID(identification) 필드, 길이 필드, 및 페이로드를 포함하는 메세지 엘리먼트 데이터 구조를 포함하는, 컴퓨터 판독가능 기록매체.
  63. 제62항에 있어서,
    상기 CPA 소스 메세지 엘리먼트의 페이로드는 암호화된(encoded) 소스 CPA를 포함하는 컴퓨터 판독가능 기록매체.
  64. 제62항에 있어서,
    상기 해쉬 논스 메세지 엘리먼트의 페이로드는 암호화된(encrypted) 논스 값을 포함하는 컴퓨터 판독가능 기록매체.
  65. PNRP 노드의 캐쉬로부터의 PNRP ID(identification)들의 리스트를 포함하는 ADVERTISE 메세지를 포함하는 피어 투 피어 프로토콜 메세지를 생성하고 발송하기 위한 단계들을 수행하기 위한, 컴퓨터에 의해 실행가능한 명령의 프로그램을 기록한 컴퓨터 판독가능 기록매체에 있어서,
    상기 단계들은,
    피어 투 피어 네임 레졸루션 프로토콜(peer to peer name resolution protocol: PNRP)에 사용되기 위한 ADVERTISE 메세지 데이터 구조를 생성하는 단계; 및
    상기 ADVERTISE 메세지를 포함하는 상기 피어 투 피어 프로토콜 메세지를 발송하는 단계를 포함하고,
    상기 피어 투 피어 네임 레졸루션 프로토콜(peer to peer name resolution protocol: PNRP)에 사용되기 위한 ADVERTISE 메세지 데이터 구조를 생성하는 단계는,
    PNRP 헤더(header) 메세지 엘리먼트를 갖는 제1 메세지 필드를 생성하는 단계;
    PNRP 헤더 수신확인(acknowledged) 메세지 엘리먼트를 갖는 제2 메세지 필드를 생성하는 단계;
    PNRP ID 배열(PNRP identification array) 메세지 엘리먼트를 포함하는 제3 메세지 필드를 생성하는 단계; 및
    해쉬 논스(hashed nonce) 메세지 엘리먼트를 포함하는 제4 메세지 필드를 생성하는 단계를 포함하는, 컴퓨터 판독가능 기록매체.
  66. 제65항에 있어서,
    각 메세지 엘리먼트는, 필드 ID(identification) 필드, 길이 필드, 및 페이로드를 포함하는 메세지 엘리먼트 데이터 구조를 포함하는, 컴퓨터 판독가능 기록매체.
  67. 제66항에 있어서,
    상기 PNRP 헤더 수신확인 메세지 엘리먼트의 페이로드는, 수신확인된 메세지의 메세지 ID(identification)를 포함하는 컴퓨터 판독가능 기록매체.
  68. 제66항에 있어서,
    상기 PNRP ID 배열 메세지 엘리먼트의 페이로드는, PNRP ID 배열 내의 엔트리 수, 상기 배열의 총 길이, 각 배열 엔트리의 유형에 대한 식별자, 각 배열 엘리먼트의 길이, 및 PNRP ID들의 배열을 포함하는 컴퓨터 판독가능 기록매체.
  69. 제66항에 있어서,
    상기 해쉬 논스 메세지 엘리먼트의 페이로드는, 암호화된(encrypted) 논스 값을 포함하는, 컴퓨터 판독가능 기록매체.
  70. PNRP 노드로 하여금 한 세트의 알려진(advertised) 공인된 피어 어드레스(certified peer address: CPA)들을 플러드(flood)하도록 하는 요청을 포함하는 REQUEST 메세지를 포함하는 피어 투 피어 프로토콜(peer to peer protocol) 메세지를 생성하고 발송하기 위한 단계들을 수행하기 위한, 컴퓨터에 의해 실행가능한 명령의 프로그램을 기록한 컴퓨터 판독가능 기록매체에 있어서,
    상기 단계들은,
    피어 투 피어 네임 레졸루션 프로토콜(PNRP)에 사용되기 위한 REQUEST 메세지 데이터 구조를 생성하는 단계; 및
    상기 REQUEST 메세지 데이터 구조를 포함하는 상기 피어 투 피어 프로토콜 메세지를 발송하는 단계를 포함하고,
    상기 피어 투 피어 네임 레졸루션 프로토콜(PNRP)에 사용되기 위한 REQUEST 메세지 데이터 구조를 생성하는 단계는,
    PNRP 헤더(header) 메세지 엘리먼트를 갖는 제1 메세지 필드를 생성하는 단계;
    논스(nonce) 메세지 엘리먼트를 갖는 제2 메세지 필드를 생성하는 단계; 및
    PNRP ID 배열(PNRP identification array) 메세지 엘리먼트를 포함하는 제3 메세지 필드를 생성하는 단계를 포함하는 컴퓨터 판독가능 기록매체.
  71. 제70항에 있어서,
    각 메세지 엘리먼트는, 필드 ID 필드, 길이 필드, 및 페이로드를 포함하는 메세지 엘리먼트 데이터 구조를 포함하는, 컴퓨터 판독가능 기록매체.
  72. 제71항에 있어서,
    상기 논스 메세지 엘리먼트의 페이로드는, 복호화된 논스 (nonce) 값을 포함하는, 컴퓨터 판독가능 기록매체.
  73. 제71항에 있어서,
    상기 PNRP ID 배열 메세지 엘리먼트의 페이로드는, PNRP ID 배열 내의 엔트리들의 개수, 상기 배열의 총 길이, 각 배열 엔트리의 유형에 대한 식별자, 각 배열 엘리먼트의 길이, 및 PNRP ID들의 배열을 포함하는, 컴퓨터 판독가능 기록매체.
  74. PNRP 피어들을 선택하기 위해, 공인된 피어 어드레스(certified peer address: CPA)의 전파(propagation)를 포함하는 FLOOD 메세지를 포함하는 피어 투 피어 프로토콜 메세지를 생성하고 발송하기 위한 단계들을 수행하기 위한, 컴퓨터에 의해 실행가능한 명령의 프로그램을 기록한 컴퓨터 판독가능 기록매체에 있어서,
    상기 단계들은,
    피어 투 피어 네임 레졸루션 프로토콜(PNRP)에 사용하기 위한 FLOOD 메세지 데이터 구조를 생성하는 단계; 및
    상기 FLOOD 메세지 데이터 구조를 포함하는 상기 피어 투 피어 프로토콜 메세지를 발송하는 단계를 포함하고,
    상기 피어 투 피어 네임 레졸루션 프로토콜(PNRP)에 사용하기 위한 FLOOD 메세지 데이터 구조를 생성하는 단계는,
    PNRP 헤더(header) 메세지 엘리먼트를 갖는 제1 메세지 필드를 생성하는 단계;
    플러드 컨트롤즈(flood controls) 메세지 엘리먼트를 갖는 제2 메세지 필드를 생성하는 단계;
    CPA 베스트 매치(best match) 메세지 엘리먼트를 포함하는 제3 메세지 필드를 생성하는 단계;및
    IPV6 끝점 배열(IPV6 endpoint array) 메세지 엘리먼트를 포함하는 제4 메세지 필드를 생성하는 단계를 포함하는, 컴퓨터 판독가능 기록매체.
  75. 제74항에 있어서,
    각 메세지 엘리먼트는, 필드 ID(identification) 필드, 길이 필드, 및 페이로드를 포함하는 메세지 엘리먼트 데이터 구조를 포함하는, 컴퓨터 판독가능 기록매체.
  76. 제75항에 있어서,
    상기 플러드 컨트롤즈 메세지 엘리먼트의 페이로드는, 컨텍스트 고유의 플래그용 비트 필드, 및 상기 FLOOD 메세지를 개시하는 이유를 기술하는 이유 코드를 포함하는, 컴퓨터 판독가능 기록매체.
  77. 제75항에 있어서,
    상기 CPA 베스트 매치 메세지 엘리먼트의 페이로드는 암호화된 CPA를 포함하는 컴퓨터 판독가능 기록매체.
  78. 제75항에 있어서,
    상기 IPV6 끝점 배열 메세지 엘리먼트의 페이로드는, 배열 내의 엔트리들의 개수, 상기 배열의 총 길이, 각 배열 엔트리의 유형에 대한 식별자, 각 배열 엘리먼트의 길이, 및 상기 FLOOD 메세지가 전송된 각 노드 및 상기 FLOOD 메세지를 수신한 것으로 이미 알려진 각 노드에 대한 어드레스들의 배열을 포함하는, 컴퓨터 판독가능 기록매체.
  79. PNRP ID(identification)가 PNRP 노드에 등록됐는지를 판단하기 위한 요청을 포함하는 INQUIRE 메세지를 포함하는 피어 투 피어 프로토콜 메세지를 생성하고 발송하기 위한 단계들을 수행하기 위한, 컴퓨터에 의해 실행가능한 명령어의 프로그램을 기록한 컴퓨터 판독가능 기록매체에 있어서,
    상기 단계들은,
    피어 투 피어 네임 레졸루션 프로토콜(PNRP)에 사용되기 위한 INQUIRE 메세지 데이터 구조를 생성하는 단계; 및
    상기 INQUIRE 메세지 데이터 구조를 포함하는 상기 피어 투 피어 프로토콜 메세지를 발송하는 단계를 포함하고,
    상기 피어 투 피어 네임 레졸루션 프로토콜(PNRP)에 사용되기 위한 INQUIRE 메세지 데이터 구조를 생성하는 단계는,
    PNRP 헤더(header) 메세지 엘리먼트를 갖는 제1 메세지 필드를 생성하는 단계;
    플래그즈 필드(flags field) 메세지 엘리먼트를 갖는 제2 메세지 필드를 생성하는 단계; 및
    유효성검사 PNRP ID(validate PNRP identification) 메세지 엘리먼트를 포함하는 제3 메세지 필드 생성하는 단계를 포함하는, 컴퓨터 판독가능 기록매체.
  80. 제79항에 있어서,
    각 메세지 엘리먼트는, 필드 ID(identification) 필드, 길이 필드, 및 페이로드를 포함하는 메세지 엘리먼트 데이터 구조를 포함하는, 컴퓨터 판독가능 기록매체.
  81. 제80항에 있어서,
    상기 플래그즈 메세지 엘리먼트의 페이로드는, 컨텍스트 고유의 플래그용 비트 필드를 포함하는, 컴퓨터 판독가능 기록매체.
  82. 제80항에 있어서,
    상기 유효성검사 PNRP ID 메세지 엘리먼트의 페이로드는, 유효화 및 권한이 요청된 노드의 피어 네임의 해쉬 및 유효화 및 권한이 요청된 상기 노드의 알려진 서비스 어드레스로부터 도출된 서비스 위치를 포함하는, 컴퓨터 판독가능 기록매체.
  83. PNRP ID(identification)의 등록의 확인을 포함하는 AUTHORITY 메세지를 포함하는 피어 투 피어 프로토콜 메세지를 생성하고 발송하기 위한 단계들을 수행하기 위한, 컴퓨터에 의해 실행 가능한 명령어의 프로그램을 기록한 컴퓨터 판독가능 기록매체에 있어서,
    상기 단계들은,
    피어 투 피어 네임 레졸루션 프로토콜(PNPR)에 사용되기 위한 AUTHORITY 메세지 데이터 구조를 생성하는 단계; 및
    상기 AUTHORITY 메세지 데이터 구조를 포함하는 상기 피어 투 피어 프로토콜 메세지를 발송하는 단계를 포함하고,
    상기 피어 투 피어 네임 레졸루션 프로토콜(PNPR)에 사용되기 위한 AUTHORITY 메세지 데이터 구조를 생성하는 단계는,
    PNRP 헤더(header) 메세지 엘리먼트를 갖는 제1 메세지 필드를 생성하는 단계;
    PNRP 헤더 수신 확인(PNRP header acknowledged) 메세지 엘리먼트를 갖는 제2 메세지 필드를 생성하는 단계;
    분할 컨트롤즈(split controls) 메세지 엘리먼트를 포함하는 제3 메세지 필드를 생서하는 단계;
    플래그즈 필드(flags field) 메세지 엘리먼트를 포함하는 제4 메세지 필드를 생성하는 단계;
    유효성검사 PNRP ID(validate PNRP identification) 메세지 엘리먼트를 포함하는 제5 메세지 필드를 생성하는 단계;
    인증서 체인(certificate chain) 메세지 엘리먼트를 포함하는 제6 메세지 필드를 생성하는 단계;
    IPV6 추천 어드레스(referral address) 메세지 엘리먼트를 포함하는 제7 메세지 필드를 생성하는 단계;
    IPV6 추천 ID(referral identification) 메세지 엘리먼트를 포함하는 제8 메세지 필드를 생성하는 단계; 및
    분류자 메세지 엘리먼트를 포함하는 제9 메세지 필드를 생성하는 단계
    를 포함하는, 컴퓨터 판독가능 기록매체.
  84. 제83항에 있어서,
    각 메세지 엘리먼트는, 필드 ID(identification) 필드, 길이 필드, 및 페이로드를 포함하는 메세지 엘리먼트 데이터 구조를 포함하는, 컴퓨터 판독가능 기록매체.
  85. 제84항에 있어서,
    상기 PNRP 헤더 수신 확인 메세지 엘리먼트의 페이로드는, 수신확인된 메세지의 메세지 ID(identification)를 포함하는, 컴퓨터 판독가능 기록매체.
  86. 제84항에 있어서,
    상기 분할 컨트롤즈 메세지 엘리먼트의 페이로드는, 조각(segmentation)의 크기 및 상기 조각의 오프셋에 대한 정보를 포함하는, 컴퓨터 판독가능 기록매체.
  87. 제84항에 있어서,
    상기 플래그즈 필드 메세지 엘리먼트의 페이로드는, 컨텍스트 고유의 플래그용 비트 필드를 포함하는, 컴퓨터 판독가능 기록매체.
  88. 제84항에 있어서,
    상기 유효성검사 PNRP ID 메세지 엘리먼트의 페이로드는, 유효화 및 권한이 요청된 노드의 피어 네임 해쉬 및 유효화 및 권한이 요청된 상기 노드의 알려진 서비스 어드레스로부터 도출된 서비스 위치를 포함하는, 컴퓨터 판독가능 기록매체.
  89. 제84항에 있어서,
    상기 인증서 체인 메세지 엘리먼트의 페이로드는, PKCS7 암호화된 인증서 저장소를 포함하는, 컴퓨터 판독가능 기록매체.
  90. 제84항에 있어서,
    상기 IPV6 추천 어드레스 메세지 엘리먼트의 페이로드는, 노드 끝점에 대한 경로 플래그, IP 프로토콜 번호, IPV6 포트, 및 대체 노드의 어드레스로서의 IPV6 어드레스를 포함하는, 컴퓨터 판독가능 기록매체.
  91. 제84항에 있어서,
    상기 IPV6 추천 ID 메세지 엘리먼트의 페이로드는, 피어 네임의 해쉬 및 추천(referral)된 노드에 대한 서비스 위치를 포함하는, 컴퓨터 판독가능 기록매체.
  92. 제84항에 있어서,
    상기 분류자 메세지 엘리먼트의 페이로드는, 어드레스 배열 내의 엔트리들의 개수, 상기 배열의 총 길이, 각 배열 엔트리의 유형에 대한 식별자, 각 배열 엘리먼트의 길이 및 유니코드 문자열 배열을 포함하는 WCHAR 엘리먼트의 배열로서 암호화된, 피어 네임의 기초로서 사용되었던 유니코드 분류자 문자열(unicode classifier string)을 포함하는, 컴퓨터 판독가능 기록매체.
  93. 삭제
  94. 삭제
  95. 삭제
  96. 클라우드(cloud)들이 분할(split)되고 복구(repair)가 요구되는지에 대해 판단하기 위한 요청을 포함하는 REPAIR 메세지를 포함하는 피어 투 피어 프로토콜 메세지를 생성하고 발송하기 위한 단계들을 수행하기 위한, 컴퓨터에 의해 실행가능한 명령의 프로그램을 기록한 컴퓨터 판독가능 기록매체에 있어서,
    상기 단계들은,
    피어 투 피어 네임 레졸루션 프로토콜(PNRP)에 사용되기 위한 REPAIR 메세지 데이터 구조를 생성하는 단계; 및
    상기 REPAIR 메세지 데이터 구조를 포함한 상기 피어 투 피어 프로토콜 메세지를 발송하는 단계를 포함하고,
    상기 피어 투 피어 네임 레졸루션 프로토콜(PNRP)에 사용되기 위한 REPAIR 메세지 데이터 구조를 생성하는 단계는,
    PNRP 헤더(header) 메세지 엘리먼트를 포함하는 제1 메세지 필드를 생성하는 단계;
    타겟 PNRP ID(target PNRP identification) 메세지 엘리먼트를 포함하는 제2 메세지 필드를 생성하는 단계;
    캐쉬 레벨(cache level) 메세지 엘리먼트를 포함하는 제3 메세지 필드를 생성하는 단계; 및
    IPV6 끝점(endpoint) 메세지 엘리먼트를 포함하는 제4 메세지 필드를 생성하는 단계를 포함하는, 컴퓨터 판독가능 기록매체.
  97. 제96항에 있어서,
    각 메세지 엘리먼트는 필드 ID 필드, 길이 필드, 및 페이로드를 포함하는 메세지 엘리먼트 데이터 구조를 포함하는 컴퓨터 판독가능 기록매체.
  98. 제97항에 있어서,
    상기 타겟 PNRP ID 메세지 엘리먼트는 타겟 피어의 피어 네임 해쉬 및 알려진 서비스 어드레스로부터 도출된 서비스 위치를 포함하는 컴퓨터 판독가능 기록매체.
  99. 제97항에 있어서,
    상기 캐쉬 레벨 메세지 엘리먼트의 페이로드는, 복구를 실행할 때 어떤 캐쉬 레벨이 사용되는지를 식별하는 캐쉬 레벨 번호를 포함하는 컴퓨터 판독가능 기록매체.
  100. 제50항에 있어서,
    상기 CPA 베스트 매치 메세지 엘리먼트는 암호화된(encoded) CPA를 포함하는, 컴퓨터 판독가능 기록매체.
  101. 피어 투 피어 네트워크(peer-to-peer network)에서 제1 노드에 피어 노드들의 ID(identification)을 제공하는 방법으로서,
    제2 노드에서, PNRP ID들을 요청하는 상기 제1 노드로부터 SOLICIT 메세지를 수신하는 단계 - 상기 SOLICIT 메세지는 적어도 헤더 메세지 엘리먼트 및 해쉬 논스(hashed nonce) 엘리먼트를 포함함 -;
    상기 제2 노드에서, ADVERTISE 메세지를 생성하는 단계 - 상기 ADVERTISE 메세지는 적어도 헤더 수신확인(header acknowledged) 메세지 엘리먼트, 상기 해쉬 논스 메세지 엘리먼트 및 PNRP ID 배열 메세지 엘리먼트를 포함하고, 상기 PNRP ID 배열 메세지 엘리먼트는 상기 제2 노드의 캐시에서의 PNRP ID들의 리스트로부터의 분산된 선정(distributed selection)을 포함함 -; 및
    상기 제1 노드로 상기 ADVERTISE 메세지를 발송하는 단계
    를 포함하는, 방법.
KR1020040043115A 2003-06-13 2004-06-11 피어 투 피어 네임 레졸루션 와이어 프로토콜 및 프로토콜에 사용하기 위한 메세지 포맷 데이터 구조를 생성 및 발송하기 위한 방법 및 컴퓨터 판독가능 기록매체 KR101021360B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/461,940 US7533184B2 (en) 2003-06-13 2003-06-13 Peer-to-peer name resolution wire protocol and message format data structure for use therein
US10/461,940 2003-06-13

Publications (2)

Publication Number Publication Date
KR20040107420A KR20040107420A (ko) 2004-12-20
KR101021360B1 true KR101021360B1 (ko) 2011-03-14

Family

ID=33299879

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020040043115A KR101021360B1 (ko) 2003-06-13 2004-06-11 피어 투 피어 네임 레졸루션 와이어 프로토콜 및 프로토콜에 사용하기 위한 메세지 포맷 데이터 구조를 생성 및 발송하기 위한 방법 및 컴퓨터 판독가능 기록매체

Country Status (14)

Country Link
US (1) US7533184B2 (ko)
EP (2) EP1487180B1 (ko)
JP (1) JP4786882B2 (ko)
KR (1) KR101021360B1 (ko)
CN (1) CN1574840B (ko)
AU (1) AU2004202255B8 (ko)
BR (1) BRPI0401924A (ko)
CA (1) CA2465997C (ko)
HK (1) HK1071252A1 (ko)
MX (1) MXPA04005718A (ko)
MY (1) MY140075A (ko)
RU (1) RU2385488C2 (ko)
TW (2) TWI379548B (ko)
ZA (1) ZA200403431B (ko)

Families Citing this family (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7065587B2 (en) * 2001-04-02 2006-06-20 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) and multilevel cache for use therewith
DE60211524T2 (de) * 2001-08-04 2006-12-14 Kontiki, Inc., Sunnyvale Verfahren und vorrichtung zur verteilten lieferung von inhalten innerhalb eines computernetzwerkes
US20040267875A1 (en) * 2003-06-30 2004-12-30 Hennessey Wade L. Method and apparatus for establishing peering rules for distributed content delivery
US7450524B2 (en) * 2003-06-30 2008-11-11 Kontiki, Inc. Method and apparatus for determining network topology in a peer-to-peer network
WO2005022397A1 (en) * 2003-08-28 2005-03-10 Trihedron Co., Ltd. Method of data synchronization in multiplayer network games
US7546357B2 (en) * 2004-01-07 2009-06-09 Microsoft Corporation Configuring network settings using portable storage media
US20050193106A1 (en) * 2004-03-01 2005-09-01 University Of Florida Service discovery and delivery for ad-hoc networks
US7747797B2 (en) * 2004-09-28 2010-06-29 Microsoft Corporation Mass storage device with near field communications
US7848332B2 (en) * 2004-11-15 2010-12-07 Cisco Technology, Inc. Method and apparatus for classifying a network protocol and aligning a network protocol header relative to cache line boundary
EP1834230A1 (en) * 2004-12-30 2007-09-19 Samsung Electronics Co., Ltd. A terminal data format and a communication control system and method using the terminal data format
US7647394B2 (en) * 2005-02-15 2010-01-12 Microsoft Corporation Scaling UPnP v1.0 device eventing using peer groups
US7640329B2 (en) * 2005-02-15 2009-12-29 Microsoft Corporation Scaling and extending UPnP v1.0 device discovery using peer groups
US7543023B2 (en) * 2005-03-15 2009-06-02 Microsoft Corporation Service support framework for peer to peer applications
US7493413B2 (en) * 2005-03-15 2009-02-17 Microsoft Corporation APIS to build peer to peer messaging applications
US7912959B2 (en) * 2005-03-15 2011-03-22 Microsoft Corporation Architecture for building a peer to peer messaging platform
US20060239206A1 (en) * 2005-04-22 2006-10-26 Microsoft Corporation Apparatus and method for network identification among multiple applications
US7788378B2 (en) * 2005-04-22 2010-08-31 Microsoft Corporation Apparatus and method for community relay node discovery
US7817647B2 (en) * 2005-04-22 2010-10-19 Microsoft Corporation Flower-petal resolutions for PNRP
US7616594B2 (en) * 2005-04-22 2009-11-10 Microsoft Corporation Wireless device discovery and configuration
US7571228B2 (en) * 2005-04-22 2009-08-04 Microsoft Corporation Contact management in a serverless peer-to-peer system
US20060242235A1 (en) * 2005-04-22 2006-10-26 Microsoft Corporation Presence monitoring in a serverless peer-to-peer system
US7603482B2 (en) * 2005-04-22 2009-10-13 Microsoft Corporation DNS compatible PNRP peer name encoding
US8036140B2 (en) * 2005-04-22 2011-10-11 Microsoft Corporation Application programming interface for inviting participants in a serverless peer to peer network
WO2006120530A2 (en) * 2005-05-06 2006-11-16 Nokia Corporation Mechanism to discover 802.21 remote events and information services
JP2006319909A (ja) * 2005-05-16 2006-11-24 Konica Minolta Holdings Inc データ通信の方法、ピアツーピア型のネットワーク、および情報処理装置
US8230221B2 (en) * 2005-08-15 2012-07-24 Telefonaktiebolaget L M Ericsson (Publ) Routing advertisement authentication in fast router discovery
US7594031B2 (en) * 2005-09-15 2009-09-22 Microsoft Corporation Network address selection
US20070073859A1 (en) * 2005-09-29 2007-03-29 Microsoft Corporation Peer name resolution and discovery
US8255546B2 (en) * 2005-09-30 2012-08-28 Microsoft Corporation Peer name resolution protocol simple application program interface
US7797427B2 (en) * 2005-12-13 2010-09-14 Cisco Technology, Inc. System and method for applying a communication feature extension
US8108548B2 (en) * 2005-12-22 2012-01-31 Microsoft Corporation Methodology and system for file replication based on a peergroup
DE602005021134D1 (de) * 2005-12-22 2010-06-17 Microsoft Corp Peer-to-Peer-Nachrichtenformat
US20070204003A1 (en) * 2006-02-28 2007-08-30 Maven Networks, Inc. Downloading a file over HTTP from multiple servers
GB0606071D0 (en) * 2006-03-27 2006-05-03 Siemens Ag Indication of dtm handover command
FR2903268A1 (fr) * 2006-06-30 2008-01-04 Thomson Licensing Sas Procede de reception de services audio/video, terminal et systeme correspondants
US8489701B2 (en) * 2007-01-30 2013-07-16 Microsoft Corporation Private virtual LAN spanning a public network for connection of arbitrary hosts
US8982887B2 (en) * 2007-05-18 2015-03-17 International Business Machines Corporation System, method and program for making routing decisions
US9838365B2 (en) * 2007-07-10 2017-12-05 Qualcomm Incorporated Peer to peer identifiers
US20090055346A1 (en) * 2007-08-23 2009-02-26 Yahoo! Inc. Scalable Ticket Generation in a Database System
US7729366B2 (en) * 2007-10-03 2010-06-01 General Instrument Corporation Method, apparatus and system for network mobility of a mobile communication device
US20090116579A1 (en) * 2007-11-02 2009-05-07 Arya Abraham Interprocessor communication link for a load control system
US8429715B2 (en) * 2008-08-08 2013-04-23 Microsoft Corporation Secure resource name resolution using a cache
US8699377B2 (en) * 2008-09-04 2014-04-15 Trilliant Networks, Inc. System and method for implementing mesh network communications using a mesh network protocol
EP2338256A4 (en) * 2008-09-17 2012-03-28 Vuze Inc ASSOCIATIVE PREPARATION OF MULTIMEDIA SUBSCRIPTIONS
US9900779B2 (en) * 2008-12-30 2018-02-20 Qualcomm Incorporated Centralized control of peer-to-peer communication
US8228822B2 (en) * 2009-03-03 2012-07-24 Cisco Technology, Inc. Hierarchical flooding among peering overlay networks
US20100293223A1 (en) * 2009-05-18 2010-11-18 Cisco Technology, Inc. Limiting storage messages in peer to peer network
US9325787B2 (en) * 2009-05-18 2016-04-26 Cisco Technology, Inc. Limited broadcast, peering among DHTs, broadcast put of limited content only
US8729814B2 (en) 2009-11-25 2014-05-20 Lutron Electronics Co., Inc. Two-wire analog FET-based dimmer switch
US9083541B1 (en) * 2010-07-29 2015-07-14 Crimson Corporation Retransmitting lost packets for multicast data distribution
US9148390B2 (en) 2010-08-04 2015-09-29 Alcatel Lucent System and method for virtual chassis split prevention
US9781205B2 (en) * 2011-09-12 2017-10-03 Microsoft Technology Licensing, Llc Coordination engine for cloud selection
WO2013100959A1 (en) * 2011-12-28 2013-07-04 Intel Corporation Processor accelerator interface virtualization
KR102005771B1 (ko) 2012-02-24 2019-10-01 삼성전자주식회사 무선 통신 네트워크에서 ｉｐ 주소 할당 방법 및 장치
US9130907B2 (en) * 2012-05-01 2015-09-08 Harris Corporation Switch for communicating data in a dynamic computer network
US9444564B2 (en) 2012-05-10 2016-09-13 Qualcomm Incorporated Selectively directing media feeds to a set of target user equipments
US9277013B2 (en) * 2012-05-10 2016-03-01 Qualcomm Incorporated Storing local session data at a user equipment and selectively transmitting group session data to group session targets based on dynamic playback relevance information
KR101689096B1 (ko) * 2012-11-12 2017-01-02 알까뗄 루슨트 네트워크 노드 및 관리 액션이 가상 섀시 스플릿을 트리거한다는 경고를 발행할지의 여부가 결정되는 가상 섀시 시스템에서 동작가능한 노드에서의 방법
US10530684B2 (en) * 2015-05-19 2020-01-07 International Business Machines Corporation Management of unreachable OpenFlow rules
US10394798B1 (en) 2015-12-07 2019-08-27 Gravic, Inc. Method of ensuring transactional integrity of a system that includes a first subsystem and a second subsystem
US9760598B1 (en) * 2015-12-07 2017-09-12 Gravic, Inc. Method of ensuring real-time transaction integrity in the cloud
US10452648B1 (en) 2015-12-07 2019-10-22 Gravic, Inc. Method of ensuring transactional integrity of a system that includes a plurality of subsystems, one of which takes an action upon a loss of transactional integrity
US9922074B1 (en) 2015-12-07 2018-03-20 Gravic, Inc. Method of ensuring real-time transaction integrity in the indestructible scalable computing cloud
US11567818B2 (en) * 2016-04-26 2023-01-31 Akimbo Technologies Inc. Method of detecting faults in a fault tolerant distributed computing network system
ES2921983T3 (es) * 2018-03-16 2022-09-05 Acklio Método y aparato para procesar datos de mensaje
US11277305B2 (en) * 2019-10-09 2022-03-15 Qualcomm Incorporated Edge discovery techniques in wireless communications systems
CN111010274B (zh) * 2019-12-30 2022-08-12 烽火通信科技股份有限公司 一种安全低开销的SRv6实现方法
US12057966B2 (en) * 2021-03-09 2024-08-06 Arista Networks, Inc. Packet forwarding between hybrid tunnel endpoints

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020174125A1 (en) * 2001-03-14 2002-11-21 Microsoft Corporation Messaging infrastructure for identity-centric data access
US20030055892A1 (en) * 2001-09-19 2003-03-20 Microsoft Corporation Peer-to-peer group management and method for maintaining peer-to-peer graphs

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03204748A (ja) * 1990-01-08 1991-09-06 Hitachi Ltd Ｏｓｉ電文組立方式
US5586264A (en) * 1994-09-08 1996-12-17 Ibm Corporation Video optimized media streamer with cache management
US5987376A (en) * 1997-07-16 1999-11-16 Microsoft Corporation System and method for the distribution and synchronization of data and state information between clients in a distributed processing system
US6205481B1 (en) * 1998-03-17 2001-03-20 Infolibria, Inc. Protocol for distributing fresh content among networked cache servers
US6269099B1 (en) * 1998-07-01 2001-07-31 3Com Corporation Protocol and method for peer network device discovery
US6898200B1 (en) * 1999-10-29 2005-05-24 Nortel Networks Limited Method for improving signaling efficiency and performing service load balancing in a connection oriented network
US6748420B1 (en) * 1999-11-23 2004-06-08 Cisco Technology, Inc. Methods and apparatus for providing shared access to an application
US7031268B1 (en) * 2000-05-17 2006-04-18 Cisco Technology, Inc. Call optimization in ad-hoc conference calls
JP2001326632A (ja) * 2000-05-17 2001-11-22 Fujitsu Ltd 分散グループ管理システムおよび方法
EP1162788B1 (en) * 2000-06-09 2012-11-21 Broadcom Corporation Trunking and mirroring across stacked gigabit switches
US6636854B2 (en) * 2000-12-07 2003-10-21 International Business Machines Corporation Method and system for augmenting web-indexed search engine results with peer-to-peer search results
US6826198B2 (en) * 2000-12-18 2004-11-30 Telefonaktiebolaget Lm Ericsson (Publ) Signaling transport protocol extensions for load balancing and server pool support
US20040213220A1 (en) * 2000-12-28 2004-10-28 Davis Arlin R. Method and device for LAN emulation over infiniband fabrics
US7197565B2 (en) * 2001-01-22 2007-03-27 Sun Microsystems, Inc. System and method of using a pipe advertisement for a peer-to-peer network entity in peer-to-peer presence detection
US7065587B2 (en) 2001-04-02 2006-06-20 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) and multilevel cache for use therewith
US7272636B2 (en) * 2001-04-24 2007-09-18 Sun Microsystems, Inc. Peer group name server
US6961723B2 (en) * 2001-05-04 2005-11-01 Sun Microsystems, Inc. System and method for determining relevancy of query responses in a distributed network search mechanism
US7299351B2 (en) * 2001-09-19 2007-11-20 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) security infrastructure and method
US7068789B2 (en) * 2001-09-19 2006-06-27 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) group security infrastructure and method
US6674459B2 (en) * 2001-10-24 2004-01-06 Microsoft Corporation Network conference recording system and method including post-conference processing
US7177929B2 (en) * 2002-03-27 2007-02-13 International Business Machines Corporation Persisting node reputations in transient network communities
US6912622B2 (en) * 2002-04-15 2005-06-28 Microsoft Corporation Multi-level cache architecture and cache management method for peer-to-peer name resolution protocol
US7206862B2 (en) * 2002-04-24 2007-04-17 Microsoft Corporation Method and apparatus for efficiently matching responses to requests previously passed by a network node
US7051102B2 (en) * 2002-04-29 2006-05-23 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) security infrastructure and method
US20040181487A1 (en) * 2003-03-10 2004-09-16 Microsoft Corporation Digital media clearing house platform
US7577750B2 (en) * 2003-05-23 2009-08-18 Microsoft Corporation Systems and methods for peer-to-peer collaboration to enhance multimedia streaming
US7454465B2 (en) * 2004-03-26 2008-11-18 Microsoft Corporation Real-time collaboration and communication in a peer-to-peer networking infrastructure

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020174125A1 (en) * 2001-03-14 2002-11-21 Microsoft Corporation Messaging infrastructure for identity-centric data access
US20030055892A1 (en) * 2001-09-19 2003-03-20 Microsoft Corporation Peer-to-peer group management and method for maintaining peer-to-peer graphs

Also Published As

Publication number Publication date
CA2465997A1 (en) 2004-12-13
EP1487180B1 (en) 2014-06-04
ZA200403431B (en) 2005-07-27
RU2004117797A (ru) 2006-01-10
JP4786882B2 (ja) 2011-10-05
RU2385488C2 (ru) 2010-03-27
AU2004202255B8 (en) 2010-01-07
CN1574840A (zh) 2005-02-02
AU2004202255B2 (en) 2009-12-03
MY140075A (en) 2009-11-30
TWI379548B (en) 2012-12-11
JP2005004777A (ja) 2005-01-06
CA2465997C (en) 2016-02-23
AU2004202255A1 (en) 2005-01-06
TW200843412A (en) 2008-11-01
CN1574840B (zh) 2010-07-14
HK1071252A1 (en) 2005-07-08
EP1487180A2 (en) 2004-12-15
MXPA04005718A (es) 2005-03-23
BRPI0401924A (pt) 2005-01-25
EP1487180A3 (en) 2011-08-31
TW200503475A (en) 2005-01-16
KR20040107420A (ko) 2004-12-20
US7533184B2 (en) 2009-05-12
US20050004916A1 (en) 2005-01-06
EP2584764A1 (en) 2013-04-24
TWI339518B (en) 2011-03-21

Similar Documents

Publication Publication Date Title
KR101021360B1 (ko) 피어 투 피어 네임 레졸루션 와이어 프로토콜 및 프로토콜에 사용하기 위한 메세지 포맷 데이터 구조를 생성 및 발송하기 위한 방법 및 컴퓨터 판독가능 기록매체
US7051102B2 (en) Peer-to-peer name resolution protocol (PNRP) security infrastructure and method
US7336623B2 (en) Peer-to-peer cloud-split detection and repair methods
US20120036564A1 (en) Peer enrollment method, route updating method, communication system, and relevant devices
Ford UIA: A global connectivity architecture for mobile personal devices
CN103546439B (zh) 内容请求的处理方法及装置

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20140217

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20150217

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20160218

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20170220

Year of fee payment: 7

LAPS Lapse due to unpaid annual fee