CN1574840B - 对等名称解析电信协议及在此使用的消息格式数据结构 - Google Patents

对等名称解析电信协议及在此使用的消息格式数据结构 Download PDF

Info

Publication number
CN1574840B
CN1574840B CN2004100489300A CN200410048930A CN1574840B CN 1574840 B CN1574840 B CN 1574840B CN 2004100489300 A CN2004100489300 A CN 2004100489300A CN 200410048930 A CN200410048930 A CN 200410048930A CN 1574840 B CN1574840 B CN 1574840B
Authority
CN
China
Prior art keywords
node
message
pnrp
cpa
parsing
Prior art date
Legal status (The legal status 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 status listed.)
Expired - Fee Related
Application number
CN2004100489300A
Other languages
English (en)
Other versions
CN1574840A (zh
Inventor
J·L·米勒
H·拉瓦斯
R·塞米奥尼斯克
B·刘艾伦
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
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 Microsoft Corp filed Critical Microsoft Corp
Publication of CN1574840A publication Critical patent/CN1574840A/zh
Application granted granted Critical
Publication of CN1574840B publication Critical patent/CN1574840B/zh
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

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

呈现了一种用于一种对等名称解析协议中的消息的可扩展的数据结构。这一消息数据结构利用许多字段，每个字段都包含一个消息元素。较佳的是，第一个字段是消息头，包括协议信息并标识消息的类型。每个消息元素都包含许多字段。这些消息元素字段包括一个类型字段、一个长度字段和该消息元素的内容或载荷。在某一实施例中，为恰当运行对等名称解析协议(PNRP)，至少要十个消息来构成，包括“解析”、“回应”、“恳求”、“广告”、“请求”、“充溢”、“查询”、“授权”、“应答”和“修复”消息。

Description

对等名称解析电信协议及在此使用的消息格式数据结构
技术领域
本发明一般涉及对等架构中的通信协议，特别涉及某种对等图中实现结构化通信的消息格式数据结构。
背景技术
互联网上的多种通信技术使具有共同兴趣的用户能协同工作、共享文件、互相聊天、组播音频与视频进行演示及小组会议，以及参加多玩家的游戏。但是现在，互联网上多数的通信是发生在某种服务器为中心的环境中的，在这种环境中所有的通信都流向或流经大的中央服务器，个人可以连接到这些服务器以加入或参加这样的通信。
随着对等技术的重新出现，当前的互联网通信以服务器为中心的模式正在被迅速替代。确实，对等技术使用户能在没有服务器的环境中互相联络，而从基于服务器的互联网通信的限制中解放出来。在一个基于对等的系统中，由于通信是直接在网络中同等点之间发生的，用户的匿名与隐私就得以维护。但是，尽管个别的通信和文件共享在对等网络中相对是很好设立的，设立、发现、加入、维护及共享信息在对等环境中却不是很好设立的。
对等通信，以及实际上所有类型的通信，都依赖于在选定的实体或节点间建立有效连接的可能性。这些实体或节点可以是同等点(如用户或机器)或在一个对等网络中形成的组。这些节点之间的连接形成了对等图，使通信及信息可以传递向这些节点，或在这些节点之间传递。但是，实体可能具有会变化的一个或几个地址，因为实体会在网络中移动，拓扑会变化，租赁的地址不能续租，组的功能或目的变化，等等。对于这种寻址问题的一种经典的架构解决办法是对每个实体赋一个稳定的名称，并在需要连接的时候将这个名称“解析”成某个当前的地址。这一名称到地址的转化必须非常鲁棒，还必须能够容易且快速地更新。
为了增加那些寻求连接到某个实体的实体找到该实体地址的可能性，许多对等协议允许实体通过多种机制公布其个别或组地址。有些协议还允许客户端通过处理来自网络中其它客户端的请求来获取其它实体地址的知识。确实，这样的地址知识的获取通过维护一个鲁棒的图实现了这些对等网络的成功运作。也就是说，关于网络中其它同等点或组的信息越好(即图越鲁棒)，对某特定资源或记录的检索能命中的可能性就越大。
如在某个以服务器为中心的环境中一样，对等图可以完全开放以实现在该图内检索与共享互联网文件。但是，由于对等网络是作为一个分布用户或同等点的图而构成的，在网络内所有同等点认识所共享的信息之前，必需将通信和数据(记录)从一个同等点传递给另一个。提供这样的路由的系统包括Usenet和OSPF。然而，这样的现有系统受到那些到现在为止已限制了对等技术的充分发展的局限的困扰。而且，对等网络现在受到缺乏适当的图管理的困扰，图管理有时在某个成员离开组时能使图“断裂”或分离。在这一情况下，来自该图的某一部分的信息可能不再能传递给由于同等点之一的离开所产生分隔的另一端的对等成员。此外的一个缺点是，不存在适当的机制来探测这样的分隔。
除了在已有技术中存在的功能问题之外，网络流量的数量也会轻易地淹没参与在网络中的同等点。消息大小与结构使同等点快速处理消息的能力变得复杂，并且在网络的大小增长时导致通信的延误或丢弃。
所以，在已有技术中就存在对一种能解决上述的以及在已有技术中存在的其它问题的对等消息协议和数据结构的需求。
发明内容
在本申请中所披露的发明性概念包括一种适用于一种对等名称解析协议的可扩展的消息数据结构。这一消息数据结构利用消息数据字段来构建用于PNRP的多种消息。这些消息数据字段的每一个都包含一个消息元素。较佳的是，第一个字段是消息头元素，包括协议信息并标识消息的类型。
至于消息本身，每个消息元素都包含许多消息元素数据字段。这些消息元素字段包括一个类型字段、一个长度字段和该消息元素的内容或载荷。类型字段包括一个指定消息元素的类型的标识符。长度字段标识了包括字段类型和长度字段的该消息元素的长度。
在某一实施例中，为恰当运行对等名称解析协议(PNRP)，至少要十个消息来构成。这十个消息包括一个“解析”消息、一个“回应”消息、一个“恳求”消息、一个“广告”消息、一个“请求”消息、一个“充溢”消息、一个“查询”消息、一个“授权”消息、一个“应答”消息和一个“修复”消息。这些消息是以在某一较佳实施例中所存在的二十二种不同消息元素构建的。
附图说明
所附录并且构成本说明一部分的附图例示了本发明的几个方面，并且与描述一起，用来解释本发明的原则。在这些附图中：
图1是一幅一般性地例示本发明所存属的一个示例性计算机系统的框图；
图2是一幅例示对等名称解析协议(PNRP)的功能元素的简化框图；
图3是一幅例示本发明的一个方面的协议消息流图；
图4是一幅例示本发明的另一个方面的协议消息流图；
图5是一幅例示本发明的可扩展数据结构模型的数据结构图，该模型实现构造本发明的消息；
图6是一幅例示构造本发明的一个示例性消息的简化数据结构图；
尽管本发明将联系某些较佳实施例来描述，但我们并无意将本发明限制于那些实施例。相反的是，我们的意图是覆盖包括在如所附权利要求所定义的本发明的精神和范围内的所有的可替换方法、修改和等价物。
具体实施方式
参见附图(其中同样的索引编号表示同样的元素)，本发明被例示成是实现在一个适当的计算环境中。尽管并不需要，但本发明将在计算机可执行指令的一般上下文中描述，例如由个人计算机执行的程序模块。一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的过程、程序、对象、组件、数据结构等。而且，相关技术的行家将了解本发明可以以其它计算机系统配置来实施，包括手持设备、多处理器系统、基于微处理器的或可编程的消费电子品、网络PC、小型计算机、大型计算机等等。本发明还可以在分布式计算环境中实施，在分布式计算环境中任务是由通过某种通信网络相联接的远端处理设备来执行。在一个分布式计算环境中，程序模块可以位于本地和远端内存存储设备上。
图1例示了一个本发明可以在其中实现的合适的计算系统环境100的一个示例。计算系统环境100只是合适的计算环境的一个例子，而不是打算建议关于本发明的使用或功能范围的任何限制。计算环境100不应当解读成对在该示例性操作环境100中所例示的任一部件或其组合具有任何依赖或要求。
本发明可运作于多种其它通用或专用计算系统环境或配置。可以适用于本发明的众所周知的计算系统、环境和/或配置的例子包括(但不限于)个人计算机、服务器计算机、手持或膝上设备、多处理器系统、基于微处理器的系统、机顶盒、可编程消费电子品、网络PC、小型计算机、大型计算机、包括任何以上系统或设备的分布式计算系统，等等。
本发明可以以计算机可执行指令的一般上下文来描述，例如由计算机执行的程序模块。一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的过程、程序、对象、组件、数据结构等。本发明还可以在分布式计算环境中实现，在分布式环境中任务是由通过某种通讯网络相联接的远端处理设备来执行。在分布式计算环境中，程序模块可以位于包括内存存储设备的本地或远端计算机存储媒介中。
参照图1，一个用于实现本发明的示例性系统包括一台计算机110形式的通用计算设备。计算机110的部件可以包括(但不限于)一个处理单元120、一个系统内存130，以及一个将包括系统内存的多个系统部件连接到处理单元120的系统总线121。系统总线121可以是几种总线架构之一，包括内存总线或内存控制器、外围设备总线，以及使用多种总线架构之一的局部总线。举例而言(但非限制)，这样的架构包括工业标准架构(ISA)总线、微通道架构(MCA)总线、增强ISA(EISA)总线、视频电子标准协会(VESA)局部总线，以及也称为Mezzanine总线的外围部件互连(PCI)总线。
计算机110一般包括多种计算机可读取媒介。计算机可读取媒介可以是能由计算机110所访问的任何可用的媒介，包括易失和不易失媒介、可移动和不可移动媒介。举例来说(但非限制)，计算机可读取媒介可以由计算机存储媒介和通讯媒介组成。计算机存储媒介包括以任何存储信息(如计算机可读取指令、数据结构、程序模块或其它数据)的方法或技术实现的易失和不易失媒介、可移动和不可移动媒介。计算机存储媒介包括(但不限于)RAM、ROM、EEPROM、闪存或其它内存技术、CD-ROM、数字万用盘(DVD)或其它光盘存储器、盒式磁带、磁带、磁盘存储器或其它磁存储设备，或可用以存储所需要信息并能由计算机110访问的任何其它媒介。通讯媒介一般将计算机可读取指令、数据结构、程序模块或其它数据实现在某种调制了的数据信号中，如某种载波或其它传输机制，并包括任何信息传递媒介。术语“调制了的数据信号”意指某种信号，其一个或多个特征可以某种方式设置或改变，以便将信息编码到该信号中。举例而言(但非限制)，通讯媒介包括联线媒介(如联线网络或直接线缆连接)和无线媒介(如声音、FR、红外或其它无线媒介)。以上的任意组合也应当包括在计算机可读取媒介的范围内。
系统存储器130包括易失和/或非易失内存形式的计算机存储媒介，如只读存储器(ROM)131和随机访问存储器(RAM)132。在ROM 131中一般存储了一个基本输入/输出系统133(BIOS)，含有(如在启动时)帮助在计算机110内各元件间传递信息的基本过程。RAM 132一般包含可由处理单元120立即访问和/或当前在处理单元120上执行的数据和/或程序模块。举例而言(但非限制)，图1例示了操作系统134、应用程序135、其它程序模块136、以及程序数据137。
计算机110还可以包括其它可移动/不可移动的、易失/不易失的计算机存储媒介。仅举例而言，图1例示了一个读写不可移动不易失磁媒介的硬盘驱动器141、一个读写可移动不易失磁盘152的磁盘驱动器151，以及一个读写可移动非易失光盘156(如CDROM或其它光媒介)的光盘驱动器155。其它可以用于该示例性操作环境的可移动/不可移动、易失/不易失计算机存储媒介包括(但不限于)盒式磁带、闪存卡、数字万用盘、数字录影带、固态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不同的编号，是为了例示至少它们是不同的拷贝。用户可以通过输入设备如键盘162和指点设备161(一般指鼠标、轨迹球或触摸板)来将命令和信息输入计算机110。其它输入设备(未示出)可以包括麦克风、游戏杆、游戏手柄、卫星天线、扫描仪等等。这些及其它输入设备通常通过一个与系统总线相连的用户输入接口160来连接到处理单元120，但也可以由其它接口和总线结构来连接，如并口、游戏口或通用串行总线(USB)。监视器191或其它类型的显示设备也通过一个接口(如视频接口190)来连接到系统总线121。除监视器以外，计算机还可以包括通过输出外围接口195连接的其它外围输出设备(如扬声器197和打印机196)。
计算机110可以在某个与一台或多台远端计算机(如远端计算机180)逻辑连接的联网环境中运行。远端计算机180可以是另一台个人计算机、服务器、路由器、网络PC、对等设备或其它普通网络节点，并且一般包括在上面关于个人计算机110所描述的多个或所有元件(尽管在图1中只例示了一个内存存储设备181)。在图1中所描述的逻辑连接包括局域网(LAN)171和广域网(WAN)173，但也可以包括其它网络。在办公室、企业范围的计算机网络、内联网和互联网中，这样的联网环境是很普遍的。
当在LAN联网环境中使用时，个人计算机110通过一个网络接口或适配器170连接到LAN 171。当在WAN联网环境中使用时，计算机110一般包括调制解调器172或其它用于在广域网173(如互联网)上建立通信的手段。调制解调器172(可以是内置的或外置的)可以通过用户输入接口160或其它合适的机制连接到系统总线121。在联网环境中，关于个人计算机110(或其各部分)所描述的程序模块可以存储在远端内存存储设备中。举例而言(并非限制)，图1将远端应用程序185例示为驻留在内存设备181上。可以了解，所示出的网络连接是示例性的，还可以使用在计算机间建立通讯链路的其它手段。
在下面的描述中，除非另外指明，本发明将引述由一台或多台计算机所执行的动作和操作的符号表示来描述。这样，就能理解这样的有时被指出是由计算机执行的动作和操作包括由该计算机的处理单元操作以某种结构化形式表示数据的电子信号。这一操作在该计算机的内存系统中转换或维护数据，这些数据以相关技术的行家所充分理解的方式重新配置或者改变该计算机的运行。维护数据的数据结构就是具有由数据格式所定义的特定属性的内存物理位置。但是，尽管本发明是在前面的上下文中描述的，但并不限制如相关技术的行家所了解的那样，此后所描述的多种动作和操作也可以在硬件中实现。
如上面所介绍的那样，对等(P2P)协议的成功依赖于该协议在选定的实体之间建议有效连接的能力。同样，在这一P2P网络中组的形成也依赖于这一能力。由于某个特定用户可能在具有不同地址的多个地点以多种方式连接入网络，一个较佳的方法是为该用户或组赋一个唯一的标识，而后通过该协议将该标识解析成一个或多个特定地址。这样一个当前发明的标识管理系统及方法所特别适用于的对等名称解析协议(PNRP)在同时未决的申请编号09/942164(题为对等名称解析协议(PNRP)及与之使用的多层缓存，2001年8月29日入档)、同时未决的申请编号10/122863(题为用于对等名称解析协议(PNRP)的多层缓存架构和缓存管理方法，2002年4月15日入档)和同时未决的申请编号09/955923(题为用于维护对等图的对等组管理及方法，2001年9月19日入档)中都有所描述，这些申请的教义和揭示都通过索引在此完整附录。
同样，同时未决的申请编号09/956260(题为对等名称解析协议(PNRP)安全基础架构及方法，2001年9月19日入档)描述了一个根本的安全基础架构，能确保网络内多个实体的标识有效，而不会不必要地以过度的流量增加网络负担。在P2P分组环境中，同时未决的申请编号09/955924(题为对等名称解析协议(PNRP)组安全基础架构及方法，2001年9月19日入档)描述了用于这样的组的根本的安全基础架构。这些申请的教义和揭示也都通过索引在此完整附录。但是，尽管本发明的接口与方法特别适用于和互操作于这样的PNRP，相关技术的行家将认识到本发明并不因而被限制，而是适用于希望提供P2P图管理功能的任何P2P系统或协议。
如在上面所附的描述PNRP并提供某些有用背景的同时未决申请中所讨论的那样，对等名称解析协议(PNRP)是一个基于同等点的名称到地址解析协议。同等点资源可以被赋予一个同等点名称。某个应用可以以PNRP注册一个同等点名称，以使其能被其它同等点发现。其它的应用可以使用PNRP来解析某个同等点名称，以获得所注册应用的相应IP地址和端口。PNRP并不提供任何寻找或浏览同等点名称的机制。发布同等点名称的机制必须通过其它手段来做。同等点名称到地址的解析是通过让参与的同等点合作彼此传递消息，并维护一个同等点名称到地址映射的分布式缓存来做到的。除了启动以外，注册与解析机制并不依赖于服务器的存在。当某个PNRP实例第一次启动时，需要找到某些可以与之交换数据的其它PNRP实例的地址。如果没有其它手段可用，则使用众所周知的服务器来获取一个其它PNRP实例的列表。
换句话说，PNRP让对等应用注册一个同等点名称到端点的映射，并解析某个同等点名称以获取端点。此时，某些定义将是适当的。一个同等点名称是一个标识着某个同等点资源的字符串。为了能注册一个同等点名称，应用必须能访问一个公/私密钥对。该密钥对用来对某些消息签名，以避免篡改。同等点名称也可以来源于公钥，以便能验证标识的主人。端点是一个IPv6/IPv4地址、端口与协议。实际上可以用单个同等点名称注册一个端点列表，并在解析该同等点名称时返回该列表。节点是PNRP协议服务的一个实例。每台计算机一般有一个节点。网络是一个能彼此到达的节点网络。单个节点可以连接到多于一个的网络。网络具有一个等同于IPv6中所定义的范围的范围属性—“全局”、“场点局域”和“链路局域”。一个节点可以具有多个场点局域网络和多个链路局域网络。节点间的通信不应当从一个网络窜到另一个。网络名称用来区分网络。一个同等点名称可以注册在多于一个节点上。PNRP保持每个不同的注册。与每个同等点名称实例相关联的端点列表都将是不同的。在一个节点内，也可能将一个同等点名称注册在与该节点相连接的多于一个的网络上。这些注册的每一个都是不同的。一般而言，这些实例的每一个中的端点列表也将是不同的。当一个节点试图解析某个同等点名称时，是在某个选定的网络中来做。只有在该同等点名称已在该网络中注册时，解析才会成功。也有可能同时在多于一个的网络上解析一个同等点名称，但这些都被看待成独立的解析请求。
如在图2中所例示的那样，PNRP服务由一起工作的几个模块构成。服务管理部件200处理简单的总务，例如启动和停止PNRP服务。RPC服务器和接头202提供客户端进程和PNRP服务之间的接口。它管理暴露的接口，提供请求的条目和事件与请求完成的通告。它还处理从客户端进程中断中的恢复。网络管理器204维护特定客户端请求的状态，并维护可用的PNRP网络的列表。它负责创建网络并通知客户端网络状态的变化。
缓存管理器206维护本地的PNRP缓存和每个网络的本地注册PNRP名称的列表。它是分布式PNRP缓存的一部分。它为来自其它计算机的解析请求提供检索和下一站选择。它通过定期启动解析请求来维护其自己的缓存，以确保较好结构化的缓存。它探测网络的分隔，并尝试修复。它提供拥有多个注册同等点ID并结构化缓存以支持每个ID的能力。协议管理器208处理创建与发送有效的PNRP消息，并处理接收到的PNRP消息。它与缓存管理器206一起工作，以实现PNRP协议。最后，消息传送器210处理消息的实际发送和接收。它操纵多个网络接口和地址，并探测本地地址集中的变化。如果需要多协议(IPv4和IPv6)，则该部件将处理两种协议。
每个PNRP节点都维护一个网络中某些其它节点的同等点名称到端点映射的缓存。按照本发明所构造的消息在节点之间交换，以将关于同等点名称的信息发布给网络中的节点。每个节点都有责任恰当地维护其缓存。如由上面所标识的申请所描述的那样，PNRP协议定义了一个编号的命名空间。每个同等点名称都被转换到一个编号，而这些编号可以比对，以确定在命名空间中的接近性。当一个解析某个同等点名称的请求到达一个节点时，该节点可以将该编号与其缓存中的编号相比对，以找出一个在编号上与所需要的节点比较接近的节点。解析请求以这种方式从节点传递到节点，在每一站都逐渐接近其目标。
同等点名称被使用上面所附申请中所描述的杂凑(hash)函数转换成称为P2P ID的128位编号。同样的同等点名称总是产生相同的P2P ID。一个同等点名称注册的特定实例也具有一个称为服务位置的128位编号。这两个一起成为一个称为PNRP ID的256位编号。PNRP ID的服务位置部分使同等点名称注册的特定实例在网络中唯一。
一个应用可以以PNRP注册一个同等点名称。PNRP ID是从该名称产生，并发送消息通知其它节点该注册。同一同等点名称可以在多于一个节点上注册。P2P ID在每个节点上都相同，但PNRP ID对于每个节点是唯一的。一个应用可以要求将某个同等点名称解析成一个地址。P2P ID是来源于同等点名称，并发送消息给其它节点，以定位某个注册了这一P2P ID的节点。当某个P2P ID被解析成一个地址时，就返回了一个验证了的同等点地址(CPA)。这一CPA包括了目标的PNRP ID的服务位置部分、当前IP地址、公钥以及许多其它字段。签署CPA是为了防止篡改。
一个给定的P2P ID可以由许多不同的节点注册。PNRP使用一个“服务位置”后缀来确保每个注册了的实例都具有一个唯一的PNRP ID。“服务位置”是一个对应于某个唯一网络服务端点的128位编号。其数值是通过组合IPv6地址、端口、协议和公钥的一部分而产生的。服务位置可以认为是对PNRP客户端不透明的。一个服务位置具有两个重要的属性。在任何时候，一个服务位置都标识一个唯一的同等点名称的实例。在比对两个服务位置时，每一个的共同前缀的长度就是对网络接近性的一个合理的测度。以相同四位开始的两个服务位置通常不会比以相同三位开始的两个相距更远。这些优点只适用于“全局”范围的自然单播IPv6地址。
PNRP ID的产生和注册只是PNRP服务的一部分。PNRP服务的执行可以分成四个阶段。第一个是PNRP网络发现。一个新的节点必须找到一个它所希望加入的网络中已存在的节点。该网络可以是全局PNRP网络、某个场点局域(企业)的网络或某个链路局域的网络。第二阶段是加入某个PNRP网络。一旦新节点找到一个已存在的节点，它就执行SYNCHRONIZE过程，以获取该已存在节点的顶缓存层的一部分。单个缓存层的一个子集提供了一个新节点开始参加入网络的足够信息。第三阶段专注于积极参加入网络。在初始化完成后，该节点可以参加入PNRP ID的注册和解析。在这一阶段中，同等点还进行定期的缓存维护。最后阶段是关于同等点离开网络。节点注销任何已本地注册的PNRP ID，而后再终止。
为了完成PNRP的多种功能，本发明的PNRP协议包含十种不同的消息类型。在高层次上，这些消息包括一种用以请求将某个目标PNRP ID解析成一个CPA的“解析”消息、一种用作某个完成“解析”请求的结果的“回应”消息、一种包含一个打算供接收者的PNRP缓存使用的CPA的“充溢”消息、一种用以要求某个PNRP节点“广告”其顶层缓存的“恳求”消息、一种包含一个针对某节点顶层缓存中CPA的PNRP ID列表的“广告”消息、一种用以要求某个节点充溢一个“广告”了的CPA的子集的“请求”消息、一种用以询问某个节点是否某特定PNRP ID已在该节点上注册的“查询”消息、一种用以确认某个PNRP ID的本地注册并可选地提供一个证书链以协助验证该ID的CPA的“授权”消息、一种用以应答接收到和/或成功处理某些消息的“应答”消息，以及最后一种用以尝试合并可能已分隔的网络的“修复”消息。
一个节点在PNRP中可以启动六种基本类型的事务，本发明的那些消息可以在这些过程中利用。这些事务包括网络发现、同步、解析、充溢、标识验证和修复。为提供对这些事务(其细节在上面所标识的申请中已有解释)的基本理解，提供这些事务的一个关于本发明的消息与消息结构的简要描述。
网络发现事务使一个同等点能发现一个同等点网络。在某一较佳实施例中，每个节点都可以加入某些数量的网络。可以加入的网络集取决于该节点所具有的网络连接性。如果某台节点计算机具有多个接口适配器，则其可以加入多个链路局域的网络。如果某个节点使一个支持IPv6的场点的一部分，则其可以访问一个场点局域的网络。如果某个节点拥有到多于1个这样场点的连接(可能是经由VPN)，则其可以访问多个场点局域的网络。如果某个节点连接到互联网，则其可以访问全局网络。
一个节点可以选择加入或是不加入某个其能访问的网络。当某个应用第一次请求在某个网络上注册一个同等点名称或解析某个网络上的同等点名称时，如果该节点还没有加入该网络，则其必须加入该网络。要加入该网络，它必须尝试定位在同一网络中的至少一个其它节点。如果它不能找到另一节点，则可以假定它是在该网络中的第一个节点，并将等待其它节点稍后加入。
每次一个PNRP节点加入一个网络时，它必须进行网络发现，以便找到另一节点。如果该PNRP实现判定其缓存不健康并需要获取更多的缓存条目，则网络发现也可以在稍后进行。如果起初的缓存发现尝试不行，则可以稍后进行进一步的尝试。网络发现使用以下的过程来进行。首先，一个同等点可以从所维持的缓存进行发现。在这一过程中，该同等点首先检查所维持的缓存。如果没有维持缓存，则该同等点必须尝试通过下面所讨论的供应的节点地址来发现。如果已维持了缓存条目，则该同等点通过对没有过期的CPA，而后对具有长生命期的CPA，再而后对过期时间最近的CPA设定优先选择，来为所有缓存条目计算一个优先级。而后该同等点尝试按顺序与所选择的节点同步，直至其中之一提供某些缓存条目。
如上所述，如果没有维持的缓存，则该同等点尝试通过供应的节点地址来进行发现。在这一过程中该同等点检查管理性配置是否指定了某个要连接的同等点集合。如果没有，则该同等点尝试下面所讨论的组播发现。不然，则该同等点对每个指定的端点按顺序尝试同步，直至其中之一提供某些缓存条目。
至于组播发现，如果简单服务发现协议(SSDP)可用，则该同等点发出一个针对所希望网络中的某个PNRP服务实例的“SSDP检索”。在该SSDP检索消息中使用的检索目标字符串是“urn：Microsoft Windows Peer NameResolution Protocol：<major>：<Protocol>：<Scope>”，其中<major>是一个表示版本的编号，<Protocol>是“IPV6”，<Scope>是“全局”、“场点局域”或“链路局域”之一。该检索可以事先发出，这样回应就能及时可用。如果SSDP不可用，则该同等点可以尝试这些其它的发现协议。如果没有一个协议可用，则该同等点将不得不尝试下面所描述的目录名称服务器(DNS)发现。但是，如果接收到了回应，则将该回应放入一个要尝试节点的列表。如果在某个短时间段内没有回应可用，则该节点可能需要尝试其它的发现协议。这段时间可以由该实现来判定。该同等点可以以所选择的节点按顺序尝试同步，直至其中之一提供某些缓存条目。
至于DNS发现，该同等点发出一个针对某台种子服务器的众所周知名称的DNS查询。这个用于全局网络的名称可以是例如SEED.PNRP.NET。如果成功，则该同等点可以进行下面所描述的同步。如果到此时网络发现还没有成功，则PNRP将该网络的状态设置成不能发现该网络的其它成员，并假定它是在该网络中的第一个节点。它可以稍后再此尝试同步。
同步使一个节点能从另一个节点的缓存获取一个CPA集合。同步是在网络发现后进行。它在从网络发现所返回的节点集合中随机选择的某单个节点上进行。同步是受安全保护的，以减轻某些攻击。如果某个网络的缓存由于变老而变空，也可以进行同步，但这只是偶尔发生。在开始同步前，该节点必须确保其拥有至少一个本地注册的CPA。如果还没有注册一个同等点名称，则该节点可以在该网络中为其自身生成一个节点ID。同步过程包括五种类型的本发明的消息，包括“恳求”、“广告”、“请求”、“充溢”和“应答”。
图3例示了一个简单的用于同步的消息交换。在这一图3中，假定节点A212启动与节点B 214的同步。在这一情况下，这些节点间的消息流将如图3中所例示的那样出现。明确来说，“恳求”消息216从一个在网络发现中选择的节点214请求一个PNRP ID的列表。这一“恳求”消息216如表1中所描述的那样填写。
    “恳求”消息字段   数值
    现时   杂凑的现时数值
    源CPA   针对某个本地注册的同等点名称或生成的节点ID的CPA
                               表1
节点跟踪用以创建杂凑现时的“现时”值。计时器与这一状态相关联，还有一个重试计数。如果回应于发出的“恳求”216没有接收到一个“广告”消息218，则将重发该“恳求”216。如果超过了重试计数，则释放该状态并终止该事务。
接收到一个“恳求”216的节点214以一个“广告”消息218回应。“广告”218包含一个PNRP ID数组。节点214首先进行节流启发以确定其是否愿意参加一个同步事务。如果它正忙，就回应一个在数组中没有PNRP ID的“广告”消息218。不然，它就从其缓存中选择一个很好地发布了的PNRP ID集合。这可以通过使用顶层缓存条目或通过随机选择来做到。如果在缓存中没有足够的条目，则节点214应当也将其自己本地注册的ID也包括进来。“广告”消息218包括来自“恳求”消息216的杂凑现时。“广告”消息218可以认为是对“恳求”216的一个应答。
如果PNRP ID数组不为空，则节点214还保留具有杂凑“现时”值的“广告”218所发送的状态。这一状态可以是在某个位图中的一位。一个计时器与这一状态相关联，这样如果在譬如15秒内没有接收到一个匹配的消息，则中止该事务并释放该状态。节点214还可以将来自“恳求”216的“源CPA”添加到其缓存。“广告”消息218如表2中所指示的那样填写。
    “广告”消息字段     数值
    现时     从“恳求”拷贝的杂凑现时数值
    ID数组     PNRP ID的列表
                              表2
当节点212接收到“广告”218时，它首先确保已经发送了一个相应的“恳求”216。如果没有，则它丢弃该消息。“广告”218被作为对“恳求”216的一个应答来对待。如果在“广告”218中的PNRP ID数组是空的，则该事务完成。不然，则节点212检查在“广告”218中的PNRP ID数组，并选择它需要包括在其缓存中的那些ID。它发出一个“请求”消息220，包括一个选定的PNRP ID的数组。它在“请求”消息220中放置用以针对“恳求”消息216而创建杂凑“现时”的原始“现时”值。“请求”消息220如表3中所指示的那样填写。
    “请求”消息字段     数值
    现时     用以在“恳求”中创建杂凑现时的现时值
    ID数组     PNRP ID的列表
                            表3
“请求”消息220被发送给节点B 214，节点B 214以一个“应答”222回应，以指示接收到并避免重新发送。如果在某个定时方式中没有接收到一个“应答”222，则节点A 212将重新发送该“请求”。如果所有的重新发送都穷尽了，却没有接收到针对该“请求”的一个“应答”，则该事务失败并终止。
如果该事务成功，即节点212接收到来自节点214的“应答”222，则节点214随后验证该“现时”是有效的。它通过杂凑所接收到的“现时”并检查其是否与上面所保存的状态匹配来做验证。如果不匹配，则不进行进一步的处理。如果该现时是有效的，则它针对数组中每个还在其缓存中的PNRP ID发送“充溢”消息2241、2242、...224N。“充溢”消息224包括针对PNRP ID的CPA。应当注意，“充溢”消息224不是同步的。也就是说，“充溢”(ID＝1)2241不需要在发送“充溢”(ID＝2)2242？前被应答。在同等点212接收到“充溢”224后，进行对该“充溢”消息224的正常处理。这包括发送一个“应答”226和验证该CPA的有效性。
如果选定的ID的数量不足够大，恳求的节点212可以决定重复这一过程。在这一情况下，它应当利用一个不同的节点来与之同步，这样就能得到一个不同的ID列表。
解析过程是由某个节点通过发送一个“解析”消息来启动。由于某个应用请求将某个同等点名称解析成一个地址(作为注册一个PNRP ID的一部分，或作为缓存维护的一部分)或探测网络分隔，可以启动一个“解析”。一个“解析”消息包含某些调整解析过程、设定在解析尝试中访问多少节点的限制、引导ID匹配的准确性的标志和代码。它指明所希望的目标PNRP ID。在每一站都插入下一站的ID以及至此所发现的最佳匹配的CPA。而且，也包括了一个已访问的节点端点的数组，以跟踪该“解析”消息从站到站的路径。“解析”消息的发起者将其自身作为第一个条目添加到该路径中。解析事务将某个PNRP ID解析成一个“验证了的同等点地址”。只有CPA的拥有者可以可信地满足一个对其CPA的解析请求。缓存的CPA只能用作对路由的“解析”请求的提示，不能用以设置一个“解析”或“回应”的“最佳匹配”字段。
当到达主持目标PNRP ID的节点时，或当所访问节点的数量等于在“解析”中设定的“最大站数”时，或当路径中的任一节点都不再可能将“解析”传递给某个更好的节点时，该“解析”消息终止。在终止后，来自该“解析”的选定内容被传入一个新的“回应”消息，该“回应”消息被向回传递往该“解析”的发起者。该“回应”包含来自该“解析”的“最佳匹配”CPA，以及所访问节点的列表。在该“回应”到达“解析”的发起者后，该发起者可以通过将该“最佳匹配”CPA的PNRP ID与目标相比对而轻易地验证它们是否找到了目标CPA。
在图4中例示了某个解析/回应事务的一个三节点示例。在这一简化了的示例中，节点A 228尝试经由节点B 230解析节点T 232。除了“应答”外，该解析事务还包括3种消息：“解析”、“回应”和“授权”。在该解析完成后，节点A 228可以如下面将讨论的那样，向节点T 232直接发送一个“查询”消息。
对于“解析”消息，要考虑三种情况，在图4中例示了前两种。这三种情况是在节点228启动一个“解析”234、将一个“解析”236从节点A 228传递给另一节点B 230、将一个“解析”从某个节点发回(在图4中未示出)。这些场景的每一种将依次讨论。
首先讨论在节点A 228启动一个“解析”。如图4中所例示的那样，节点A 228由于某些原因启动一个“解析”。这些原因包括应用的解析请求、注册广告、缓存幅度维护或网络分隔探测。发起者228还指定一个操作代码，指示该“解析”是否可以由某个本地注册的ID来满足。如果可以，则节点A 228扫描本地注册的ID集合来寻找匹配。如果找到一个匹配，则该“解析”在节点A 228自身内以所匹配的ID完成。如果本地注册的ID不可接受，或者如果没有本地ID匹配，则以在表4中所示出的字段创建一个“解析”消息234。而后将这一“解析”消息传递给某些其它的节点230，以作如下面所描述的处理。
    目标ID     设定为所希望的ID
    下一站     从缓存中选择的PNRP ID
    最大站数     可以是常量或关于预计的网络大小
    最佳匹配     某个本地注册的同
  等点名称的CPA
    路径   1个条目，包含最佳的源地址和端口
    原因代码、操作代码、精度   取决于解析发起者的数值
                             表4
当节点A 228想要或需要将一个“解析”234传递给另一节点B 230时，必须首先选择该下一节点。为了选择下一站，节点A 228制作一个与“目标ID”(节点T 232)最接近的三个PNRP ID的缓存的CPA的列表L，排除那些地址已经在“路径”中列出的，以及那些并不比A的最接近的本地注册ID更接近“目标ID”的。如果“目标ID”在列表L中，则选择该条目作为下一站。不然，如果列表L不为空，则随机选择一个条目。换句话说，节点A 228找到某些比该节点更接近目标的新节点，并选择其中之一以向之传递“解析”消息234。
如果节点A 228能够选择某个下一站，则节点A 228将一个适当的条目插入“已接收位图”。节点A 228将其自身加入“路径”中，为所选定的下一站选择其最佳地址，并将该条目标记成“已接受”。节点A 228将“下一站”设定成所选定目的地的期望PNRP ID，并将“解析”消息234传递给节点B 230。如果“解析”消息234被成功发送，则发送的节点228预期将接收到一个“授权”消息238形式的应答。如果接收到该“授权”消息238，则节点228维护一个针对“解析”234的上下文，并等待一个将返回的“回应”240，直至超时。如果在某段时间后仍没有接收到“授权”238，则重新发送该“解析”234。在假定“下一站”无效前，将重试总共N次。在某一较佳实施例中，N＝3。如果超过了重试计数，则将“下一站”的CPA从本地缓存中删除，并将该条目作为一个失败的站加入“路径”。如果没有超过站计数，则从本地缓存中选择另一个“下一站”，并重复该过程。如果在“路径”中的条目数量等于或超过“最大站数”，则以“回应代码”RESULT_MAX_HOP_LIMIT_HIT生成一个“回应”消息，并发送给“路径”中标记成“已接受”的最近的条目。
如果该节点不能够找到某个下一站，则它检查“目标ID”是否应该是在最低层的缓存层中。如果应该是，则该节点怀疑该“目标ID”可能不存在。该节点检查已有的“路径”条目，并对那些被标记成“可疑”的条目计数。如果这一计数超过某个阈值，则以“回应代码”RESULT_TOO_MANY_MISSES生成一个“回应”消息，并发送给“路径”中标记成“已接受”的最近的条目。如果该节点不能够找到某个下一站，但“可疑”计数没有超出，则该节点将该“解析”发回给“路径”中标记成“已接受”的最后的条目。该节点首先将其自身加入“路径”中，为目的地节点选择其最佳地址，并将该条目标记成“已拒绝”。它将“下一站”设定成0，并设置RF_IGNORE_NEXTHOP标志以指示原路返回。如果该“目标ID”应该在该节点的最低缓存层中，则它怀疑该“目标ID”可能不存在。在这一情况下，该节点也将其“路径”条目标记成“可疑”。如果该节点不能够找到某个下一站，而且在“路径”中没有节点(除其自身外)，则它就是该“解析”消息的发起者。在这一情况下，它以“回应代码”RESULT_NO_BETTER_PATH_FOUND将一个结果返回给呼叫者，指示解析失败。“最佳匹配”CPA变得对该呼叫者可用。
节点B 230接收到一个“解析”消息234，包含一个目标PNRP ID、一个“最佳匹配”CPA、一个“下一站”PNRP ID和一个列出了处理过该“解析”的所有节点的地址的“路径”。如果标志字段没有设置RF_IGNORE_NEXTHOP，而“最佳匹配”CPA可能具有一个CPA或为空，则节点B 230检查其本地处理负载。如果负载太高不能处理新的“解析”请求，则它以一个将标志字段设置成“AF_REJECT_TOO_BUSY”的“授权”238来回应，而处理完成。该“授权”的接收者负责将拒绝的节点端点加入路径数组，并重新路由该“解析”请求到别处。
接收节点230检查该“路径”数组包含至少1个标记成“已接受”的地址，而最后一个这样的地址与该消息的来源相同。如果不是，则不做进一步处理。接收节点还检查所接收到请求中的参数。如果某些参数不在有效范围内，则它以一个将标志字段设置成“AF_INVALID_REQUEST”的“授权”消息来回应，而处理完成。无效参数的一个示例是“最大站数”是否太大。该“授权”的接收者负责将拒绝的节点端点加入路径数组，并重新路由该“解析”请求到别处。
接收节点(例如节点B 230)检查“下一站”ID是否是本地注册的。种子服务器可以跳过这一测试。如果失败，则它该“授权”的接收者负责重新路由该“解析”请求到别处。在接收到AF_UNKNOWN_ID时，该“授权”的接收者还应当从其缓存中删除该“授权”发送者的PNRP ID。如果在该消息中包括“最佳匹配”CPA，则该节点尽其可能验证该“最佳匹配”。如果该CPA无效，则该节点将该“最佳匹配”CPA从该消息中删除。如果该“最佳匹配”CPA有效，则该节点遵循通常的用以决定是否将该CPA加入其缓存的规则。
该节点还检查在“路径”中是否已有一个针对它的条目。如果有，由于这不是一个原路返回的“解析”，就存在一个环路。则该节点以一个将标志字段设置成“AF_REJECT_LOOP”的“授权”来回应，而处理完成。该“授权”的接收者负责将拒绝的节点端点加入“路径”数组，并重新路由该“解析”请求到别处。
如果所有前面的检查都通过，则节点B 230发送一个“授权”238以应答该“解析”消息234。如果设置了“解析”标志RF_SEND_CHAIN，则在该“授权”238中包括了针对“下一站”的证书链。在该“授权”消息中包括了对应于下一站的PNRP ID的同等点名称的“分类符”字符串部分。
节点B 230检查其是否具有某个比当前的“最佳匹配”更匹配的本地注册的CPA。如果是，则它用这一CPA替换“最佳匹配”。该节点还检查其是否具有某个满足该“解析”标准(基于“操作代码”、“精度”和“目标ID”)的本地注册的CPA。如果有满足的，或者如果在路径中条目的数量＞＝“最大站数”，则该节点以当前的“最佳匹配”创建一个“回应”消息。将该“解析”消息的路径拷贝成该“回应”消息的路径。该节点设置“回应代码”以指示RESULT_FOUND_MATCH或RESULT_MAX_HOP_LIMIT_HIT。而后该节点从路径中删除其地址以及标记成“已拒绝”的后续条目，并将该“回应”发送给路径中标记成“已接受”的最近的条目。
如果节点B 230没有发送“回应”(如图4所例示的那样)，则它尝试将该“解析”消息236传递给下一个节点T 232。这一传递遵循上面所描述的过程。也就是说，节点T 232起初以一个“授权”消息242来回应。而后它进行上面所讨论的检查，并判定它与“目标”匹配，以一个将其自身标识成“最佳匹配”的“回应”消息244回应给节点B 230。回应于该“回应”消息244，节点B 230发送回一个“应答”消息246。而后节点B 230检查该路径并将“回应”消息240传递给节点A 228，而节点A 228以一个“应答”消息248回应。
如上面所指示的那样，节点还必须处理某个原路返回的“解析”。当一个节点接收到一个“解析”消息R时，它包含一个“目标ID”PNRP ID、一个“最佳匹配”CPA、一个“下一站”PNRP ID和一个列出所有已处理过该“解析”的节点的地址的“路径”。对于一个标志字段没有设置RF_IGNORE_NEXTHOP的原路返回的“解析”，该节点首先检查其“已接收位图”，以验证它以前传递过该“解析”。如果该位没有设置，就丢弃该消息。而后该节点检查“路径”，以确保其地址是在该“路径”上，而且它是在该“路径”中标记成“已接受”的最顶上的条目。不然，就丢弃该消息。如果没有丢弃该消息，则该节点将一个“授权”发送回给发送者，以“应答”该消息。它不包括一个证书链。
如果在“路径”中的条目数量＞＝“最大站数”，则该节点以当前“最佳匹配”创建一个“回应”消息S。将“解析”消息R的“路径”拷贝成S的“路径”。该节点设置“回应代码”以指示超出了“最大站数”。而后该节点从“路径”中删除其地址，并将该“回应”发送回“路径”中标记成“已接受”的最近的条目。如果该节点没有发送一个“回应”，则它尝试将该“解析”传递给下一站。这遵循上面所描述的过程，除了某些例外：a)不符合“节点B 230检查其是否具有某个比当前的‘最佳匹配’更匹配的本地注册的CPA。如果是，则它用这一CPA替换‘最佳匹配’。”；以及b)如果当前节点是该“解析”事务的发起者，并且原因是REASON_REPAIR_DETECTION，则处理完成。
如上面所简要讨论的那样，当一个节点接收到一个“回应”消息244、240时，它包含一个“目标ID”PNRP ID、一个“最佳匹配”CPA和一个列出所有已处理过该“解析”的节点的地址的“路径”。接收节点还检查其“已接收位图”，以验证它以前发送过一个与该“回应”240、244相匹配的“解析”234、236。如果该位没有设置，就丢弃该消息。接收节点还检查“路径”，以确保其地址是在该“路径”上的最后一个(最近的)，而且它是标记成“已接受”的。不然，就丢弃该消息。如果没有丢弃该消息，则该接收节点发送一个“授权”246、248，以应答接收。该节点尽其可能验证“最佳匹配”CPA，并将之加入其缓存。将CPA加入缓存服从一组规则，这些规则可能要求交换进一步的消息，这样P就可以验证“最佳匹配”CPA。这已在上面所标识的申请中描述。
而后该节点将其自身从“路径”中删除。该节点还删除前面的标记成“已拒绝”的条目，直至它遇到一个标记成“已接受”的条目或该列表耗尽。如果找到了某个标记成“已接受”的条目，则该节点将该“回应”传递给这一节点。如果该“回应”所传递给的节点没有用一个“应答”来回应，则该节点重新发送该“回应”，直至N次。如果重发次数超过，则该节点将该失败了的目的地节点从“路径”中删除，并重试在本段中所讨论的“回应”处理。如果在“路径”中已没有更多的条目，则该节点就是原来的“解析”234的发起者。节点228验证是否其发起该请求。如果不是，则丢弃该“回应”。如果“回应代码”指示成功，则节点228在“最佳匹配”CPA的来源上进行标识验证检查。这包括将一个“查询”消息250发送给目标节点232，以及验证返回的“授权”消息252。如果该标识验证失败，则它将回应代码改变成IDENTITY_FAILURE。它将这些结果返回给呼叫者。
“授权”消息可以由发送者分段。靠接收者来确保其在处理该“授权”消息前接收到所有的分段。如果在某个合理的时间范围内没有接收到某个分段，则应当重新发送原来的消息(“查询”或“解析”)，除非超过了重试计数。如果该“授权”消息设置了AF_CERT_CHAIN标志，则该节点应当在所缓存的针对“验证ID”所指明的PNRP ID的CPA上进行链验证操作。应当检查该链以确保其中的所有证书都是有效的，并且该链的根与叶之间的关系也是有效的。用于该链的根的公钥杂凑应当与该CPA的同等点名称中的授权相比对，以确保匹配。用于该链的叶的公钥应当与用以签署该CPA的密钥相比对，以确保匹配。最后，应当检查P2P ID，根据创建P2P ID的规则看它是否是“授权”和“分类符”的杂凑。如果上面的任一检查失败，则应当将该CPA从缓存中删除，并且应当通过将发送该“授权”消息的节点的地址加入该“解析”消息的“路径”并将该条目标记成“已拒绝”来更改该“解析”消息。
如果设置了AF_UNKNOWN_ID，则应当将该CPA从缓存中删除。如果没有设置AF_CERT_CHAIN，但对应于“验证ID”PNRP ID的CPA要求一个证书链来验证，则应当将该CPA从缓存中删除，并且应当通过将发送该“授权”消息的节点的地址加入该“解析”消息的“路径”并将该条目标记成“已拒绝”来更改该“解析”消息。
当对应于“验证ID”PNRP ID的CPA被验证后，应当将其标记成已充分验证的。将“分类符”字符串从该“授权”消息中析出，并与该CPA一起保持。如果AF_REJECT_TOO_BUSY、AF_UNKOWN_ID、AF_REJECT_LOOP和AF_INVALID_REQUEST都未设置，则接受该“解析”以作处理，而“授权”处理完成。
在某些情况下某个接收到“解析”消息的节点可能选择不接受该消息以作传递，但仍向发送节点提供一个“下一站”建议。在这一情况下，该节点在“授权”消息中返回一个建议的“推举端点”和“推举PNRP ID”。在这一情况下，该“授权”的标志值应当包含AF_REDIRECT。接收到有AF_REDIRECT的“授权”的节点可以选择是否使用该“推举端点”来发送“解析”消息。在这两种情况下，回应该“授权”的节点都被加入“路径”。节点应当使用该“推举端点”的唯一时候是在发起该“解析”的节点是为了探测网络分隔，并已向某台PNRP种子服务器发送一个具有REASON_REPAIR“原因”的“解析”的情况下。在其它情况下，该节点应当忽略该“推举端点”。
PNRP使用导向的充溢来在节点间传播CPA缓存。充溢是在几种情况下使用。在回应于某个“请求”消息的同步期间，将所请求的CPA充溢到发送该“请求”的同等点。只有在已接受一个“恳求”消息并且已发送一个“广告”消息后，才能接受该“请求”消息。无论何时当将一个CPA加入缓存的最低层时，就将所添加的CPA充溢到离本地注册ID最近的n个同等点。n的值可以调整，而值最好是4。如果添加CPA的原因是由于接收到一个“充溢”，则不应当将该CPA充溢到其地址在所接收到的“充溢”的“已充溢”列表中的节点。如果没有足够的空间，则应当将所接收到的“已充溢”列表中的地址拷贝到新的“充溢”消息的“已充溢”列表。无论何时接收到一个包含CPA撤回的“充溢”后当将一个CPA从缓存的最低层删除时，就将所撤回的CPA充溢到离本地注册ID最近的n个同等点。同样，n的值可以调整，但值最好是4。不应当将该CPA充溢到其地址在所接收到的“充溢”的“已充溢”列表中的节点。如果没有足够的空间，则应当将所接收到的“已充溢”列表中的地址拷贝到新的“充溢”消息的“已充溢”列表。最后，当接收到一个针对某新同等点的“充溢”消息，而该CPA已被加入缓存的最低层时，则将一个“充溢”消息以本地节点的ID发送给该新同等点。如果该“充溢”的来源就是该新同等点，则是一个例外。
PNRP并不创建持久的邻居关系。在最松散的意义上，每个由CPA缓存中的一个CPA所代表的节点都可以认为是一个邻居。但是，从缓存中添加和删除CPA不需要通知该CPA的发布者。在某个节点的缓存中具有一个同等点的CPA并不确保这个邻居在其缓存中具有该节点的CPA。这里关系是不对称的。但是，上面所描述的最后的“充溢”条件确实试图对彼此接近的ID创建对称。
每个UDP“充溢”消息于在其上采取任何行动之前，都由一个“应答”来应答。“充溢”的发送者维护针对发送“充溢”的某些时间的状态。如果接收到“应答”，则释放该状态。如果在某一时间段内没有接收到“应答”，则重新发送该“充溢”并重新设定计时器。重试该“充溢”直至某个给定的次数，最好是3次。如果在最后的重试后还没有接收到“应答”，则释放该状态。而且，如果该“充溢”的目的地是在发送者的缓存中，则删除该缓存条目，以避免将来再试图发送消息给该无回应的节点。
当节点接收到一个“充溢”消息时，首先通过发送一个“应答”应答该“充溢”消息来处理它。如果“验证ID”  出现并且不是本地注册的，则将标志字段设置成“KF_NACK”。接着，验证该“充溢”消息。这包括进行CPA签名和内容的本地验证。如果该CPA被验证，则它判定是否将该CPA加入缓存。如果该CPA是针对一个在同一节点上本地注册的PNRP ID的，则无需将其加入缓存。如果用以签署该CPA的标识不能由该CPA单独验证，而该CPA将被加入缓存视图的两个较低层之一，则需要如下面所将讨论的那样来进行标识验证。如果验证失败，则该节点丢弃该“充溢”消息。如果成功，则该节点继续处理该“充溢”。如果该CPA已经过时，则该节点丢弃该“充溢”。如果该CPA是一个撤回的CPA，则该节点从缓存中删除相应的CPA(如果存在)。如果找到了某一个，则该节点通过发送“充溢”消息将该撤回传递给其它的邻居。
如果该CPA不是一个撤回CPA，则该节点更新缓存。如果在缓存中已有一个匹配的CPA，则该节点以新的CPA数据更新该缓存条目。如果这是一个新的条目，则该节点创建一个新的条目，并试图将其加入缓存。如果需要删除另一条目来为其腾出空间，但所存在的条目由于更高的信任等级或更好的接近性而优于该新条目，则该条目可能不能添加。如果该条目属于最低的缓存层，则应当添加它。如果该CPA属于最低的缓存层，则应当将其传递给某些邻居，即使无法将其加入缓存。如果在同步期间接收到“充溢”，则止住“充溢”消息的传递，因为假定其它节点已经知道所有已发现的CPA。如果需要传递“充溢”，则选择离本地注册ID最近的n个PNRP ID集合。以该新的CPA和一个“已充溢列表”将一个“充溢”消息发送给该集合中的每一个，该“已充溢列表”包括该n个邻居加上在所接收到的“充溢”消息中接收到的“已充溢列表”的内容。
标识验证是一种用以验证CPA的减缓威胁的设计。它具有两个目的。首先，标识验证确保在一个CPA中所指明的PNRP节点具有该CPA所本地注册的PNRP ID。其次，对于安全的PNRP ID，标识验证确保该CPA是用一把与该PNRP ID中的授权有可密码证明的关系的密钥来签署的。标识验证如何完成这两个目的的细节可以在上面所标识的未决申请中找到。
标识验证在两个不同的时间发生。首先，标识验证在将一个CPA加入最低两个缓存层时发生。在最低两个缓存层中的CPA验证对于PNRP解析PNRPID的能力是很关键的。在将一个CPA加入这两层之一前进行标识验证减缓了几种攻击。在这一情况下，该CPA将被在一个列表中保持多至譬如30秒，等待“授权”消息。其次，标识验证在“解析”期间寻机发生。PNRP缓存有很高的周转率。因此，多数缓存条目在被使用之前就被在缓存中覆盖。PNRP并不验证多数的CPA，直至它们被实际使用。当用一个CPA来路由某个“解析”路径时，PNRP将标识验证背负在该“解析”消息头上。该“解析”包含一个“下一站”ID，该ID如同在“查询”消息中的“目标ID”一样对待。该“解析”以一个“授权”消息来应答，如同对于一个“查询”所预期的一样。如果某个寻机的标识验证失败，则该“解析”的接收者不是发送者所相信的。因此，该“解析”被路由到别处，而该无效的CPA被从缓存中删除。
为例示这一验证，假定P是一个请求对PNRP ID“T”标识验证的节点。N是接收该标识验证请求的节点。P以目标ID＝T生成一个“查询”消息，或以下一站＝T(并且不设置RF_IGNORE_NEXTHOP)生成一个“解析”消息。N检查其本地注册PNRP ID的列表。如果T不在该列表中，则N以一个指示ID T不是本地注册的“授权”消息来回应。如果所接收到的消息是一个“解析”，则丢弃该“解析”，因为P将负责将它传递给别处。当T是在N上的PNRP ID列表中，则N构建一个“授权”消息，并将目标ID设置成T。如果设置了RF_SEND_CHAIN标志，则N获取关于用以向对PNRP ID T的授权签署该CPA的密钥的证书链(如果存在)。该证书链被插入到该“授权”消息中。同等点名称的“分类符”部分也被加入该“授权”消息。
N将该“授权”消息发送给P。如果该“授权”消息长于1216字节，则将该消息分割成几个1216字节或少于1216字节的分段，并发送每个分段。如果T是一个不安全的ID，或该CPA已经验证(以RF_SEND_CHAIN发送了“解析”)，则处理完成。P验证该CPA的签署密钥和用以产生PNRP ID的授权之间的关系。如果验证失败，则丢弃该CPA。如果验证失败而启动消息是一个“解析”，则P将该“解析”传递给别处。
如在上面所标识的申请所解释以及上面所简要讨论的那样，PNRP网络有可能分隔。这可以以两种方式发生。第一，网络可能是独立启动的，并需要合并。第二，网络可能是作为一个而启动的，但该网络的某些分段变得与该网络的其它部分相隔离。为了桥接任何可能的分隔，假定该网络将有指定的种子服务器。这是用于经由DNS引导的相同的服务器。如果在一个网络中有多台种子服务器，则这些种子服务器必须定期互相通信，以确保交换在它们缓存中的ID。这可以使用同步过程来做到。这将避免产生孤岛。
一个网络中的节点将定期轮询种子服务器，以测试该网络是否已变得与主网相隔离，并在必要时试图合并回去。网络测试分隔的频率与其对该网络大小的预计成反比。这是为了防止测试分隔发生得太频繁。一个新近加入网络得节点在假定其能够估计该网络得大小之前应当等待一段时间，等其缓存被传播。
为了确保网络的合并，要使用PNRP“修复”消息。“修复”具有一个PNRPID、一个节点的IP地址和一个“修复层次”编号。缓存层是编码成0为顶层(最广泛的编号范围)，而每个后续层(更小范围)高1。当首次探测到一个分隔时，将“修复层次”初始化为0。当某个节点决定其应当对某个分隔代码进行一次测试时，该节点将使用某台已知种子服务器的地址作为IP地址、一个本地注册的PNRP ID和一个0层次来内部产生一个“修复”。它自己来处理这个“修复”。
在处理一个“修复”时，该节点对分隔进行一次测试。它首先找到一个与该“修复”消息中的最接近的本地注册ID。而后它发送一个针对这一ID+1的“解析”给该“修复”消息中所指明的IP地址。这一“解析”应当具有一个“修复”的“原因代码”。如果这解析到了某个已知的节点，则并没有分隔。
如果解析到了某个新的节点，则怀疑有一个分隔。如果发现该新节点是在底层缓存(最高编号)，则如通常一样进行充溢。在该“充溢”中设置一个“修复”的“原因代码”。同样，如果接收到该“解析”的节点将来源ID放入其最低缓存层，则该节点将充溢条目到该来源。所有的这些充溢将导致与新的网络交换几个ID。所有经由充溢发现的新节点都以这一方式来跟踪。
现在很显然，PNRP协议包括十种消息类型。每个消息以一个PNRP头开始，以特定于该消息类型的字段随后。运转开销(例如字段描述)在每个消息字段表的“长度”列单独计算。在以下的描述中，描述了一个由所有这些消息共享的一般消息数据结构，跟着是对本发明的协议中所包括的十种消息中每一种的消息数据结构的详细描述。在这一讨论后，将提供用以构造本发明的消息的每个字段数据结构的描述。
在图5中例示的是一幅例示了用以构造本发明的十种PNRP消息的基本消息数据结构的示例性数据结构图。可以看到，消息数据结构260包含许多字段2621-N。在某一较佳实施例中，第一个字段2621被保留为PNRP头。针对用以构造消息260的每个单独字段2621-N的字段数据结构包括一个类型成份266、一个长度成份268和字段数据结构264的实际内容或载荷270。长度成份268是按照整个字段264的长度272来计算的。按这种方式，此协议是完全可扩展的。
“解析”消息按照本发明的数据结构来构造。如从图6的简化数据结构图可以看到的，“解析”消息280是以许多字段282-292构造的。这多种字段也是按照本发明的字段数据结构来构造。举例来说，PNRP_HEADER字段282包含字段数据结构294。这一数据结构294的成份包括类型(字段ID 296)、长度298。这一PNRP_HEADER数据结构294的内容包括一个协议成份300、一个主版本成份302、一个副版本成份304、一个消息类型成份306和一个消息ID成份308。类似的是，VALIDATE_PNRP_ID字段288包含字段数据结构310。如所有其它的字段数据结构一样，VALIDATE_PNRP_ID字段数据结构310以一个类型成份(字段ID 312)和一个长度成份314来开头。这一字段数据结构的内容包括P2P ID成份316和服务位置成份318。每个不同字段都以某种类似图5中所例示的式样构造，其描述将在下面提供。
如现已显明并将在下面例示的那样，这一“解析”消息包含一个要解析的目标PNRP ID、该“解析”发起者的CPA、“最佳匹配”的CPA以及一个已处理过该“解析”的节点的列表。该“解析”包括一个“标志”字段。对于Resolve_Controls字段的标志子字段定义了两个标志：RF_SEND_CHAIN-0x0001，要求接收者在“授权”回应中发送一个证书链(如果存在)；RF_IGNORE_NEXTHOP-0x0004，用于“解析”的原路返回路径。如果某个节点接收到一个作为原路返回一部分的“解析”，则发送者并不知道这一节点的PNRP ID。“下一站”字段设成零，并设置RF_IGNORE_NEXTHOP，以指示该“授权”将只用作对“解析”的“应答”。如上面所讨论的那样，“解析”的接收是以一个“授权”消息来应答的。在本发明的某一较佳实施例中，“头部”中的“消息类型”设成5。在表5中呈现了按照本发明的教义构造的“解析”消息的数据结构细节。
   116+P+A*20
              表5
在这一表5中，P是编码了的CPA的字节长度，向上取整到最接近的DWORD边界。A是在已标记数组中条目的数量。它不能超过“最大站数”的值。
在“解析”到达拥有目标PNRP ID的节点时，或者在已标记路径的大小等于“解析”“最大站数”时，产生一个“回应”。在生成“回应”时，将来自相应“解析”的已标记路径的所有条目拷贝入“回应”路径。经由“路径”中所有标记了“接受”的地址自底向顶路由“回应”消息，直至每个适当的网络端点都处理过该“回应”，且该“回应”返回到“解析”的发起者。如上面所讨论的那样，“回应”的接收是由一个“应答”消息来应答。在某一较佳实施例中，“头部”中的“消息类型”设成6。在表6中呈现了按照本发明的教义构造的“回应”消息的数据结构细节。
Figure G04148930020040625D000271
                            表6
在这一表6中，P是编码了的源CPA的字节长度，向上取整到最接近的DWORD边界。B是在端点数组中条目的数量。
“恳求”消息请求接收者从其缓存中向发送者“广告”某些条目。发送者包括一个接收者可能加入其缓存的CPA。必须在该“广告”消息中返回“杂凑的现时”。“恳求”的接收由一个“广告”消息来应答。在某一较佳实施例中，“头部”中的“消息类型”设成1。在表7中呈现了按照本发明的教义构造的“恳求”消息的数据结构细节。在这一表7中，P是编码了的源CPA的字节长度，向上取整到最接近的DWORD边界。
Figure G04148930020040625D000281
                              表7
“广告”消息回应于某个“恳求”而产生。“广告”从广告者的缓存中列出某些PNRP ID。这使该“广告”的接收者能有选择性地“请求”CPA传播其缓存。“广告”的接受扮演对“恳求”的一个应答。对于“广告”不产生应答。任何不是扮演对“恳求”的应答的“广告”都应当默默地丢弃。“杂凑现时”值必须与在该“恳求”消息中所接收到的同样。一个接收“广告”的节点必须能够验证该“杂凑的现时”是有效的。在某一较佳实施例中，“头部”中的“消息类型”设成2。在表8中呈现了按照本发明的教义构造的“广告”消息的数据结构细节。在这一表中，A是ID数组中的条目数量。
Figure G04148930020040625D000282
20  4+8+A*32  PNRP_ID_ARRAY ID数组 排序了的可用于“请求”的PNRP ID的数组
32+A*32  4+4  HASHED_NONCE 杂凑的现时 加密了的现时值
40+A*32
                               表8
“请求”消息用于请求某个广告者“充溢”“广告”了的CPA的一个子集。“现时”应当被杂凑过，并与在原始“恳求”消息中所接收到的“杂凑的现时”相比对。ID数组包含发送者意欲“充溢”回发送者的PNRP ID，这样它就能获得那些CPA。“请求”的接收由一个“应答”消息来应答。在本发明的某一较佳实施例中，“头部”中的“消息类型”设成3。在表9中呈现了按照本发明的教义构造的“请求”消息的数据结构细节。在这一表中，A是ID数组中的条目数量。
                             表9
“充溢”消息由PNRP用来传播缓存了的CPA，以选择同等点。“充溢”是在将一个新的CPA加入最低缓存层时，或在最低缓存层中处理一个撤回的较早版本的CPA时，回应于某个“请求”消息而发起。“充溢”包括一个帮助防止冗余“充溢”的地址的列表，称为“已充溢列表”。“已充溢列表”包含发送者的地址、每个发送者所要直接传送该“充溢”向的目的地，以及在该“充溢”中已接收到的任何其它发送者所知道的PNRP节点的地址。“已充溢列表”具有一个条目最大数量。如果该列表满了，则以某种FIFO方式相应低替换条目。这假定“充溢”的接收者更可能将该“充溢”传播给“附近”的邻居，而不是远的邻居。“充溢”的接收以一个“应答”消息来应答。“验证ID”是一个可选的字段。如果出现，则其要求接收者如果本地缓存了一个具有指定PNRP ID的CPA则以一个“应答”来回应，如果没有则作“否定应答”。在某一较佳实施例中，“头部”中的“消息类型”设成4。在表10中呈现了按照本发明的教义构造的“充溢”消息的数据结构细节。在这一表中，P是编码了的CPA的字节长度，向上取整到最接近的DWORD边界，而A是在数组中条目的数量。
                           表10
“查询”消息由PNRP节点用来在将选定的CPA输入本地缓存前对它们进行标识验证。标识验证确认某个CPA在其发起节点仍然有效，并请求帮助验证发起节点注册该CPA的授权的信息。对于“标志”字段定义一个标志：RF_SEND_CHAIN，要求接收者在“授权”回应中发送一个证书链(如果存在)。如果该PNRP ID已本地注册，则“查询”的接收以一个“授权”消息来应答。不然，则默默地忽略该“查询”消息。在某一较佳实施例中，“头部”中的“消息类型”设成7。在表11中呈现了按照本发明的教义构造的“查询”消息的数据结构细节。如该表所显明的那样，在FLAGS_FIELD后面有2个额外的字节，以将下一个字段放到DWORD边界上。
                              表11
“授权”消息用于确认或否认某个PNRP ID仍注册在本地节点上，并可选地提供一个证书链，让该“授权”的接收者能验证该节点注册对应于目标ID的CPA的权限。对于“标志”字段定义以下标志：AF_UNKNOWN_ID-0x0001，指示所指定“验证”的PNRP ID不注册在该主机上；AF_INVALID_SOURCE-0x0002，并不使用；AF_INVALID_BEST_MATCH-0x0004，也是并不使用；AF_REJECT_TOO_BUSY-0x0008，只有在回应某个“解析”时有效，并指示该主机太忙不能接受“解析”，发送者应当将其传递给别处去处理；AF_REJECT_DEADEND-0x0010，并不使用；AF_REJECT_LOOP-0x0020，指示该节点已处理过该“解析”消息，该消息不应当被发送过来；AF_TRACING_ON-0x0040，只用于调试；AF_REDIRECT-0x0080，指示该节点将不传递该“解析”消息，但在“授权”消息中包括了一个“推举”地址；AF_INVALID_REQUEST-0x0100，指示该“解析”消息验证失败，这可能在“最大站数”太大时发生；以及AF_CERT_CHAIN-0x8000，指示包括了一个证书链，实现验证“验证PNRP ID”与用以签署其CPA的公钥之间的关系。
“验证PNRP ID”具有向之发送“授权”的ID。“证书链”是可选的。AF_CERT_CHAIN标志指示其是否出现。“推举端点”也是可选的。这一字段由某个不能传递“解析”消息但知道可以向之发送“解析”的其它节点的节点使用。端点包含将向之发送“解析”的某个对等节点的IPv6地址和端口。当前这一字段是被忽略的，除非在节点尝试经由某台种子服务器探测网络分隔时。“分类符”字段包含是用以创建PNRP ID的同等点名称一部分的真正的“分类符”字符串。“授权”的接收不用明确地应答。“授权”只作为对“查询”或“解析”消息的一个应答/回应而发送。如果超出这一上下文而接收到某个“授权”，就必须丢弃它。在某一较佳实施例中，“头部”中的“消息类型”设成8。在表12中呈现了按照本发明的教义构造的“授权”消息的数据结构细节。在这一表中，C是编码了的证书链的字节长度，向上取整到最接近的DWORD边界，而S是“分类符”字符串的字节长度。
Figure G04148930020040625D000321
询”的内容和可能结果的标志。还有移到4字节边界的填料
28(+8) 4+32  VALIDATE_PNRP_ID 验证 “授权”所关于的PNRP ID
64(+8) (4+20)  IPV6_REFERRAL_ADDRESS 推举端点 IPv6端点。该字段可选。
64(+32) (4+32)  IPV6_REFERRAL_ID 推举PNRPID 针对IPv6端点的PNRP ID。该字段可选。
询”的内容和可能结果的标志。还有移到4字节边界的填料
64(+68) 4+C  CERT_CHAIN 证书链 关于用以向已注册ID签署CPA的公钥的证书链。
68+C(+68) (4+8+S)  CLASSIFIER 分类符 分类符字符串。该字段可选。
68+C(+S+80)
                             表12
由于包含一个“证书链”和一个“分类符”字符串，“授权”消息可能非常长。为了便于通过网络传输，在发送时可以明确地将其分割成几个分段。接收者必须能在处理该消息前将这些分段拼合起来。如果该消息是分割了的，则“头部”和“应答的头部”字段在每个分段中都是重复的。每个分段还包含一个“分割控制”字段。在每个分段中“分割控制”字段中的“偏移”值都会变化，以反映该分段的“偏移”。“分割控制”中的“大小”值是整个消息的大小减去“头部”、“应答的头部”和“分割控制”字段的大小。除最后一个外，每个分段都是相同大小。如果该消息没有分割，则“分割控制”字段是可选的。
“应答”由PNRP使用，因为它是一种请求/回应协议。在某些情况下，使用一个“应答”来代替回应简化了协议。“应答”总是在接收到“请求”、“回应”和“充溢”消息后发送。其它的消息由适当的回应消息类型来应答。“应答”可以作为一个“应答”，或者在某个“充溢”设定了“验证ID”的情况下，通过将“标志”字段设为KF_NACK＝1，作为一个“否定应答”。在某一较佳实施例中，“头部”中的“消息类型”设成9。在表13中呈现了按照本发明的教义构造的“应答”消息的数据结构细节。
Figure G04148930020040625D000341
                              表13
由于在某些情况下PNRP网络可能经历某种分隔，所以要使用“修复”消息。这一消息用以测试某个分隔，并在需要时发起一个“修复”。“修复”将请求其它节点将该“修复”传播到其它缓存层。在某一较佳实施例中，“头部”中的“消息类型”设成10。在表14中呈现了按照本发明的教义构造的“修复”消息的数据结构细节。如该表所显明的那样，在CACHE_LEVEL后面有2个额外的字节，以将下一个字段放到DWORD边界上。
Figure G04148930020040625D000351
                               表14
在讨论了这些消息以及它们的数据结构后，现在将注意力转向用以构造这些消息的消息元素。以下细述在PNRP消息中传输的结构的字节代码。除非另外指明，所有的数字是以网络字节顺序传输，而所有文本在传输前都编码成UTF-8。这些消息元素就是用于刚刚所讨论的消息的积木。基本的消息元素是一个“字段”描述。每个“字段”元素应当开始于消息内的某个4字节边界。这意味着在“字段”间可能有缝隙。
MESSAGE_FIELD元素是用以确保PNRP将来可轻易地扩展的字段描述。对于消息中的每个数据集，它都提供一个标识该字段类型的16位“字段ID”和一个对该字段的16位计数。在表15中呈现了按照本发明的教义构造的MESSAGE_FIELD元素的数据结构细节。
Figure G04148930020040625D000361
                        表15
PNRP_HEADER-类型0x0010用以开始所有的PNRP消息。“协议”+“版本”构成一个4字节的标识符，可用于判定某个接收到的消息是否是真正供PNRP使用的。在表16中呈现了按照本发明的教义构造的PNRP_HEADER元素的数据结构细节。
Figure G04148930020040625D000362
                         表16
使用PNRP_HEADER中的“消息ID”，这样节点就可以确保某个所接收到的主旨为回应该节点所发送的某个消息的消息实际上就是这一回应。举例来说，假定某个节点向另一个节点发送了一个“解析”消息。如在图4中所例示的那样，该第一个节点期望接收某个回应的“授权”消息。但是，没有任何跟踪或追踪对该原始“解析”的回应的方法，就无法保证某个接收到的“授权”消息是合法的还是网络中某个恶意节点的哄骗。通过在“解析”消息中包括一个“消息ID”，产生“授权”消息的节点就可以将这一“消息ID”在下面所讨论的PNRP_HEADER_ACKED字段中包括进其回应。
PNRP_HEADER_ACKED-类型0x0018是一个完整的PNRP消息头，用以标识某个所“应答”的消息。在表17中呈现了按照本发明的教义构造的PNRP_HEADER_ACKED元素的数据结构细节。
Figure G04148930020040625D000371
                          表17
由于PNRP被指明工作在IPv6网络中，使用IPV6_ENDPOINT-类型0x0021元素。该结构指明了一个IPv6网络端点。还有一个标志可以用以指示节点对正在进行的“解析”的功用。“路径标志”用来指示某个发送到“地址”的“解析”是被“接受”还是被“拒绝”。而且如果该“地址”是一个邻近的邻居，可以设置“可疑”标志，因为该节点应当知道其所有邻近的邻居。“地址已删除”指示符在调试期间使用，以将某个条目标记为已删除，而不必真的删除它。这些指示符如下：
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。在表18中呈现了按照本发明的教义构造的IPV6_ENDPOINT元素的数据结构细节。
Figure G04148930020040625D000372
设定成UDP。
2  2  USHORT 端口 IPv6端口。
4  16  BYTE[16] 地址 IPv6地址。
20
                          表18
PNRP_ID-0x0030元素是一个128位P2P ID和一个128位服务位置的串联。在表19中呈现了按照本发明的教义构造的PNRP_ID元素的数据结构细节。
                        表19
TARGET_PNRP_ID-0x0038是用于某个“解析”请求或其相应“回应”的目标ID。在表20中呈现了按照本发明的教义构造的TARGET_PNRP_ID元素的数据结构细节。
                         表20
VALIDATE_PNRP_ID-0x0039是对之请求验证或授权的PNRP ID。在表21中呈现了按照本发明的教义构造的VALIDATE_PNRP_ID元素的数据结构细节。
Figure G04148930020040625D000391
                          表21
FLAGS_FIELD-0x0040标识了用于特定于上下文的目的的一个位字段的标志。在表22中呈现了按照本发明的教义构造的FLAGS_FIELD元素的数据结构细节。
Figure G04148930020040625D000392
                        表22
RESOLVE_CONTROLS-0x0041字段包含了要在处理“解析”或“回应”时使用的信息。标志被用来指示该“解析”是否是原路返回的，或者是否请求某个“授权”消息。这些标志包括：RF_IGNORE_NEXT_HOP-0x0001；RF_SEND_CHAIN-0x0004；RF_DONT_REMOVE_PATH_ENTRIES-0x0008，只用于调试；以及RF_TRACING_ON-0x0010，只用于调试。“最大站数”限制了在完成“解析”前的站数。“操作代码”描述了应当如何进行匹配。对于“ANY”代码，匹配只要头上的128位(P2P ID)，而对于“NEAREST”代码，还有考虑“服务位置”。“操作代码”还确定匹配是否应当考虑在同一节点上注册为“解析”的发起者的ID。这些操作代码包括：
SEARCH_OPCODE_NONE-0；
SEARCH_OPCODE_ANY_PEERNAME-1；
SEARCH_OPCODE_NEAREST_PEERNAME-2；
SEARCH_OPCODE_NEAREST64_PEERNAME-4；以及
SEARCH_OPCODE_UPPER_BITS-8。“精度”设定了ID与实际位数相匹配的精度。如果操作代码是SEARCH_OPCODE_UPPER_BITS，就使用该值。
“原因”用以指示该“解析”是由于缓存维护而作为“修复”过程的一部分发送，还是由于某个应用请求而作为“注册”的一部分发送。这些“原因”包括：
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_NONE-0；
RESULT_FOUND_MATCH-1；RESULT_MAX_HOP_LIMIT_HIT-2；
RESULT_NO_BETTER_PATH_FOUND-3；以及
RESULT_TOO_MANY_MISSES-4。事务ID由某个请求的发起者使用来与“回应”相关联。“解析”的发起者设置“事务ID”值，而发起“回应”的节点在“回应”消息中重复该值。中间节点都不应当改变该值。在表23中呈现了按照本发明的教义构造的RESOLVE_CONTROLS元素的数据结构细节。
应当将ID的上128位特别对待吗？
4  2  USHORT 精度 要匹配的有效位数
6  1  BYTE 原因代码 描述发起“解析”的原因的代码-应用请求、修复探测、注册、缓存维护等。
应当将ID的上128位特别对待吗？
7  1  BYTE 结果代码 描述返回“回应”的原因的代码-找到匹配、达到“最大站数”限制、未找到更佳路径等。
8  4  ULONG 事务ID 事务ID值
12
                        表23
CACHE_LEVEL-类型0x0042元素描述了在执行“修复”时要使用哪个缓存层。这在进行某个分隔缓存修复时使用。在表24中呈现了按照本发明的教义构造的CACHE_LEVEL元素的数据结构细节。
                        表24
FLOOD_CONTROLS-类型0x0043元素包含在处理“充溢”时要使用的信息。发送该“充溢”的原因是唯一使用的代码。在表25中呈现了按照本发明的教义构造的FLOOD_CONTROLS元素的数据结构细节。
步请求、经由“解析”发现了CPA、经由“充溢”发现了CPA、进行修复等。
3
                          表25
CPA_SOURCE-类型0x0058是在“恳求”消息中用作源CPA的CPA。该CPA为网络传输而被编码。在表26中呈现了按照本发明的教义构造的CPA_SOURCE元素的数据结构细节。
Figure G04148930020040625D000421
                      表26
CPA_BEST_MATCH-类型0x0059元素是在“解析”或“回应”中用作“最佳匹配”的CPA。该CPA为网络传输而被编码。在表27中呈现了按照本发明的教义构造的CPA_BEST_MATCH元素的数据结构细节。
                        表27
PNRP_ID_ARRAY-类型0x0060元素包括了存储在一个数组中的针对“广告”和“请求”消息的PNRP ID。下面描述了这些数据，包括数组的大小。在表28中呈现了按照本发明的教义构造的PNRP_ID_ARRAY元素的数据结构细节。
Figure G04148930020040625D000423
数，包括头部。应当设为12+(A*32)。
4  2  USHORT 元素字段类型 对每个数组条目类型的标识符。应当为0x0030，PNRP_ID。
6  2  USHORT 条目长度 每个数组元素长度的字节数。应当为32。
8  A*32  PNRP_ID ID列表 PNRP ID的数组。
8+A*32
                       表28
IPV6_ENDPOINT_ARRAY-类型0x0071元素是所有已经访问过的节点的一个数组。“充溢”的消息会访问多个节点。每个已经访问过或发送向的节点都进入这一数组。下面描述了这些数据，包括数组的大小。在表29中呈现了按照本发明的教义构造的IPV6_ENDPOINT_ARRAY元素的数据结构细节。
Figure G04148930020040625D000431
  8   A*20   IPV6_ENDPOINT[]   端点数组   端点的数组。
  8+A*20
                       表29
IPV6_REFERRAL_ADDRESS-类型0x0072元素是一个特别用以为发送“解析”提供一个备用地址的IPv6端点。当某个节点不需要传递某个“解析”，但需要提供某个某些其它节点可以尝试的地址时，在“授权”消息中使用这一字段。在表30中呈现了按照本发明的教义构造的
IPV6_REFERRAL_ADDRESS元素的数据结构细节。
                         表30
IPV6_REFERRAL_ID-类型0x0073元素与IPv6_Referral_Address一起使用，以指示用作推举的PNRP ID。在表31中呈现了按照本发明的教义构造的IPV6_REFERRAL_ID元素的数据结构细节。
Figure G04148930020040625D000442
                             表31
“证书链”(CERT_CHAIN)-类型0x0080元素是通过使用Windows CAPIAPI来建立的。首先将构成该链的证书放入一个CAPI内存中的证书储备，而后将其导出成一个PKCS7编码的证书储备。将这一导出的储备不作改变而发送。
WCHAR-类型0x0084元素被定义来保存单个的UNICODE字符。它只作为UNICODE数组字段(如“分类符”)的部分来使用。
CLASSIFIER-类型0x0085元素是用作同等点名称的基础的UNICODE“分类符”字符串。它被编码成一个WCHAR元素的数组。在表32中呈现了按照本发明的教义构造的CLASSIFIER元素的数据结构细节。
                       表32
HASHED_NONCE-类型0x0092元素是一个被包括在“广告”消息中的加密了的“现时”值。期望接收者将拥有解密该“现时”的密钥。在表33中呈现了按照本发明的教义构造的HASHED_NONCE元素的数据结构细节。
“现时” 值。
4
                         表33
NONCE-类型0x0093元素是一个被包括在“请求”消息中的解密了的“现时”值。期望接收者将验证该解密了的“现时”与其加密前发送的值相符。在表34中呈现了按照本发明的教义构造的NONCE元素的数据结构细节。
                         表34
SPLIT_CONTROLS-类型0x0098元素在以一系列分段而不是以单个消息来发送某个长消息时使用。每个分段都包括了“分割控制”字段，这样就可以由接收者来构造该消息。在表35中呈现了按照本发明的教义构造的SPLIT_CONTROLS元素的数据结构细节。
                         表35
PNRP_TRACE-类型0x0099元素在调试期间使用，以保存可以在“解析”与“回应”消息之间从站到站运载的数据。它用以存储跟踪数据。在协议的最终版本中可能不支持。
前面对本发明多种实施例的描述是为例示与描述目的而呈现的，无意将本发明穷尽或限制于所揭示的精确实施例。在以上教义的光亮下，无数修改或变更都是可能的。所讨论的实施例是选择并描述来提供本发明原则及其实际应用的最佳例示，因而使相关技术领域的某个普通行家能以适于所预期的特殊用途的多种实施例及多种修改来利用本发明。如通过根据公平、合法、公正地授予的幅度来解读所附权利要求而判定的那样，所有这样的修改与变更都是在本发明的范围之内。

Claims (2)

1.一种在对等网络中向第一节点提供对等节点的对等名称解析协议标识的方法，所述方法包括以下步骤：
在第二节点处接收来自所述第一节点的“恳求”信息，以请求对等名称解析协议标识PNRP ID，其中所述“恳求”信息至少包括指示“消息类型”为“恳求”的头部信息单元和杂凑的现时单元；
在所述第二节点处从该第二节点的缓存中选择一已发布的PNRP ID列表；
在第二节点处生成“广告”信息，其中所述“广告”信息至少包括指示“消息类型”为“广告”的头部应答信息单元、来自所述“恳求”信息的所述杂凑的现时单元和PNRP ID数组信息单元，其中所述PNRP ID数组信息单元包括从所述第二节点的缓存中选择的所述PNRP ID列表；
向所述第一节点发送所述“广告”信息，并在所述第二节点处保留具有所述杂凑的现时单元的所述“广告”信息所发送的状态；以及
第一节点处检查在所述“广告”信息中的PNRP ID列表，并且在所述第一节点处选择该第一节点需要包括在其缓存中的PNRP ID。
2.一种在对等网络中向第一节点提供对等节点的对等名称解析协议标识的系统，所述系统包括：
用于在第二节点处接收来自所述第一节点的“恳求”信息，以请求对等名称解析协议标识PNRP ID的装置，其中所述“恳求”信息至少包括指示“消息类型”为“恳求”的头部信息单元和杂凑的现时单元；
用于在所述第二节点处从该第二节点的缓存中选择一已发布的PNRP ID列表的装置；
用于在第二节点处生成“广告”信息的装置，其中所述“广告”信息至少包括指示“消息类型”为“广告”的头部应答信息单元、来自所述“恳求”信息的所述杂凑的现时单元和PNRP ID数组信息单元，其中所述PNRP ID数组信息单元包括从所述第二节点的缓存中选择的所述PNRP ID列表；
用于向所述第一节点发送所述“广告”信息，并在所述第二节点处保留具有所述杂凑的现时单元的所述“广告”信息所发送的状态的装置；以及
用于在第一节点处检查在所述“广告”信息中的PNRP ID列表，并在所述第一节点处选择该第一节点需要包括在其缓存中的PNRP ID的装置。
CN2004100489300A 2003-06-13 2004-06-11 对等名称解析电信协议及在此使用的消息格式数据结构 Expired - Fee Related CN1574840B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/461,940 2003-06-13
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

Publications (2)

Publication Number Publication Date
CN1574840A CN1574840A (zh) 2005-02-02
CN1574840B true CN1574840B (zh) 2010-07-14

Family

ID=33299879

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2004100489300A Expired - Fee Related CN1574840B (zh) 2003-06-13 2004-06-11 对等名称解析电信协议及在此使用的消息格式数据结构

Country Status (14)

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

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
WO2003015341A2 (en) * 2001-08-04 2003-02-20 Kontiki, Inc. Method and apparatus for facilitating secure distributed content delivery across a computer network
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
US20050149732A1 (en) * 2004-01-07 2005-07-07 Microsoft Corporation Use of static Diffie-Hellman key with IPSec for authentication
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
WO2006071062A1 (en) * 2004-12-30 2006-07-06 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
US7912959B2 (en) * 2005-03-15 2011-03-22 Microsoft Corporation Architecture for building a peer to peer messaging platform
US7493413B2 (en) * 2005-03-15 2009-02-17 Microsoft Corporation APIS to build peer to peer messaging applications
US20060242235A1 (en) * 2005-04-22 2006-10-26 Microsoft Corporation Presence monitoring in a serverless peer-to-peer system
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
US8036140B2 (en) * 2005-04-22 2011-10-11 Microsoft Corporation Application programming interface for inviting participants in a serverless peer to peer network
US7571228B2 (en) * 2005-04-22 2009-08-04 Microsoft Corporation Contact management in a serverless peer-to-peer system
US20060239206A1 (en) * 2005-04-22 2006-10-26 Microsoft Corporation Apparatus and method for network identification among multiple applications
US7603482B2 (en) * 2005-04-22 2009-10-13 Microsoft Corporation DNS compatible PNRP peer name encoding
AU2006245467B2 (en) * 2005-05-06 2010-04-29 Nokia Technologies Oy 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
EP1802072B1 (en) * 2005-12-22 2010-05-05 Microsoft Corporation Peer-to-peer message format
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
WO2010027495A1 (en) * 2008-09-04 2010-03-11 Trilliant Networks, Inc. A system and method for implementing mesh network communications using a mesh network protocol
US9253143B2 (en) * 2008-09-17 2016-02-02 Azureus Software, Inc. Reverse 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
US9325787B2 (en) * 2009-05-18 2016-04-26 Cisco Technology, Inc. Limited broadcast, peering among DHTs, broadcast put of limited content only
US20100293223A1 (en) * 2009-05-18 2010-11-18 Cisco Technology, Inc. Limiting storage messages in peer to peer network
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
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
US9444564B2 (en) 2012-05-10 2016-09-13 Qualcomm Incorporated Selectively directing media feeds to a set of target user equipments
JP2016501463A (ja) * 2012-11-12 2016-01-18 アルカテル−ルーセント 管理アクションが仮想シャーシの分割をトリガーするという警告を発行するかどうかが決定される、ネットワークノード、および仮想シャーシシステム内で動作可能であるノードにおける方法
US10530684B2 (en) * 2015-05-19 2020-01-07 International Business Machines Corporation Management of unreachable OpenFlow rules
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
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
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
EP3541040B1 (en) * 2018-03-16 2022-04-13 Acklio Method and apparatus for processing message data
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

Family Cites Families (29)

* 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
US6985958B2 (en) * 2001-03-14 2006-01-10 Microsoft Corporation Messaging infrastructure for identity-centric data access
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
US7068789B2 (en) * 2001-09-19 2006-06-27 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) group security infrastructure and method
US7493363B2 (en) 2001-09-19 2009-02-17 Microsoft Corporation Peer-to-peer group management and method for maintaining peer-to-peer graphs
US7299351B2 (en) * 2001-09-19 2007-11-20 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) 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

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Sklower K. et al.The PPP Multilink Protocol.Request for Comments:1990.1996,1-24. *

Also Published As

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

Similar Documents

Publication Publication Date Title
CN1574840B (zh) 对等名称解析电信协议及在此使用的消息格式数据结构
US7336623B2 (en) Peer-to-peer cloud-split detection and repair methods
US7051102B2 (en) Peer-to-peer name resolution protocol (PNRP) security infrastructure and method
US10193907B2 (en) Intrusion detection to prevent impersonation attacks in computer networks
CN101471878B (zh) 对等会话起始协议网络的安全路由方法、网络系统及设备
CN101637004A (zh) 用于通信系统中的前缀可达性的方法
Shah A novel approach for securing IPv6 link local communication
CN103546439B (zh) 内容请求的处理方法及装置
CN108768853B (zh) 基于域名路由器的分布式混合域名系统及方法
Banks et al. Davis social links: integrating social networks with internet routing
Prem Sankar et al. B-secure: a dynamic reputation system for identifying anomalous BGP paths
Wirtgen et al. A first step towards checking BGP routes in the dataplane
de Sousa Regateiro How secure are blockchains?
Zarin et al. Blockchain Nodes are Heterogeneous and Your P2P Overlay Should be Too: PODS
Comer et al. Effective border gateway protocol protection that does not require universal adoption of a public key infrastructure
Wang et al. Trustworthy Mobile Network Architecture Based on Locator/Identity Split.

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
ASS Succession or assignment of patent right

Owner name: MICROSOFT TECHNOLOGY LICENSING LLC

Free format text: FORMER OWNER: MICROSOFT CORP.

Effective date: 20150506

C41 Transfer of patent application or patent right or utility model
TR01 Transfer of patent right

Effective date of registration: 20150506

Address after: Washington State

Patentee after: Micro soft technique license Co., Ltd

Address before: Washington State

Patentee before: Microsoft Corp.

CF01 Termination of patent right due to non-payment of annual fee
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20100714

Termination date: 20180611