MXPA04005718A - Protocolo cableado de resolucion de nombre interpar y estructura de datos de formato de mensaje para usarse en el mismo. - Google Patents

Abstract

Se presenta una estructura de datos extensibles para mensajes en un protocolo de resolucion de nombre internar. Esta estructura de datos de mensaje utiliza un numero de campos, cada uno conteniendo un elemento de mensaje. Preferiblemente, el primer campo es el encabezado del mensaje que incluye la informacion del protocolo e identifica el tipo de mensaje. Cada elemento de mensaje contiene un numero de campos. Esos campos de elemento de mensaje incluyen un campo de tipo, un campo de longitud, y el contenido o carga util del elemento de mensaje. En una modalidad, por lo menos diez mensajes se forman para la operacion apropiada de un Protocolo de Resolucion de Nombre Internar (PNPR), que incluye los mensajes RESOLVER, RESPUESTA, SOLICITAR, PUBLICAR, DEMANDAR, INUNCADR, INVBESTIGAR, AUTORIDAD, ACK y REPARAR.

Description

PROTOCOLO CABLEADO DE RESOLUCION DE NOMBRE INTERPAR Y ESTRUCTURA DE DATOS DE FORMATO DE MENSAJE PARA USARSE EN EL MISMO CAMPO DE LA INVENCION La presente invención se refiere en general a protocolos de comunicación en una infraestructura interpar, y más particularmente a estructura de datos de formato de mensaje que permiten la comunicación estructura en una gráfica interpar.

ANTECEDENTES DE LA INVENCION Varias tecnologías de comunicación en el Internet permiten a los usuarios con intereses comunes colaborar, compartir archivos, platicar con otros, multidifundir audio y video para presentaciones y reuniones de grupo, e interconectarse en juegos de jugadores múltiples. Actualmente, sin embargo, la mayoría de las comunicaciones en el Internet toman lugar en un ambiente céntrico de servidor por medio del cual todas las comunicaciones fluyen a o a través de grandes servidores centrales a los cuales los individuos se conectan para unirse y participar en dichas comunicaciones. Con el resurgimiento de la tecnología interpar, el actual modelo céntrico de servidor del Internet la comunicación es rápidamente reemplazado. Ciertamente, las tecnologías interpar permiten a los usuarios ponerse en contacto uno con el otro en un ambiente sin servidor, libre de restricciones de servidor en base a la comunicación de Internet. En un sistema a base a interpar, un usuario anónimamente y en privado puede ser controlado ya que la comunicación ocurre directamente entre compañeros dentro de la red. Sin embargo, mientras la comunicación individual y la compartición de archivos está relativamente bien establecida en redes interpar, el establecimiento, descubrimiento, unión, control y compartición de la información en un ambiente interpar no están bien establecidos. La comunicación interpar, y de hecho todos los tipos de comunicación, dependen de la posibilidad de establecer conexiones válidas entre las entidades o nodos seleccionados. Estas entidades o nodos pueden ser pares (por ejemplo, usuarios o máquinas) o grupos formados dentro de una red interpar. Las conexiones entre los nodos de la gráfica interpar que habilita que la comunicación y la información sean pasadas y entre los nodos. Sin embargo, las entidades pueden tener una o varias direcciones que pueden variar debido a que las entidades se mueven en la red, debido a los cambios de topología, debido a que el alquiler de una dirección no puede ser renovada, debido que la función del grupo o propósito ha cambiado, etc. Una solución arquitectural clásica a este problema de direccionamiento es de esta forma asignar a cada entidad un nombre estable, y para "resolver" este nombre a una dirección actual cuando se necesita una conexión. Este nombre para la traducción de la dirección puede ser muy robusto, y también debe permitir las actualizaciones fáciles y rápidas. El incremento de la probabilidad de que una dirección de entidad pueda ser encontrada por aquellos que están buscando conectarse a ésta, muchos protocolos interpar permiten a las entidades publicar su dirección(es) individual o de grupo a través de varios mecanismos. Algunos protocolos también permiten a un cliente adquirir información de otras direcciones de la entidad a través del procesamiento de solicitudes de otros en la red. Ciertamente, es esta adquisición de información de dirección lo que permite una operación exitosa de estas redes interpar a través del control de una gráfica robusta. Es decir, entre mejor es la información acerca de otros pares y grupos en la red (es decir, entre más robusta es la gráfica), la probabilidad es más grande de que una búsqueda de un recurso en particular o registro converja. Como con un ambiente céntrico de servidor, las gráficas interpar puede estar enteramente abiertas para permitir la búsqueda de archivos en Internet y compartirlos dentro de la gráfica. Sin embargo, debido a que las redes interpar están formadas como una gráfica de usuarios o pares distribuidos, es necesario que la comunicación y los datos (registros) pasen de un par a otro antes de que todos los pares dentro de la red puedan convertirse en peritos de la información compartida. Los sistemas que proveen dicho enrutamiento incluyen Usenet y OSPF. Sin embargo, dicho sistema actual sufre de limitaciones que tienen, a la fecha, limitado el desarrollo completo de tecnología ¡nterpar. Adicionalmente, las redes ¡nterpar actualmente sufren de una carencia de administración de gráficas adecuada que, en ciertos momentos permite a las gráficas "separarse" o dividirse cuando uno de los miembros deja el grupo. En dicho caso, la información de una parte de la gráfica ya no puede pasarse a miembros pares en el otro lado de la partición creada por la salida de uno de los pares. Como una desventaja adicional, no existe un mecanismo adecuado para la detección de dicha partición. Además de los problemas de función existentes en la técnica, la cantidad de tráfico en la red puede fácilmente abrumar a los pares participantes dentro de la nube. El tamaño del mensaje y la estructura complican la habilidad del par para rápidamente procesar los mensajes, y da como resultado un retraso o la caída de las comunicaciones mientras el tamaño de la nube crece. Existe, por lo tanto, una necesidad en la técnica de un protocolo de transmisión de mensajes interpar y estructura de datos que dirijan lo anteriormente descrito y otros problemas existentes en la técnica.

COMPENDIO DE LA INVENCION Los conceptos de la invención descritos en esta solicitud involucran una estructura de datos extensible para mensajes adecuada para uso en un protocolo de resolución de nombre interpar. Esta estructura de datos de mensaje utiliza campos de datos de mensaje para construir varios mensajes de uso para el PNRP. Cada uno de los campos de datos de mensaje contiene un elemento de mensaje. Preferiblemente, el primer campo es el elemento del encabezado del mensaje que incluye la información del protocolo e identifica el tipo de mensaje. Como con los mismos mensajes, cada elemento de mensaje contiene un número de campos de datos de mensajes. Estos campos de elemento de mensaje incluyen el campo de tipo, un campo de longitud, y el contenido o carga útil del elemento de mensaje. El campo de tipo incluye un identif icador que designa el tipo del elemento de mensaje. El campo de longitud identifica la longitud del elemento de mensaje, incluyendo el tipo de campo y los campos de longitud. En una modalidad, por lo menos diez mensajes se forman para la operación apropiada de un Protocolo de Resolución de Nombre Interpar (PNRP). Estos diez mensajes incluyen un mensaje de RESOLVER, un mensaje de RESPUESTA, un mensaje de SOLICITAR, un mensaje de PUBLICAR, un mensaje de DEMANDA, un mensaje de INUNDAR, un mensaje de AUTORIDAD, un mensaje ACK, y un mensaje de REPARAR. Estos mensajes se construyen de veintidós diferentes elementos del mensaje existentes en una modalidad preferida.

BREVE DESCRIPCION DE LOS DIBUJOS Los dibujos acompañantes incorporados en y formado una parte de la especificación ilustran varios aspectos de la presente invención, y junto con la descripción sirven para explicar los principios de la invención. En los dibujos: La Figura 1 es un diagrama de bloque que generalmente ilustra un sistema de computadora ilustrativo en el cual la presente invención reside; La Figura 2 es un diagrama de bloque simplificado que ilustra los elementos funcionales del Protocolo de Resolución de Nombre Interpar (PNRP); La Figura 3 es un diagrama de flujo del mensaje de protocolo que ilustra un aspecto de la presente invención; La Figura 4 es un diagrama de flujo del mensaje de protocolo que ilustra otro aspecto de la presente invención; La Figura 5 es un diagrama de la estructura de datos que ilustra el modelo de la estructura de datos extensible de la presente invención que permite la construcción de mensajes de la presente invención; y La Figura 6 es un diagrama de la estructura de datos simplificada que ilustra la construcción de un mensaje ilustrativo de la presente invención. Ya que la invención será descrita en conexión con ciertas modalidades preferidas, no se pretende limitarla a esas modalidades.

Por el contrario, se pretende cubrir todas las alternativas, modificaciones y equivalentes como incluidos dentro del espíritu y alcance de la invención como se define por las reivindicaciones anexas.

DESCRIPCION DETALLADA DE LA INVENCION Cambiando ahora a los dibujos, en donde números de referencia similares se refieren a elementos similares, la invención se ilustra como estando implementada en un ambiente de computación adecuado. Aunque no se requiere, la invención será descrita en el contexto general de instrucciones ejecutables por computadora, tales como módulos de programa, siendo ejecutados por una computadora personal. Generalmente, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc. que realizan tareas particulares o ¡mplementan tipos de datos abstractos particulares. Además, aquellos con experiencia en la técnica apreciarán que la invención puede ser practicada con otras configuraciones de sistema de computadora, incluyendo dispositivos portátiles, sistemas multiprocesador, electrónicos de consumidor en base a microprocesador o programables, PCs en red, minicomputadoras, computadoras de marco principal y similares. La invención también puede ser practicada en ambientes de computación distribuidos en donde las tareas se realizan a través de dispositivos de procesamiento remoto que están enlazados a través de una red de comunicaciones. En un ambiente de computación distribuido, los módulos de programa pueden estar localizados en ambos dispositivos de almacenamiento de memoria, locales y remotos. La Figura 1 describe un ambiente operativo de computación adecuado 100 en el cual la invención puede ser implementada. El ambiente del sistema de computación 100 es solamente un ejemplo de un ambiente operativo adecuado y no pretende sugerir ninguna limitación al alcance del uso o funcionalidad de la invención. Tampoco el ambiente de computación 100 debe ser interpretado como teniendo ninguna dependencia o requerimiento relacionado con ninguno o un combinación de componentes ilustrados en el ambiente operativo ilustrativo 100. La invención es operacional con otros numerosos ambientes de sistema de computación o configuraciones de propósito general o propósito especial. Ejemplos de sistemas de computación bien conocidos, ambientes y/o configuraciones que pueden ser adecuados para uso con la invención incluyen, pero no se limitan a, computadoras personales, computadoras servidor, dispositivos de computación portátiles, dispositivos de computación portables, sistemas multiprocesador, sistemas en base a microprocesador, cajas encima del televisor, electrónicos de consumidor programables, PCs en red, minicomputadoras, computadoras de marco principal, ambientes de computación distribuidos que incluyen cualquiera de los sistemas o dispositivos anteriores, y similares.

La invención puede ser descrita en el contexto general de instrucciones ejecutables por computadora, tales como módulos de programa, siendo ejecutados por una computadora. En general, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos, etc. que realizan tareas particulares o implementan tipos de datos abstractos particulares. La invención . también puede ser practicada en ambientes de computación distribuidos en donde las tareas se llevan a cabo a través de dispositivos de procesamiento remoto que están enlazados a través de una red de comunicaciones. En un ambiente de computación distribuido en red, los módulos de programa pueden estar localizados en ambos medios de almacenamiento de computadora locales y remotos incluyendo dispositivos de almacenamiento de memoria. Con una referencia a la Figura 1, un sistema ilustrativo para implementar la invención incluye un dispositivo de computación de propósito general en la forma de una computadora 110. Los componentes de la computadora 110 pueden incluir, pero no se limitan a, una unidad de procesamiento 120, una memoria del sistema 130, y un conductor común del sistema 121 que acopla varios componentes del sistema incluyendo la memoria del sistema a la unidad de procesamiento 120. El conductor común del sistema 121 puede ser cualquiera de varios tipos de estructuras de conductor común incluyendo un conductor común de memoria o controlador de memoria, un conductor común periférico, y un conductor común local utilizando cualquiera de una variedad de estructuras de conductores comunes. A manera de ejemplo, y no limitación, dichas arquitecturas incluyen el conductor común de Arquitectura Estándar de la Industria (ISA), el conductor común de la Arquitectura del Canal Micro (MCA), el conductor común Mejorado ISA (EISA), el conductor común local de la Asociación de Estándares Electrónicos de Video (VESA), y el conductor común de Interconexión del Componente Periférico (PCI) también conocido como conductor común Mezanine. La computadora 110 típicamente incluye una variedad de medios legibles por computadora. Los medios legibles por computadora pueden ser cualquier medio disponible que pueda ser accedido por la computadora 110 e incluye medios volátiles y no volátiles, medios removibles y no removibles. A manera de ejemplo, y no limitación, los medios legibles por computadora pueden comprender medios de almacenamiento por computadora y medios de comunicación. Los medios de almacenamiento por computadora incluyen ambos medios volátiles y no volátiles, removibles y no removibles, en cualquier método o tecnología para el almacenamiento de información, tal como instrucciones ejecutables por computadora, estructuras de datos, módulos de programa u otros datos. Los medios de almacenamiento por computadora incluyen, pero no se limitan a, RAM, ROM, EEPROM, memoria no volátil, u otra tecnología de memoria, CDROM, discos versátiles digitales (DVD) u otro almacenamiento en disco óptico, casetes magnéticos, cinta magnética, almacenamiento en disco magnético y otros dispositivos de almacenamiento magnético, o cualquier otro medio que puede ser utilizado para almacenar la información deseada y que puede ser accedida por la computadora 110. Los medios de comunicación típicamente modalizan las instrucciones legibles por computadora, estructuras de datos, módulos de programa u otros datos en una señal de datos modulada tal como una onda portadora, u otro tipo de mecanismo de transporte e incluye cualquier medio de distribución de información. El término "señal de datos modulada" significa una señal que tiene una o más de sus características fijadas o cambiadas en tal forma que codifica la información en la señal. A manera de ejemplo, y no limitación, los medios de comunicación incluyen medios por cable tal como una red cableada o conexión directa-cableada, y medios inalámbricos tal como medios inalámbricos acústicos, RF, infrarrojos y otros medios inalámbricos. Las combinaciones de cualquiera de los anteriores también se pueden incluir dentro del alcance de los medios legibles por computadora. La memoria del sistema 130 incluye medios de almacenamiento por computadora en la forma de memoria volátil y/o no volátil tales como memoria de solo lectura (ROM) 131 y memoria de acceso aleatorio (RAM) 132. Un sistema de entrada/salida básico 133 (BIOS), conteniendo las rutinas básicas que ayudan a la transferencia de información entre elementos dentro de la computadora 110, tales como durante el arranque, se almacenan tópicamente en ROM 131. La RAM 132 típicamente contiene datos y/o módulos de programa que son inmediatamente accesibles para y/o actualmente siendo operados por la unidad de procesamiento 120. A manera de ejemplo, y no limitación, La Figura 1 ilustra el sistema operativo 134, programas de aplicación 135, otros módulos de programa 136, y datos de programa 137. La computadora 110 también puede incluir otros medios de almacenamiento removibles/no removibles, volátiles/no volátiles. A manera de ejemplo solamente, la Figura 1 ilustra una unidad de disco duro 141 que lee de o escribe en el medio no removible, no volátil magnético, una unidad de disco duro magnética 151 que lee de o escribe en un disco magnético removible, no volátil 152, y una unidad de disco óptico 155 que lee de o escribe en una disco óptico no volátil 156, tal como un CD ROM u otro medio óptico. Otros medios de almacenamiento por computadora removibles/no removibles, volátiles/no volátiles que pueden ser utilizados en el ambiente de operación ilustrativo incluyen, pero no se limitan a, casetes de cinta magnética, tarjetas de memoria no volátil, discos versátiles digitales, cintas de video digitales, RAM de estado sólido, ROM de estado sólido, y similares. La unidad de disco duro 141 está típicamente conectada al conductor común del sistema 121 a través de la interfase de memoria no removible tal como la interfase 140, una unidad de disco magnético 151 y una unidad de disco óptico 155 están típicamente conectados al conductor común del sistema 121 a través de la interfase de memoria removible, tal como la interfase 150. Las unidades y sus medios de almacenamiento por computadora asociados discutidos anteriormente e ilustrados en la Figura 1, proporcionan almacenamiento de instrucciones legibles por computadora, estructuras de datos, módulos de programa y otros datos para la computadora 110. En la Figura 1, por ejemplo, la unidad de disco duro 141 está ilustrada como almacenando el sistema operativo 144, los programas de aplicación 145, otros módulos de programa 146, y los datos de programa 147. Observar que estos componentes pueden ya sea ser el mismo o diferentes del sistema operativo 134, programas de aplicación 135, oros módulos de programa 136 y datos de programa 137. Al sistema operativo 144, programas de aplicación 145, otros módulos de programa 146, y datos de programa 147 se les han dado números diferentes aquí para ¡lustrar que, al mínimo, son diferentes copias. Un usuario puede capturar comandos e información en la computadora 110 a través de los dispositivos de entrada tales como un teclado 162 y un dispositivo de apuntamiento 161, comúnmente referido como un ratón, seguibola o almohadilla sensible al tacto. Otros dispositivos de entrada (no mostrados) pueden incluir un micrófono, palanca de mandos, almohadillas de juegos, antena parabólica, escáner o similar. Estos y otros dispositivos de entrada por lo general están conectados a la unidad de procesamiento 120 a través de una interfase de usuario 160 que está acoplada al conductor común del sistema, pero pueden estar conectados a través de otras interfases y estructuras de conductores comunes, tales como un puerto paralelo, un puerto de juego o conductor común serial universal (USB). Un monitor 191 u otro tipo de dispositivo de pantalla también está conectado al conductor común del sistema 121 a través de una interfase, tal como una interfase de video 190. Además del monitor, las computadoras también pueden incluir otros dispositivos de salida periféricos tales como bocinas 197 y la impresora 196, los cuales pueden conectarse a través de una interfase periférica de salida 195.

La computadora 110 puede operar en un ambiente conectado en red utilizando conexiones lógicas a una o más computadoras remotas, tales como la computadora remota 180. La computadora remota 180 puede ser una computadora personal, un servidor, un direccionador, una PC en red, un dispositivo par u otro nodo de red común, y típicamente incluye muchos o todos los elementos descritos anteriormente con relación a la computadora 110, aunque solamente un dispositivo de almacenamiento de memoria 181 ha sido ilustrado en la Figura 1. Las conexiones lógicas descritas en la Figura 1 incluyen una red de área local (LAN) 171 y una red de área amplia (WAN) 173, pero también pueden incluir otras redes. Dichos ambientes conectados en red son lugares comunes de oficinas, redes de computadora a nivel empresa, intranets y el Internet. Cuando se utiliza en un ambiente conectado en LAN, la computadora 110 está conectada a la otra LAN 171 a través de una interfase de red o adaptador 170. Cuando se utiliza en un ambiente conectado en WAN, la computadora 110 típicamente incluye un módem 172 u otros medios para establecer comunicaciones a través de la WAN 173, tal como el Internet. El módem 172, el cual puede ser interno o externo, puede estar conectado al conductor común del sistema 121 a través de una interfase de entrada de usuario 160, u otro mecanismo apropiado. En un ambiente conectado en red, los módulos de programa descritos con relación a la computadora 110, o porciones de los mismos, pueden almacenarse en el dispositivo de almacenamiento de memoria remoto. A manera de ejemplo, y no limitación, la Figura 1 ¡lustra programas de aplicación remotos 185 como residentes en el dispositivo de memoria 181. Se apreciará que las conexiones en red mostradas son ilustrativas y que otros medios para establecer enlaces de comunicaciones entre las computadoras pueden utilizarse. En la descripción que sigue, la invención será descrita con referencia a las acciones y representaciones simbólicas de las operaciones que se realizan a través de una o más computadoras, a menos que se indique lo contrario. Es decir, se entenderá que dichas acciones y operaciones, las cuales algunas veces se denominan como siendo ejecutadas por computadora, incluyen la manipulación a través de la unidad de procesamiento de señales eléctricas representando datos en una forma estructurada. Esta manipulación transforma los datos o mantiene su ubicación en el sistema de memoria de la computadora, la cual reconfigura o por el contrario altera la operación de la computadora en una forma bien entendida por aquellos con experiencia en la técnica. Las estructuras de datos en donde los datos se mantienen son ubicaciones físicas de la memoria que tienen propiedades particulares definidas por el formato de los datos. Sin embargo, ya que la invención está siendo descrita en el contexto anteriormente mencionado, no pretenden ser una limitante como aquellos con experiencia en la técnica apreciarán que varias de las acciones y operaciones descritas a continuación también se pueden implementar en hardware. Como se dijo anteriormente, el éxito de un protocolo interpar (P2P) depende de la habilidad del protocolo para establecer conexiones válidas entre entidades seleccionadas. De la misma manera, la formación de grupos en dicha red P2P depende de su habilidad. Debido a que un usuario particular se puede conectar a la red en varias formas en varios lugares que tienen diferentes direcciones, un método preferido es asignar una identidad única al usuario o al grupo, y después resolver esa identidad a una dirección particular o direcciones a través del protocolo. Dicho protocolo de resolución de nombre interpar (PNRP) al cual el sistema de administración de identidad y método de la presente invención encuentra una aplicabilidad particular se describe en la Solicitud co-pendiente No. 09/942,164, intitulada Protocolo de Resolución de Nombre Interpar (PNRP) y Caché Multinivel Para Uso en el Mismo, presentada el 29 de agosto del 2001, en la Solicitud co-pendiente No. 10/122,863, intitulada Arquitectura De Caché Multinivel y Método Para La Administración del Caché para el Protocolo De Resolución De Nombre Interpar, presentada el 15 de abril del 2002, y la Solicitud co-pendiente No. 09/955,923, intitulada Administración de Grupo Interpar y Método Para el Control de Gráficas Interpar, presentada el 19 de septiembre del 2001, las enseñanzas y descripciones de las cuales de incorporan aquí en su totalidad por referencias en la presente. De la misma manera, la Solicitud co-pendiente No. 09/956,260, intitulada Infraestructura y Método de Seguridad del Protocolo de Resolución De Nombre Interpar (PNRP) presentada el 19 de septiembre del 2001 describe una infraestructuras de seguridad subyacente que asegura que las identidades de las varias identidades dentro de la red son válidas, sin una sobrecarga innecesaria de la red con exceso de tráfico. En el ambiente de agrupamiento P2P, la Solicitud co-pendiente No. 09/955,924, intitulada Infraestructura y Método de Seguridad de Grupo del Protocolo de Resolución De Nombre Interpar (PNRP), presentada el 10 de septiembre del 2001, describe la Infraestructura de seguridad subyacente utilizada por dichos grupos. Las enseñanzas y descripción de estas solicitudes también se incorporan en su totalidad por referencia en la presente. Sin embargo, ya que las interfases y métodos de la presente invención encuentran una aplicabllidad particular a y una interacción con dicho PNRP, uno con experiencia en la técnica reconocerá que la presente invención no está limitada a eso, pero tiene aplicabilidad a cualquier sistema o protocolo P2P que desee proveer funciones de administración de gráfica P2P. Como se discutió en la solicitud co-pendiente anteriormente incorporada que describe el PNRP y para proporcionar algún uso de fondo, el protocolo de resolución de nombre interpar (PNRP) es un protocolo de resolución de nombre-a-dirección basado en el interpar. A los recursos pares se les puede dar un Nombre Par. Una aplicación puede registrar un Nombre Par con PNRP para hacerlo descubrible para otros pares. Otras aplicaciones pueden utilizar PRNP para resolver un Nombre Par para obtener una dirección IP y puerto correspondiente de la aplicación registrada. PNRP no proporciona ningún mecanismo para encontrar o navegar para Nombres Pares. El mecanismo para distribuir Nombres Pares debe ser hecho a través de otros medios. La resolución de Nombres Pares a direcciones se hace teniendo los pares participantes cooperando en el envío de mensajes a otro, y manteniendo un caché distribuido del Nombre Par a los mapeos de direcciones. El mecanismo de registro y resolución no depende de la existencia de servidores, excepto para la inicialización. Cuando una instancia PNRP llega, necesita encontrar la dirección de alguna otra instancia PNRP con la cual intercambiar datos. Sí no hay otros medios disponibles, entonces los servidores bien conocidos se utilizan para obtener una lista de otras instancias PNRP. En otras palabras, PNRP les permite a las aplicaciones interpar registrar un Nombre Par en el mapeo del punto final, y resolver un Nombre Par para obtener el punto final. En este punto algunas definiciones serían apropiadas. Un Nombre Par es una cadena que identifica un recurso par. Para ser capaz de registrar un Nombre Par, una aplicación debe tener acceso a un par clave público/privado. El par clave se utiliza para firmar algunos mensajes para evitar el sabotaje. Un Nombre Par puede también ser derivado de la clave pública, para habilitar la verificación de la propiedad de la identidad. Un punto final es una dirección IPv4/IPv6, puerto y protocolo. En un hecho actual una lista de puntos finales puede ser registrada con un Nombre Par individual, y la lista se devuelve cuando el Nombre Par se resuelve. U nodo es una instancia del servicio del Protocolo PNRP. Por lo general existe un nodo por computadora. Una nube es una red de nodos en la que se pueden alcanzar uno al otro. Un nodo individual puede estar conectado a más de una nube. Una nube tiene una propiedad de alcance que es equivalente a los alcances definidos en IPv6-Global, Local del Sitio, y Local del Enlace. Un nodo puede tener múltiples nubes de Local de Sitio y múltiples nubes de Local de Enlace. La comunicación entre los nodos nunca debe de cruzar de una nube a otra. Los nombres de las nubes se utilizan para distinguir las nubes. Un Nombre Par puede ser registrado en más de un nodo. El PNRP mantiene cada registro diferente. La lista del punto final asociada con cada instancia de Nombre Par será diferente. Dentro de un nodo, también es posible registrar un Nombre Par o más de una nube a la cual el nodo está conectado. Cada uno de estos registros es diferente. Normalmente, la lista del punto final será diferente en cada una de estas instancias también. Cuando un nodo trata de resolver un Nombre Par, hace esto en una nube seleccionada. La resolución será exitosa solamente si el Nombre Par está registrado en la misma nube. Es posible resolver un Nombre Par en más de una nube simultáneamente, pero estás son tratadas como solicitudes de resolución independientes. El servicio PNRP está comprendido de varios módulos que trabajan juntos, como se ilustra en la Figura 2. El componente de Administración del Servicio 200 negocia con el mantenimiento normal tal como iniciando y deteniendo el servicio PNRP. El servidor PNRP y fragmentos 202 proporcionan la interfase entre los procesos del cliente y el servicio PNRP. Esto maneja la interfase expuesta, proporcionando puntos de entrada para las solicitudes, y las notificaciones de los eventos y terminación de la solicitud. También negocia con la recuperación de la terminación del proceso del cliente. El Administrador de Nube 204 mantiene el estado de las solicitudes específicas del cliente y mantiene la lista de nubes PNRP disponibles. Es responsable de crear nubes e informar a los clientes de los cambios a los estados de la nube. El Administrador del Caché 206 mantiene el caché PNRP local, y la lista de nombres PNRP registrados localmente para cada nube. Esto es parte del caché PNRP distribuido. Provee la selección de la búsqueda y el siguiente punto de conexión para resolver solicitudes que vienen de otras computadoras. Realiza el mantenimiento en su propio caché iniciando periódicamente solicitudes de resolución para asegurar un caché bien estructurado. Realiza la detección de divisiones de la nube, y trata de repararlas. Proporciona la habilidad de tener múltiple IDs Pares registrados, y estructuras de caché para soportar cada una. El Administrador de Protocolo 208 negocia con la creación y envío de mensajes PNRP válidos, y procesar los mensajes PNRP recibidos. Trabaja junto con el Administrador de Caché 206 para implementar el protocolo PNRP. Finalmente, el Transporte de Mensaje 201 negocia con el envío y recepción actual de los mensajes. Maneja múltiples interfases y direcciones de red, y detecta los cambios en el grupo de direcciones locales. Si se requieren múltiples protocolos (IPv4 e IPv6), entonces este componente negociará con ambos protocolos. Cada nodo PNRP mantiene un caché del Nombre Par a los mapeos de los puntos finales para algunos otros nodos en una nube. Los mensajes construidos de acuerdo con la presente invención se intercambian entre nodos para distribuir la información acerca de los Nombres Par a los nodos en la nube. Es responsabilidad de cada nodo mantener si caché apropiadamente. Como se describe a través de las aplicaciones identificadas anteriormente, el protocolo PNRP define un nombre de espacio numérico. Cada Nombre Par es convertido a un número, y los números pueden ser comparados para determinar la proximidad en el nombre de espacio. Cuando una solicitud para resolver un Nombre Par llega a un nodo, puede comparar el número con los números en su caché para encontrar un nodo que está numéricamente cercano al nodo deseado. En esta forma la solicitud de resolver se pasa de nodo a nodo, acercándose a su objetivo con cada punto de conexión. Los Nombres Par son convertidos en números de 128 bits llamados IDs de P2P utilizando funciones de desbaratar descritas en las aplicaciones anteriormente incorporadas. El mismo Nombre Par siempre producirá el mismo ID de P2P. Una instancia específica de un registro del Nombre Par también tiene un número de 128 bits llamado una ubicación del servicio. Los dos juntos hacen un número de 256 bits llamado el ID de PNRP. La porción de la ubicación del servicio del ID PNRP hace la instancia especifica del registro del Nombre Par único en la red. Una aplicación puede registrar un Nombre Par con PNRP. Un PNRP se crea del nombre, y mensajes enviados informando otros nodos del registro. El mismo Nombre Par puede ser registrado en más de un nodo. El ID del PNRP será el mismo en cada nodo, pero el ID del PNRP deberá ser el único para cada nodo. Una aplicación puede solicitar resolver un Nombre Par para una dirección. Un ID de PNRP se deriva del Nombre Par, y los mensajes se envían a otros nodos para localizar un nodo que tiene su ID P2P registrado. Cuando un ID P2P es resuelto en una dirección, se devuelve una dirección par certificada (CPA). Esta CPA incluye la parte de la ubicación del servicio del ID del PNRP objetivo, la dirección IP actual, la clave pública, y muchos otros campos. La CPA se firma para prevenir el sabotaje. Un ID P2P dado puede ser registrado a través de varios diferentes nodos. PNRP utiliza un sufijo de "ubicación de servicio" para asegurar que cada instancia de registro tenga un ID de PNRP único. Una "ubicación de servicio" es un número de 128 bits correspondiente a un punto final del servicio de red único. El valor se crea combinando la dirección IPv6, el puerto, el protocolo, y la parte de la clave pública. Las ubicaciones del servicio deberían ser consideradas opacas para los clientes PNRP. Una ubicación del servicio tiene dos propiedades importantes. En cualquier momento, una ubicación del servicio identifica una instancia única de un Nombre Par. Cuando dos ubicaciones de servicio son comparadas, la longitud del prefijo común para cada una medida razonable de la proximidad de la red. Dos ubicaciones de servicios que inician con los mismos cuatro bits están usualmente no muy separados que dos que inician con los mismos tres bits. Estos beneficios pueden aplicarse solamente para direcciones IPv6 de unidifusión nativas de alcance Global. La creación y registro de IDs de PNRP es solamente una parte del servicio PNRP. La ejecución del servicio PNRP puede ser dividida en cuatro fases. La primera es el descubrimiento de la nube PNRP. Un nuevo nodo debe encontrar un nodo existente en la nube a la que desea unirse. La nube puede ser la nube PNRP global, una nube local de sitio (empresa), o una nube local de enlace. La segunda fase es la unión de una nube PNRP. Una vez que el nuevo nodo ha encontrado un nodo existente, realiza el procedimiento de SINCRONIZACION para obtener una parte del nivel de caché superior de los nodos existentes. Un subgrupo de un nivel de caché individual proporciona suficiente información para que un nuevo nodo inicie su participación en la nube. La tercera fase contempla la participación activa en la nube. Después de que la inicialización se ha completado, el nodo puede participar en el registro y resolución del ID del PNRP. Durante esta fase, el par también realiza el mantenimiento del caché regular. La fase final se refiere a un par dejando la nube. El nodo cancela el registro de cualquier ID del PNRP localmente registrado, entonces termina. El protocolo PNRP de la presente invención, para efectuar las varias funciones de PNRP, comprende diez diferentes tipos de mensajes. A un nivel alto los mensajes incluyen un mensaje de RESOLVER que se utiliza para solicitar la resolución de un ID de PNRP objetivo en una CPA. Un mensaje de RESPUESTA se utiliza como el resultado de una solicitud de RESOLVER completada. Un mensaje de INUNDAR contiene una CPA deseada para el caché PNRP del receptor. Un mensaje de SOLICITAR se utiliza para solicitar a un nodo PNRP PUBLICAR su caché de nivel superior. Un mensaje de PUBLICAR contiene una lista de IDs de PNRP en un caché de nivel superior del nodo. Un mensaje de DEMANDAR se utilizar para solicitar a un nodo que inunde un subgrupo de CPAs PUBLICADOS. Un mensaje de PREGUNTAR se utiliza para preguntar a un nodo si un ID de PNRP específico está registrado en ese nodo. Un mensaje de AUTORIDAD se utiliza para confirmar el registro local de un ID de PNRP, y opcionalmente proporciona una cadena de certificado para ayudar a validar la CPA para ese ID. Un mensaje ACK se utiliza para aprobar la recepción y/o procesar exitosamente ciertos mensajes. Finalmente, un mensaje REPARAR se utiliza para tratar de fusionar nubes que pueden estar divididas.

Un nodo puede iniciar seis tipos básicos de transacciones en PNRP durante las cuales los mensajes de la presente invención se utilizan. Estas transacciones incluyen el descubrimiento, sincronización, resolución, inundación, validación de identidad, y reparación de la nube. Para proporcionar un entendimiento básico de estas transacciones, los detalles de las cuales se explican en las aplicaciones anteriormente identificadas, una breve descripción de estas transacciones como se relacionan con los mensajes y las estructuras de los mensajes de la presente invención. La transacción de descubrimiento de la nube permite a un par descubrir una nube par. En una modalidad preferida, cada nodo puede unirse a algunos números de nubes. El grupo de nubes al que se puede unir depende de la conectividad de la red que tiene el nodo. Si una computadora de nodo tiene múltiples adaptadores de interfase, entonces se puede unir a múltiples nubes del Local del Enlace. Si un nodo es parte de un sitio que soporta IPv6, entonces puede tener acceso a una nube del Local del Sitio. Si un nodo tiene conexiones a más de 1 de dichos sitios (quizás a través de VPN), entonces puede tener acceso a múltiples nubes del Local del Sitio. Si un nodo está conectado al Internet, puede tener acceso a la nube Global. Un nodo puede seleccionar unirse a no unirse a una nube a la que tiene acceso. Cuando una primera aplicación solicita ya sea Registrar un Nombre Par en una nube, o Resolver un Nombre Par en una nube, entonces el nodo debe unirse a la nube si aún no lo ha hecho. Para unirse a la nube debe tratar de localizar por lo menos otro nodo en la misma nube. Si no puede encontrar otro nodo, entonces debe asumir que es el primer nodo en la nube, y esperará que otros nodos se unan más tarde. Cada vez que un nodo PNRP se une a una nube, debe realizar el descubrimiento de la nube para encontrar otro nodo. El descubrimiento de la nube también puede tener lugar después si la implementación del PNRP determina que su caché no es saludable, y necesita obtener más entradas de caché. Si el intento del descubrimiento del Caché inicial no funciona, entonces se pueden hacer intentos adicionales más adelante El descubrimiento de la nube se realiza utilizando los siguientes procedimientos. Primero, un par puede conducir el descubrimiento a partir del caché persistente. En dicho procedimiento, el par primero verifica el caché persistente. Si ningún caché ha sido persistente, entonces el par debe intentar el descubrimiento a través de la dirección de nodo suministrada discutida más adelante. Si las entradas al caché han sido persistentes, para todas las entradas del caché el par calcula una prioridad dando preferencia a las CPAs las cuales aún no han expirado, y después las CPAs que tienen una vida útil más larga, y después las CPAs cuya expiración es más reciente. El par entonces intenta la sincronización con los nodos seleccionados en secuencia hasta que uno de ellos proporciona algunas entradas de caché. Como se indica anteriormente, si no hay un caché persistente, el par trata de realizar el descubrimiento suministrando la dirección del nodo. En este procedimiento el par verifica si la configuración administrativa especifica un grupo de pares a los cuales conectarse. Si no es así, entonces el par trata el descubrimiento de difusión múltiple discutido más adelante. De otra manera, para cada punto final especificado el par intenta la sincronización en secuencia hasta que uno de ellos proporciona algunas entradas de caché. Para el descubrimiento de difusión múltiple, si el Protocolo Del Descubrimiento del Servicio Simple (SSDP) está disponible, el par emite un SSDP de MBUSCAR para una instancia del servicio PNRP en la nube deseada. La cadena del Objetivo de la Búsqueda para utilizarse en el mensaje de Búsqueda SSDP es "urn:Protocolo de Resolución del Nombre Par de Microsoft Windows: <principal>:<Protocolo>:<Alcance> "En donde <principal> es un número que representa la versión, Protocolo es "IPV6"; y Alcance es uno del "Global", "LocalSitio", o "LocalEnlace". La búsqueda debe ser emitida por adelantado para que las respuestas estén disponibles a tiempo. Si el SSDP no está disponible, el par puede tratar estos otros protocolos de descubrimiento. Si no hay ninguno disponible, entonces el par tendrá que intentar el descubrimiento del Servidor del Nombre del Directorio (DNS) descrito más adelante. Sin embargo, si se reciben respuestas, las respuestas se ponen en una lista de nodos que se tratarán. Si no hay ninguna respuesta disponible dentro de un período corto de tiempo, entonces el nodo puede querer intentar otros protocolos de descubrimiento. El período de tiempo puede ser determinado a través de implementación. El par puede intentar la sincronización con los nodos seleccionados en secuencia hasta uno de estos provea algunas entradas al caché. Para el descubrimiento DNS, el par emite una búsqueda DNS para el nombre bien conocido de un servidor de origen. Este nombre para la nube global puede ser, por ejemplo, ORIGEN. PNRP. RED. Si es exitoso, el par puede conducir la sincronización descrita anteriormente. Si la nube descubierta no es exitosa mediante este punto, sin embargo, PNRP estable el estado de la nube como incapaz de descubrir otros miembros de la nube, y asume que es el primer nodo en la nube. Puede intentar más tarde sincronizar otra vez. La sincronización permite a un nodo obtener un grupo de CPAs de otro caché del nodo. La sincronización se realiza después del descubrimiento de la nube. Se realiza con un nodo individual aleatoriamente seleccionado de un grupo de nodos devueltos por el descubrimiento de la nube. La sincronización es segura para mitigar ciertos ataques. La sincronización también puede ser realizada si el caché para una nube se convierte en vacío debido al envejecimiento, pero esto debe de suceder solamente raras veces. Antes de iniciar la Sincronización, el nodo de asegurarse que tiene por lo menos un CPA localmente registrado. Si un Nombre Par aún no ha sido registrado, entonces el nodo puede generar un ID de nodo para sí mismo en la nube. El proceso de sincronización involucra cinco tipos de mensajes de la presente invención, incluyendo SOLICITAR, PUBLICAR, DEMANDAR, INUNDAR y ACK. La Figura 3 ilustra un intercambio de mensaje simple para la sincronización. En esta Figura 3 suponer que el nodo A 212 está iniciando la sincronización con el nodo B 214. En dicha situación el flujo del mensaje entre los nodos aparecerá como se ilustra en la Figura 3. Específicamente, el mensaje SOLICITAR 216 solicita una lista de IDs de PNRP de un nodo 214 que fue seleccionado durante el descubrimiento de la nube. Este mensaje SOLICITAR 216 se presenta como se describe en el Cuadro 1.

CUADRO 1 El nodo mantiene el rastreo del valor de Esta ocasión utilizado para crear el valor de Esta ocasión desglosado. Los cronómetros están asociados con este estado, así como un contador de reintentos. Si un mensaje PUBLICAR 218 no se recibe en respuesta a SOLICITAR 216 enviado, el SOLICITAR 216 será reenviado. Si el contador de reintentos es excedido, entonces el estado se libera y la transacción es terminada. El nodo 214 que recibe un SOLICITAR 216 responde con un mensaje PUBLICAR 218. PUBLICAR 218 contiene un arreglo de IDs de PNRP. El nodo 214 primero aplica guías heurísticas de admisión para determinar si está deseando involucrarse en una transacción de sincronización. Si está ocupada, responde con un mensaje PUBLICAR 218 sin IDs de PNRP en el arreglo. Por el otro lado selecciona un grupo bien distribuido de IDs de PNRP de su caché. Esto puede ser hecho utilizando las entradas de caché de nivel superior o a través de selección aleatoria. Si no hay entradas suficientes en el caché, el nodo 214 debería incluir sus propios IDs localmente registrados también. El mensaje PUBLICAR 218 incluye el Valor de Esta Ocasión Desglosado del mensaje SOLICITAR 216. PUBLICAR 218 se considera como siendo una aprobación para SOLICITAR 216. Si el arreglo de los IDs de PNRP no estaba vacío, el nodo 214 también controla el estado que un PUBLICAR 218 con el valor de Esta Ocasión desglosado fue enviado. Este estado puede ser un bit en un mapa de bits. Un cronómetro está asociado con este estado, por lo que si un mensaje de comparación no es recibido dentro de, por ejemplo 15 segundo, la transacción se aborta y el estado se libera. El nodo 214 también puede agregar el CPA de origen del mensaje SOLICITAR 216 a su caché. El mensaje PUBLICAR 218 se presenta como se indica en el Cuadro 2.

CUADRO 2 Cuando un nodo 212 recibe PULBICAR 218, primero se asegura que ha enviado un SOLICITAR 216 correspondiente. Si no es así, da de baja el mensaje. PUBLICAR 218 se trata como una aprobación para SOLICITAR 216. Si el arreglo de las IDs de PNRP en PUBLICAR 218 está vacío, la transacción se completa. De otro modo el nodo 212 va a través del arreglo de los IDs de PNRP en PUBLICAR 218 y selecciona los que quiera incluir en su caché. Envía un mensaje DEMANDAR 220, incluyendo un arreglo de los IDs de PNRP seleccionados. En el mensaje DEMANDAR 220 colocar el valor de Esta ocasión original utilizado para crear el valor de Esta Ocasión desglosado del mensaje SOLICITAR 216. El mensaje DEMANDAR 220 es presentado como se indica en el Cuadro 3.

CUADRO 3 El mensaje DEMANDAR 220 se envía al nodo B 214, el cual responde con un ACK 222 para indicar la recepción y evitar la retransmisión. Si un ACK 222 no es recibido en una forma a tiempo, el nodo 212 retransmitirá DEMANDAR. Si todas las retransmisiones son exhaustadas sin recibir un ACK de DEMANDAR, la transacción falla y se termina. Si la transacción es exitosa, es decir el nodo 212 recibe ACK 222 del nodo 214, el nodo 214 entonces verifica que el valor de Esta Ocasión sea válido. Hace esto desglosando el valor de Esta ocasión recibido y verificando si coincide con el estado guardado anteriormente. Si no coincide, no se lleva cabo ningún procesamiento adicional. Si es válido, entonces para cada ID de PNRP en el arreglo que aún tiene en su caché, envía un mensaje INUNDAR 224^ 2242, ...224N. El mensaje INUNDAR 224 incluye el CPA para el ID de PNRP. Se debe observar que los mensajes INUNDAR 224 no son sincrónicos. Es decir, INUNDAR(ID = 1 ) 224^ no necesita ser aprobado antes de que INUNDAR(ID = 2)224 sea enviado. Una vez la recepción de INUNDAR 224 mediante el par 212, el procesamiento normal del mensaje INUNDAR 224 toma lugar. Esto incluye enviar un ACK 226 y verificar la validez de CPA. El nodo solicitante 212 puede decidir repetir este procedimiento si el número de IDs seleccionados no es lo suficientemente grande. En este caso debería utilizar un nodo diferente con el cual sincronizar por lo que obtendrá una lista diferente de IDs. El proceso de Resolución se inicia a través de un nodo enviando un mensaje RESOLVER. Un RESOLVER puede ser iniciado debido a que una aplicación está solicitando resolver un nombre Par para una dirección, como parte del Registro de un ID de PNRP, como parte del mantenimiento del caché, o para detectar divisiones de la nube. Un mensaje RESOLVER contiene algunas banderas y códigos para sintonizar el procesamiento de resolver, para establecer un límite sobre cuántos nodos visitar en un intento de resolver, y para guiar la exactitud de la comparación de ID. Especifica el ID de PNRP objetivo deseado. En cada punto de conexión el ID del siguiente punto de conexión se inserta, así como la mejor coincidencia CPA se encuentra. Además, un arreglo de puntos finales de nodo visitados se incluye para rastrear la trayectoria del mensaje RESOLVER de punto de conexión a punto de conexión. El originador de RESOLVER se agrega a sí mismo como la primera entrada en la trayectoria. La transacción de resolución resuelve un ID de PNRP en una Dirección Par Certificada. Los CPAs guardados en memoria caché solamente pueden ser utilizados como sugerencias para el direccionamiento de las solicitudes RESOLVER. No pueden ser utilizadas para establecer el campo de "mejor coincidencia" de RESOLVER o RESPUESTA. Un mensaje RESOLVER se termina cuando el nodo que hospeda el ID del PNRP objetivo es logrado, o cuando el número de nodos visitados iguala los Puntos de Conexión Máximos establecidos en RESOLVER, o cuando ya no es posible para ningún nodo en la trayectoria enviar RESOLVER a un mejor nodo. Una vez la terminación, los contenidos seleccionados de RESOLVER son transferidos en un nuevo mensaje de RESPUESTA, el cual es enviado de regreso hacia el iniciador RESOLVER. RESPUESTA contiene el CPA "de mejor coincidencia" de RESOLVER, así como la lista de los nodos visitados. Una vez que RESPUESTA alcanza al originador RESOLVER, el originador puede fácilmente verificar en donde encontraron el CPA objetivo mediante la comparación de los IDs de PNRP de los CPAs de "mejor coincidencia" con el objetivo. Un ejemplo de tres nodos de una transacción RESOLVER/RESPUESTA se ilustra en la Figura 4. En este ejemplo simplificado, el nodo A 228 está intentando resolver para el nodo T 232 a través del nodo B 230. Existen tres mensajes involucrados en la transacción de Resolver aparte de ACK, para discernir RESOLVER, RESPUESTA, y AUTORIDAD. Una vez que la resolución está completa, el nodo A 228 envía al nodo T 232 un mensaje de INDAGAR directamente como se discutirá más adelante. Para los mensajes RESOLVER, existen tres casos a considerar, los primeros dos de los cuales se ilustran en la Figura 4. Los tres casos inician RESOLVER 234 en el nodo A 228, enviando un RESOLVER 236 desde el nodo A 228 a otro nodo B 230, y teniendo un RESOLVER enviado otra vez de un nodo (no mostrado en la Figura 4). Cada uno de estos escenarios se discuten también. El iniciar RESOLVER en el nodo A 228 se discute primero. Como se ilustra en la Figura 4, el nodo A 228 inicia RESOLVER por alguna razón. Estas razones incluyen una solicitud de resolver la aplicación, registro de publicación, mantenimiento del respiro del caché, o detección de división de la nube. El iniciado 228 también especifica un código de operación, indicando si RESOLVER puede ser satisfecho a través de un ID localmente registrado. Si puede ser así, entonces el nodo A 228 escanea el grupo de IDs localmente registrados para una comparación. Si se encuentra uno, RESOLVER se completa dentro del nodo A 228 mismo con el ID coincidente. Si un ID localmente registrado no es aceptable, o si ninguno de los IDs locales son una coincidencia, entonces un mensaje RESOLVER 234 es creado con los campos mostrados en el Cuadro 4. Este mensaje RESOLVER 234 entonces es enviado a algún otro nodo 230 para el procesamiento como se describe a continuación.

CUADRO 4 Cuando el nodo A 228 quiere o necesita enviar RESOLVER 234 a otro nodo B 230, este siguiente nodo debe primero se seleccionado. Para seleccionar el siguiente punto de conexión, el nodo A 228 hace una lista L de los tres CPAs guardados en memoria caché con los IDs de PNRP que están más cercanos al ID Objetivo (nodo T 232), excluyendo cualquiera cuya dirección ya está listada en la Trayectoria, y aquellas que no están cerca del ID Objetivo que el ID localmente registrado de la más cercana. Si el ID Objetivo está en la lista L, esa entrada se selecciona como el siguiente punto de conexión. Por el contrario, si la lista L no está vacia, entonces se selecciona una entrada de forma aleatoria. En otras palabras, el nodo A 228 encuentra algunos nuevos nodos que están más cercanos al objetivo que este nodo, y selecciona uno de ellos al cual enviar el mensaje RESOLVER 234. Si el nodo A 228 es capaz de seleccionar un siguiente punto de conexión, entonces el nodo A 228 inserta una entrada apropiada en el "mapa de bits recibido". El nodo A 228 se agrega a sí mismo a la Trayectoria, seleccionando su mejor dirección para el siguiente punto de conexión seleccionado, y marcando la entrada como Aceptada. El nodo A 228 establece el SiguientePuntoDeConexión para el Id de PNRP esperado del destino seleccionado, y envía el mensaje RESOLVER 234 al nodo B 230. Si el mensaje RESOLVER 234 es exitosamente enviado, entonces el nodo remitente 228 espera recibir una aprobación en la forma de un mensaje AUTORIDAD 238. Si AUTORIDAD 238 es recibida, entonces el nodo 228 mantiene un contexto para RESOLVER 234 y espera hasta un valor de tiempo fuera para que un mensaje de RESPUESTA 240 sea devuelto. Si AUTORIDAD 238 no es recibido después de algún tiempo, RESOLVER 234 se envía otra vez. Un total de N entradas ocurrirá antes de que se asuma que el SiguientePuntoDeConexión es inválido. En una modalidad preferida, N = 3. Si el conteo de reintentos es excedido, entonces el CPA de SiguientePuntoDeConexión es removido del caché local, y la entrada se agrega a la Trayectoria como un punto de conexión fallido. Si el conteo de puntos de conexión no se excede, entonces otro SiguientePuntoDeConexión se selecciona del caché local, y el proceso se repite. Si el número de entradas en la Trayectoria es igual o excede los PuntosDeConexiónMáximos, entonces un mensaje RESPUESTA es generado con un código de Respuesta de RESULTADO_MAX_PUNTOCONEXION_LIMIT_HIT, y se envía a la entrada más reciente en la Trayectoria que fue marcada como Aceptada. Si el nodo no fue capaz de encontrar el siguiente punto de conexión, verifica si el ID objetivo pudiera estar en el nivel del caché más bajo. Si pudiera estar, entonces el nodo sospecha que el ID Objetivo no existe. El nodo verifica las entradas de la Trayectoria existente y cuneta las que están marcadas como Sospechosas. Si este conteo excede un umbral, entonces un mensaje RESPONDER se genera con un código de Responder de RESULTADO_MUCHOS_ERRORES, y se envía a la entrada más reciente en la Trayectoria que fue marcada como Aceptada. Si el nodo no fue capaz de encontrar un siguiente punto de conexión, pero el conteo Sospechoso no es excedido, el nodo envía RESOLVER otra vez al último nodo en la Trayectoria que está marcado como Aceptado. El nodo primero se agrega a sí mismo en la Trayectoria, seleccionando su mejor dirección para el nodo de destino, y marcando la entrada Rechazada. Establece el SiguientePuntoDeConexión a 0, y establece la bandera R F_l G O RAR_S IG U IENTEPUNTOCONEXION para indicar un retroceso. Si el ID Objetivo debería estar en el nivel más bajo del caché del nodo, entonces se sospecha que el ID Objetivo no existe. En este caso el nodo también marca su entrada de Trayectoria como Sospechosa. Si el nodo no fue capaz de encontrar el siguiente punto de conexión, y ya no hay nodos en la Trayectoria (además del él). Entonces es el originador del mensaje RESOLVER. En este caso regresa un resultado al que llama, indicando una falla en resolver, con el Código de Respuesta de RESULT_NO_ME JO R_TRAYECTORIA_EN CONTRA DA. La CPA MejorCoincidencia se hace disponible al que llama. El nodo B 230 recibe un mensaje RESOLVER 234 que contiene un ID de PNRP objetivo, un CPA de MejorCoincidencia, un ID de PNRP de Siguiente Punto de Conexión, y una Trayectoria que lista las direcciones de todos los nodos que han procesado RESOLVER. Si el campo de banderas no tiene RF_IGNORAR_SIGUIENTEPUNTOCONEXION establecido y el CPA de MejorCoincidencia puede tener un CPA o puede estar vacío, el nodo B 230 verifica su carga de procesamiento local. Si la carga es muy grande para procesar nuevas solicitudes RESOLVER, responde con un AUTORIDAD 238 con el campo de bandera fijado en " AF_RECH AZAR_DEMASI ADO_OCUPADO" y el procesamiento está completo. El receptor de AUTORIDAD es responsable de agregar el punto final del nodo que rechaza al arreglo de la trayectoria y redirecciona la solicitud RESOLVER a cualquier otro lugar. El nodo receptor 230 verifica que el arreglo de la Trayectoria contenga por lo menos 1 dirección marcada como Aceptada, y que la última de dichas direcciones sea la misma que la fuente del mensaje. Si no es así, no se hace ningún procesamiento adicional. El nodo receptor también verifica los parámetros en la solicitud recibida. Si algunos parámetros no están en un rango válido, entonces responde un mensaje AUTORIDAD con el campo de banderas fijado en "AF_SOLICITUD_INVALIDA", y el procesamiento se completa. Un ejemplo de un parámetro inválido es si el MáxPuntosConexión es demasiado grande. El receptor de AUTORIDAD es responsable de agregar el punto final del nodo que rechaza a la ensayo de la trayectoria y redirecciona la solicitud RESOLVER a cualquier otro lugar. El nodo receptor (nodo B 230 por ejemplo) verifica si el ID de SiguientePuntoConexión está localmente registrado. Un servidor de origen puede brincarse esta prueba. Si esto falla, responde con AUTORIDAD con el campo de banderas fijado en "AF_ID_DESCONOCIDO", y el procesamiento está completo. El receptor de AUTORIDAD es responsable de direccional la solicitud RESOLVER a cualquier otro lugar. El receptor de AUTORIDAD también debe remover el ID del PNRP del remitente de AUTORIDAD de su caché cuando se recibe AF_ID_DESCONOCI DO. Si CPA de MejorCoincidencia está incluido en el mensaje, el nodo valida la MejorCoincidencia, siempre que esté disponible Si CPA no es válida, el nodo remueve CPA de MejorCoincidencia del mensaje. Si CPA de MejorCoincidencia es válida, entonces el nodo sigue las reglas usuales para decidir si agregar el CPA a su caché. El nodo también verifica si ya hay una entrada para él en la Trayectoria. Si hay una, entonces existe un bucle ya que no es un RESOLVER de retroceso. El nodo entonces responde con un AUTORIADA con el campo de las banderas establecido a " AF_RECH AZAR_BUCLE", y el procesamiento está completo. El receptor de AUTORIDAD es responsable de agregar el punto final de nodo rechazado a la Trayectoria y de redireccionar la solicitud RESOLVER a cualquier otro lugar. Si todas las verificaciones previas son aprobadas, el nodo B 230 envía un AUTORIDAD 238 para aprobar el mensaje RESOLVER 234. Si la bandera RESOLVER RF_ENVIAR_CADENA fue establecida, entonces la cadena del certificado para el SiguientePuntoConexion se incluye en AUTORIDAD 238. La porción de la cadena Clasificadora del Nombre Par correspondiente al siguiente ID de PNRP del punto de conexión está incluido en el mensaje AUTORIDAD. El nodo B 230 verifica si tiene un CPA localmente registrado que es una mejor coincidencia que la MejorCoincidencia actual. Si es así, reemplaza la MejorCoincidencia con ésta. El nodo también verifica si tiene una CPA localmente registrada que satisface el criterio RESOLVER, en base en el CódigoOp, Precisión e IDObjetivo. Si tiene una coincidencia, o si el número de entradas en la trayectoria es > = MáxPuntosConexión , entonces el nodo crea un mensaje de RESPUESTA con la MejorCoincidencia actual. La trayectoria del mensaje RESOLVER se copia en la trayectoria del mensaje RESPUESTA. El nodo establece el Cód igoRespuesta para indicar ya sea el resultado RESLTADO_ENCONTRADO_CO INCIDENTE o RESULTADO_MAX_PUNTOCONEXION_LIMITE_HIT. El nodo entonces remueve sus direcciones de la trayectoria así como las subsiguientes entradas marcadas como Rechazadas, y envía la RESPUESTA a la entrada más reciente en la trayectoria que está marcada como Aceptada. Si el nodo B 230 no envía una RESPUESTA (como se ilustra en la Figura 4), entonces trata de enviar un mensaje RESOLVER 236 al siguiente nodo T 232. Este envío sigue el procedimiento descrito anteriormente. Es decir, el nodo T 232 responde inicialmente con un mensaje AUTORIDAD 242. Después realiza las verificaciones discutidas anteriormente y, determina que coincide con el Objetivo, responde al nodo B 230 con un mensaje de RESPUESTA 244 identificándose el mismo como la MejorCoincidencia. En respuesta al mensaje RESPUESTA 224, en nodo b 230 envía de regreso un mensaje ACK 246. El nodo B 230 entonces verifica la trayectoria y envía el mensaje RESPUESTA 240 al nodo A 228, el cual responde con un mensaje ACK 248. Como se indicó anteriormente, un nodo también puede tener que manejar un RESOLVER de retroceso. Cunado un nodo recibe un mensaje RESOLVER R contiene un ID de PNRP de ID Objetivo, un CPA MejorCoincidencia, un ID de PNRP SiguientePuntoConexión, y una Trayectoria listando las direcciones de todos los nodos que han procesado RESOLVER. Para RESOLVER de retroceso el campo de banderas tiene RF_IGNORAR_SIGUIENTEPUNTOCONEXION fijado.

El nodo primero verifica su "mapa de bits recibido" para verificar que ha enviado previamente este RESOLVER. Si en bit no está establecido, el mensaje se da de baja. El nodo entonces verifica la Trayectoria para asegurar que sus direcciones están en la Trayectoria y que es la entrada más superior que está marcada como Aceptada en la Trayectoria. En el caso contrario el mensaje es dado de baja. Si el mensaje no es dado de baja, en nodo envía AUTORIDAD de regreso al remitente para ACK el mensaje. Esto no incluye una cadena de certificado. Si el número de entradas en la Trayectoria > = MáxPuntosConexión, entonces el nodo crea un mensaje RESPUESTA S con la MejorCoincidencia actual. La trayectoria del mensaje R RESOLVER se copia a la Trayectoria S. El nodo establece el Código de Respuesta para indicar que MáxPuntosConexión se han excedido. El nodo entonces remueve sus direcciones de la Trayectoria y envía RESPUESTA otra vez a la entrada más reciente en la Trayectoria que está marcada como Aceptada. Si el nodo no envía una RESPUESTA, entonces trata de enviar RESOLVER al siguiente punto de conexión. Esto sigue el procedimiento descrito anteriormente con algunas excepciones: a) "El nodo B 230 verifica si tiene un CPA localmente registrado que es la mejor coincidencia que la MejorCoincidencia actual. Si es así reemplaza la MejorCoincidencia con ésta". NO APLICA; y b) si el nodo actual es el originador de la transacción RESOLVER Y la razón es RAZON REPARAR DETECCION, el procesamiento está completo.

Como se discutió brevemente anteriormente, cuando un nodo recibe un mensaje RESPUESTA 244, 240 contiene un IDObjetivo del ID de PNRP, una CPA de MejorCoincidencia, y una trayectoria listando las direcciones de todos los nodos que han procesado RESOLVER. El nodo receptor también verifica su "mapa de bits" recibido para verificar que ha enviado previamente un RESOLVER 234, 236 que coincide con esta RESPUESTA 240, 244. Si el bit no esta establecido, el mensaje es dado de baja. El nodo receptor también verifica la Trayectoria para asegurar que su dirección es la última (más actüal) en la Trayectoria, y que está marcada como Aceptada. De lo contrario el mensaje es dado de baja. Si el mensaje no es dado de baja, este nodo receptor envía un ACK 246, 248 para el receptor aprobado. El nodo valida el CPA de MejorCoincidencia mientras está disponible, ya lo agrega a su caché. Al agregar un CPA a un caché se somete a un grupo de reglas que pueden requerir que se intercambien mensajes adicionales, por lo que P puede validar la CPA de MejorCoincidencia. Esto se describe en las aplicaciones identificadas anteriormente. Entonces el nodo se remueve a sí mismo de la Trayectoria. El nodo también remueve las entradas previas que están marcadas como Rechazada, hasta que encuentra une entrada marcada Aceptada o la lista es vaciada. Si se encuentra una entrada marcada como Aceptada, entonces el nodo envía la RESPUESTA a este nodo. Si el nodo que tiene la RESPUESTA enviada no responde con un ACK, el nodo retransmite la RESPUESTA hasta N veces. Si el tiempo de retransmisión se agota, entonces el nodo remueve el nodo de destino fallido de la trayectoria, y reintenta el procesamiento de RESPUESTA discutido en este párrafo. Si ya no hay más entradas en la Trayectoria, entonces el nodo es el originador de RESOLVER 234 original. El nodo 228 valida que el originó la solicitud. Si no lo hace, la RESPUESTA es dada de baja. Si el Código de Respuesta indica exitoso, el nodo 228 entonces hace una validación de identidad en la fuente del CPA de MejorOpción. Esto involucra el envío de un mensaje de AVERIGUAR 250 al nodo objetivo 232, y verifica el mensaje de AUTORIDAD devuelto 252. Si la validación de la identidad falla, cambia el código de respuesta a IDENTIDAD_FALLA. Devuelve el resultado de regreso al que llama. Un mensaje AUTORIDAD puede ser fragmentado por el remitente. Depende del receptor asegurar que ha recibido todos los fragmentos antes de procesar el mensaje AUTORIDAD. Si cualquier fragmento no es recibido dentro de una cantidad razonable de tiempo, entonces el mensaje origina (AVERIGUAR o RESOLVER) debe ser reenviado, a menos que el conteo de reintentos sea excedido. Si las banderas del mensaje AUTORIDAD tienen establecido AF_CERT_CADENA, el nodo debe realizar una operación de validación de cadena en el CPA guardado en la memoria caché para el ID del PNRP especificado en el IDValidado. La cadena debe ser verificada para asegurar que todos los certificados en ella son válidos, y la relación entre la raíz y la hoja de la cadena es válida. El desglose de la clave pública para la raíz de la cadena debe se deberá comparar contra la clave utilizada para firmar la CPA para asegurar que coinciden. Finalmente, el ID de P2P deberá verificarse par ver que es el desglose de la Autoridad y Clasificador de acuerdo con las reglas para crear el ID P2P. Si cualquiera de las verificaciones anteriores falla, el CPA deberá ser removido del caché, y le mensaje RESOLVER deberá ser modificado agregando la dirección del nodo que envió el mensaje AUTORIDAD a la Trayectoria del mensaje RESOLVER y haciendo la entrada Rechazada. Si se establece AF_DESCONOCIDO_ID, CPA deberá ser removido del caché. Si AF_CERT_CADENA no se estableció, pero el CPA correspondiente al IDValidado del ID de PNRP requiere una cadena de certificación para validar, el CPA deberá ser removido del caché, y el mensaje RESOLVER deberá ser modificado agregando la dirección del nodo que envió el mensaje AUTORIDAD para la Trayectoria del mensaje RESOLVER y marcar la entrada Rechazada.

Cuando el CPA correspondiente al IDValidado del ID del PNRP ha sido validado, deberá ser marcado como completamente validado. La cadena del Clasificador se extrae del mensaje de AUTORIDAD y mantiene el CPA. Si un AF_RECHAZAR_DEMAS I ADO_OCUPADO, AF_DESCONOCIDO_ID, AF_RECHAZAR_BUCLE y AF_SOLICITUD_INVALIDA todas son aclaradas, RESOLVER ha sido aceptado para el procesamiento, y el procesamiento AUTORIDAD está hecho. En algunos casos un nodo que recibe un mensaje RESOLVER puede seleccionar no aceptarlo para enviarlo, pero aún proveer una sugerencia de SiguientePuntoConexión al nodo que lo envía. En este caso el nodo regresa un punto final de Referencia e ID el PNRD de. Referencia en el mensaje AUTORIDAD. En este caso el valor de las Banderas AUTORIDAD deberá contener AF_RE D I R IG I R. El nodo que recibe una AUTORIDAD con AF_REDIRIGIR puede seleccionar si no utilizar el Punto Final de Referencia para enviar el mensaje RESOLVER. En cualquier caso el nodo que respondió con AUTORIDAD es agregado a la Trayectoria. La única vez que un nodo deberá utilizar el Punto Final de Referencia es en el caso en donde el nodo que origina RESOLVER lo hizo para detectar una división de la nube, y ha enviado un RESOLVER a un Servidor de Origen PNRP con una Razón de RAZON_REPARAR. En otros casos en nodo deberá ignorar el Punto Final de Referencia. PNRP utiliza inundación dirigida para propagar las entradas CPA en el caché entre los nodos. La inundación se utiliza en varios casos. Durante el proceso de sincronización en respuesta a un mensaje de DEMANDA, los CPAs solicitados son inundados al par que envió la DEMANDA. El mensaje DEMANDA es solamente aceptado después de que un mensaje SOLICITAR ha sido aceptado y un mensaje PUBLICAR ha sido enviado. Siempre que un CPA se agregue al nivel más bajo del caché, el CPA agregado es inundado a los pares n más cercanos al ID localmente registrado. El valor de n puede se sintonizado, y un valor de 4 es preferido. Si la razón para agregar un CPA es debido a la recepción de INUNDAR, entonces CPA no deberá inundar los nodos cuyas direcciones están el a Lista de Inundar de la INUNDAR recibida. Las direcciones en la Lista Inundar deberán ser copiadas a la nueva lista Inundada del mensaje INUNDAR si hay suficiente espacio. En cualquier momento que una revocación de CPA suceda, la CPA revocada es inundada en los pares n más cercanos al ID localmente registrado. Otra vez, el valor de n puede ser sintonizado, pero un valor de 4 es preferido. CPA debe inundar los nodos cuyas direcciones están el la Lista de Inundado de INUNDAR recibido. Las direcciones en la Lista de Inundado recibida deberán ser copiadas en la nueva Lista de Inundado del mensaje INUNDAR si hay suficiente espacio. Finalmente, cuando un INUNDAR es recibido para un nuevo Par, y CPA se agrega al nivel más bajo del caché, un mensaje INUNDAR entonces es enviado al nuevo Par con el ID del nodo local. Se hace una excepción si la fuente de INUNDAR es el nuevo Par. PNRP no crea relaciones de vecinos persistentes. En el sentido más suelto, cada nodo representado por CPA en el caché CPA puede ser considerado un vecino. Sin embargo, los CPAs se agregan y remueven desde el caché sin necesariamente notificar al emisor de CPA. Al tener un CPA del par en un caché del nodo no asegura que el vecino que tiene el CPA del nodo esté en su caché. La relación es asimétrica. Sin embargo, la condición INUNDAR final descrita anteriormente trata de crear la simetría para los IDs que están más cerca uno del otro. Cada mensaje INUNDAR UDP es aprobado por un ACK antes de que se tome cualquier otra acción, Si se recibe el ACK, el estado es liberado. Si un ACK no es recibido durante un período de tiempo, INUNDAR se reenvía y el cronómetro se reinicia. INUNDAR se reintenta hasta un número dado de veces, preferiblemente 3. Si un ACK no se recibe después del último intento, entonces el estado es liberado. Además, si el destino de INUNDAR fue en el caché del remitente, entonces la entrada al caché es removida para evitar tratar de enviar mensajes a un nodo no responsivo en el futuro. Cuando un nodo recibe un mensaje INUNDAR, se procesa a través de la primera aprobación del mensaje INUNDAR enviando un ACK. El campo de banderas se fija en "KF_ ACK" si el IDValidado está presente y no está localmente registrado. Enseguida, el mensaje INUNDAR es validado. Esto incluye hacer una verificación local de la firma CPA y el contenido. Si el CPA es validado, entonces se determina si el CPA será agregado al caché. Si el CPA es para un ID de PNRP que está localmente registrado en el mismo nodo, entonces no hay necesidad de agregarlo al caché. Si la identidad utilizada para firmar el CPA no puede ser verificada por el CPA solo, y el CPA será agregado a uno de los niveles más bajos de la vista del caché, entonces la validación de la identidad necesita ser realizada como se discutirá más adelante. Si la validación falla, el nodo da de baja el mensaje INUNDAR. Sí es exitosa, el nodo continúa procesando INUNDAR. Si CPA ya ha vencido entonces el nodo da de baja a INUNDAR. Si CPA es un CPA de revocación, entonces el nodo remueve el CPA correspondiente del caché si hay alguno. Si se encontró uno, el nodo envía la revocación a otros vecinos enviando mensajes INUNDAR. Si CPA no es una CPA de revocación, entonces el nodo actualiza el caché. Si un CPA coincidente ya está en el caché, el nodo actualiza la entrada del caché con los nuevos datos de CPA. Si esto es una nueva entrada, entonces el nodo crea una nueva entrada y trata de agregarla al caché. La entrada no puede ser agregada si otra entrada necesita ser removida para hacer espacio para esto, pero las entradas existentes son preferidas que las nuevas entradas debido a sus niveles de confianza más altos o mejores medidas de proximidad. Si la entrada pertenece al nivel del caché más bajo, entonces debería ser agregado. Si CPA pertenece al nivel más bajo del caché, entonces debería ser enviada a algunos vecinos, aún si falla al ser agregada al caché. Si INUNDAR fue recibida durante la sincronización, entonces el envío de los mensajes INUNDAR necesitan ser enviados, después un grupo de IDs de PNRP n que están más cerca del ID localmente registrado se seleccionan. Un mensaje INUNDAR se envía a cada uno de estos con el nuevo CPA, y una Lista de Inundados que incluye los n vecinos, más el contenido de la Lista de Inundados recibida en el mensaje INUNDAR que fue recibido. La validación de la identidad es un dispositivo de mitigación de amenazas utilizado para validar CPAs. Tiene dos propósitos. Primero, la validación de la identidad asegura que el nodo PNRP especificado en una CPA tiene la ID del PRNP de ese CPA registrado localmente. Segundo, para asegurar los IDs de PNRP, la validación de identidad asegura que el CPA fue firmado utilizando una clave con una relación probable criptográficamente a la autoridad en el ID de PNRP. Los detalles de cómo la validación de la identidad logró estos dos objetivos se encuentra en las aplicaciones pendientes identificadas anteriormente. Una verificación de validación de identidad sucede en dos diferentes momentos. Primero, una validación de identidad ocurre cuando se agrega un CPA al nivel más bajo de los dos niveles del caché. La validación de CPA en el más bajo de los dos niveles del caché es crítica para la habilidad de PNRP para resolver los IDs de PNRP. Al llevar a cabo la validación de identidad antes de agregar una CPA a cualquiera de estos dos niveles mitiga varios ataques. En este caso CPA será capaz de ser controlada en una lista durante hasta por ejemplo, 30 segundos, esperando por el mensaje de AUTORIDAD. Segundo, la validación de identidad ocurre oportunamente durante RESOLVER. Las memorias caché de PNRP tiene una alta tasa de rendimiento. Consecuentemente, la mayor parte de las entradas al caché se sobrescriben en el caché antes de que se hayan utilizado. PNRP no valida la mayoría de los CPAs hasta que actualmente se utilizan. Cuando un CPA se utiliza para dirigir una trayectoria RESOLVER, la validación de identidad se aprovecha en la parte superior del mensaje RESOLVER. RESOLVER contiene un ID del "siguiente punto de conexión" el cual se trata de la misma forma que el "ID Objetivo" en un mensaje de INVESTIGAR.

RESOLVER es aprobado con un mensaje de AUTORIDAD, de la misma forma que se espera de un INVESTIGAR. Si una validación de identidad de oportunidad falla, el receptor de RESOLVER no es el que el remitente piensa que es. Consecuentemente, RESOLVER se dirige a cualquier lugar y el CPA inválido es removido del caché. Para ilustrar esta validación, asumir que P es un nodo solicitando una validación de identidad para el ID 'T' de PNRP. N es el nodo que recibe la solicitud de validación de identidad. P genera ya sea un mensaje de INVESTIGAR con un ID Objetivo^ T, o un mensaje RESOLVER con el siguiente punto de conexión = T (y RF_IGNORAR_SIGU IENTEPUNTOCO EXION no está establecido). N verifica su lista de IDs de PNRP localmente registrados. Si T no está en la lista N, responde con un mensaje AUTORIDAD indicando que el ID T no está localmente registrado. Si el mensaje recibido fue un RESOLVER, RESOLVER es descartado, según P se encargará de enviarlo a cualquier lugar. Cuando T está en la lista de IDs de PNRP en N, N construye un mensaje AUTORIDAD y establece el ID objetivo para T. Si la bandera RF_ENVIAR_CADENA se estableció, N recupera la cadena del certificado (si hay alguna) relacionada con la clave utilizada para firmar la CPA a la autoridad para el ID de PNRP T. La cadena de certificado se inserta en el mensaje AUTORIDAD. La parte Clasificadora del Nombre Par también se agrega en el mensaje AUTORIDAD. N envía el mensaje AUTORIDAD a P. Si el mensaje AUTORIDAD es más grande de 1216 bits, entonces el mensaje se divide en múltiples fragmentos de 1216 bytes o menos, y cada fragmento se envía. Si T es un ID inseguro, o si CPA ya fue validado (RESOLVER enviado con RF_EN VIAR CADENA aclarado), entonces el procesamiento está completo. P valida la relación entre la clave de firma de CPA y la autoridad utilizada para generar el ID de PNRP T. Si la validación falla, el CPA es descartado. Si la validación falla y el mensaje de iniciación fue RESOLVER, P envía RESOLVER a cualquier otro lado. Como se explicó en las aplicaciones identificadas anteriormente y como se discutió brevemente anteriormente, es posible que las nubes PNRP puedan se divididas. Esto puede suceder en dos formas. Primera, las nubes deben haber empezado independientemente y necesitan ser fusionadas. Segunda, las nubes pueden haber empezado como una, pero algún fragmento de la nube de volvió aislado del resto de la nube. El puentear cualesquiera posibles divisiones, se asume que las nubes tendrán servidores de origen designados. Estos son los mismos servidores para autoconfigurarse a través del DNS. Si hay múltiples servidores de origen en una nube, entonces los servidores de origen deben comunicarse uno con el otro periódicamente para asegurarse de que intercambian IDs en sus memorias caché. Esto se puede hacer utilizando el proceso de Sincronización. Esto evitará la creación de islas. Los nodos en una nube periódicamente censarán los servidores de origen para probar si el nodo se ha convertido en aislado de la nube principal, e intentarán fusionarlo de nuevo si es necesario. La frecuencia a la cual un nodo hará la prueba para una división es inversamente proporcional a su estimado del tamaño de la nube. Esto es para controlar que las pruebas se dividan demasiado frecuentemente. Un nodo que recientemente se ha unido a una nube deberá esperar durante un período de tiempo para que su caché se haya populado antes de asumir que es capaz de estimar el tamaño de la nube. Para habilitar la fusión de las nubes, el mensaje REPARAR PNRP se utiliza. REPARAR tiene un ID de PNRP, la dirección IP de un nodo y un número de Nivel de Reparación. Los niveles del caché están numerados con 0 siendo el nivel superior (rango de número más amplio) y cada nivel subsiguiente (rango más pequeño) siendo 1 más alto. Cunado una división es primero detectada, se inicializa un valor de Nivel de Reparación de 0. Cuando un nodo decide que debería realizar una prueba para un código de división, el nodo internamente generará REPARAR, utilizando la dirección del Servidor de Origen conocido como la dirección IP, un ID de PNRP que está localmente registrado, y un nivel de 0. Procesa esta REPARAR el mismo. Cuando un REPARAR es procesado, el nodo hace una prueba para una división. Primero encuentra un ID localmente registrado que está más cerca de ID en el mensaje REPARAR. Entonces lo envía a RESOLVER para este ID + a la dirección IP especificada en el mensaje REPARAR. Este RESOLVER deberá tener un Código de Razón de Reparación. Si esto resuelve a un nodo conocido, entonces no hay una división. Si esto se resuelve a un nuevo nodo, entonces se sospecha de una división. Si el nuevo nodo descubierto falla en el nivel más bajo del caché (número más alto), entonces se realiza la inundación como siempre. Un Código de Razón de Reparación se establece en el mensaje INUNDAR. También, si el nodo receptor de RESOLVER pone el ID de la fuente en su nivel más bajo del caché, entonces ese nodo inundará entradas en la fuente. Toda esta inundación dará como resultado un intercambio de varios IDs con la nueva nube. A todos los nuevos nodos descubiertos a través de la inundación se les controla el rastreo en esta forma. Si un nuevo nodo descubierto está más cerca que los nodos previamente conocidos, y hay entradas de caché en el Nivel de Reparación recibidas, entonces el nodo envía el mensaje REPARAR a las entradas en el caché en el Nivel de Reparación. Para cada REPARAR enviado, el nodo selecciona uno de los ID de nodo recién descubiertos y dirección IP, y los pasa al Nivel de Reparación + 1. Si el nuevo nodo descubierto es adicional a los nodos previamente conocidos, entonces el nodo envía REPARAR al nuevo nodo, pasando algunos ID y direcciones del caché local, y el Nivel de Reparación recibido. Cada nodo que recibe un mensaje REPARAR lo procesa en la misma forma. Como ahora será aparente, el protocolo PNRP consiste de diez tipos de mensajes. Cada mensaje empieza con un encabezado PNRP, seguido por campos específicos a ese tipo de mensaje. Los costos operativos (tales como la descripción del campo) se calculan separadamente en la columna "longitud" de cada cuadro de campo de mensaje. En la siguiente descripción, se describe una estructura de datos de mensaje genérica compartida por todos estos mensajes, seguida por una descripción detallada de la estructura de datos de mensaje para cada uno de los diez mensajes incluidos en el protocolo de la presente invención. Después de esta discusión, se proporcionará una descripción de cada una de las estructura de datos de campo que se utilizan para construir los mensajes de la presente invención. Se ilustra en la Figura 5 un diagrama de una estructura de datos ilustrativa que ilustra la estructura de datos de mensajes básica 260 utilizada para construir los diez mensajes del PNRP de la presente invención. Como se podrá ver, la estructura de datos del mensaje 260 comprende un número de campos 262^. En una modalidad preferida, el primer campo 262i está reservado para el Encabezado del PNRP. La estructura de datos de campo 264 para cada uno de los campos individuales 2621-N que se utilizan para construir el mensaje 260 incluye un componente de tipo 266, un componente de longitud 268, y el contenido o carga útil actual 270 de la estructura de datos de campo 264. El componente de longitud 268 se calcula como la longitud 272 del campo completo 264. En esta forma, el protocolo es completamente extensible. De acuerdo con la estructura de datos de la presente invención, se construye el mensaje RESOLVER. Como se puede ver del diagrama de la estructura de datos simplificada de la Figura 6, el mensaje RESOLVER 280 está construido de un número de campos 282-292. También de acuerdo con la estructura de datos de campos de la presente invención, los varios campos son construidos. Por ejemplo, el campo PN RP E CABEZADO 282 comprende la estructura de datos de campo 294. Los componentes de esta estructura de datos 294 incluyen el tipo (ID Campo 296), la longitud 298. El contenido de esta estructura de datos PNRP_ENCABEZADO 294 incluye un componente de protocolo 300, un componente de versión mayor 302, un componente de versión menor 304, un componente de tipo de mensaje 306, y un componente de ID de mensaje 308. Similarmente, el campo VALIDAR_PNRP_ID 288 contiene la estructura de datos de campo 310. Como con las otras estructuras de datos de campo, la estructura de datos VALIDAR_P RP_ID 310 empieza con un componente de tipo (ID Campo 312) y componente de longitud 314. El contenido de esta estructura de datos de campo incluye el componente de ID P2P 316 y el componente de ubicación del servicio 318. Cada uno de los diferentes campos son construidos en una forma similar según ilustrada en la Figura 5, las descripciones de cada una se proporcionarán más adelante. Como ahora será aparente y se ilustrará a continuación, este mensaje RESOLVER contiene un ID de PNRP objetivo, el CPA del originador de RESOLVER, el CPA de "mejor coincidencia", y una lista de nodos que han procesado RESOLVER. RESOLVER incluye un campo de "banderas". Dos banderas se definen por el subcampo de Banderas del campo Resolver_Controles: RF_ENVIAR_CADENA 0x0001, el cual solicita que el receptor envíe una cadena de certificado (si existe alguna) en la respuesta AUTORIDAD; y RF_IGNORAR_SIGU IENTEPUNTOCONEXION - 0x0004, el cual se utiliza en la trayectoria de retroceso de un RESOLVER. Si un nodo está recibiendo RESOLVER como parte del retroceso, el remitente no sabe que el ID de PNRP de este nodo. El campo "siguiente punto de conexión" se fija a cero, y RF_IG ORAR_SIGU IENTEPU TOCO EXION es establecido para indicar que la AUTORIDAD solamente se usará como un "ack" para RESOLVER. Como se discutió anteriormente, la recepción de RESOLVER es aprobada por un mensaje de AUTORIDAD. El Tipo de Mensaje en el Encabezado es fijado a 5 en una modalidad preferida de la presente invención. Los detalles de la estructura de datos del mensaje RESOLVER construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 5.

CUADRO 5 En este Cuadro 5 P es la longitud en bytes de CPA codificado, redondeando hasta el limite DPALABRA más cercano. A es el número de entradas en el arreglo abanderado. Esto no deberá exceder el valor Máx Puntos de Conexión. Una RESPUESTA se genera cuando un RESOLVER alcanza al nodo que posee el ID de PNRP objetivo, o cuando el tamaño de la trayectoria abanderada es igual a Máx Puntos de Conexión RESOLVER. Cuando una RESPUESTA es generada, todas las entradas de la trayectoria abanderada RESOLVER correspondientes son copiadas en la trayectoria RESPUESTA. Los mensajes RESPUESTA son dirigidos a través de todas las direcciones marcadas 'aceptada' en la Trayectoria, desde la parte inferior hasta la parte superior, hasta que el punto final de la red apropiado ha procesado la RESPUESTA y es devuelta al originador de RESOLVER. Como se discutió anteriormente, una recepción de RESPUESTA es aprobada por un mensaje ACK. En una modalidad preferida, el Tipo de Mensaje en el Encabezado se fija a 6. Los detalles de la estructura de datos del mensaje RESPUESTA construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 6.

CUADRO 6 En este Cuadro 6, P es la longitud en bytes de la CPA fuente codificada, redondeada hasta el límite DPALABRA más cercano. B es el número de entradas en el arreglo de punto final. El mensaje SOLICITAR requiere que el receptor PUBLICAR algunas entradas de su caché al remitente. El remitente incluye un CPA que el receptor debe agregar a su caché. El valor de EstaOcasiónDesglosado debe ser devuelto en el mensaje PUBLICAR. El receptor de SOLICITAR es aprobado mediante un mensaje PUBLICAR. En una modalidad preferida, el Tipo de Mensaje en el Encabezado se fija a 1. Los detalles de la estructura de datos del mensaje SOLICITAR construido de acuerdo con las enseñanzas de la presente invención se presentan e el Cuadro 7. En este cuadro P es la longitud en bytes de la fuente codificada de CPA, redondeada al límite DPALABRA más cercano.

CUADRO 7 El mensaje PUBLICAR se genera en respuesta a un SOLICITAR. PUBLICAR lista algunos de los IDs de PNRD en el caché del publicador. Esto permite al receptor de PUBLICAR selectivamente CPAs de SOLICITUD para popular su caché. El receptor de PUBLICAR actúa como una aprobación de un SOLICITAR. No se genera ninguna aprobación para PUBLICAR. Cualquier PUBLICAR que no está actuando como una aprobación de un SOLICITAR deberá ser silenciosamente descartado. En valor de EstaOcasiónDesglosado debe ser idéntico al recibido en el mensaje SOLICITAR. Un nodo que recibe un PUBLICAR, debe ser capaz de validar que el valor de EstaOcasiónDesg losado en válido. En una modalidad preferida, el Tipo de Mensaje en el Encabezado se fija a 2. Los detalles de la estructura de datos del mensaje PUBLICAR construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 8. En este Cuadro A es el # de entradas en el arreglo de ID.

CUADRO 8 Compensación ..ongitud Tipo Nombre Descripción 0 4+8 ENCABEZADO PNRP Encabezado Encabezado 12 4+4 PNRP ENCABEZADO ACKED ACKd del Encabezado Encabezado de SOLICITAR que está siendo implícitamente ACKd 20 4+8+ PNRP ID ARREGLO ID del arreglo Arreglo A*32 clasificado de los IDs de PNPR disponibles para DEMANDAR 32+ 4+4 ESTAOCASION DESGLOSADO EstaOcasiónDesg losado Valor codificado A*32 de esta ocasión El mensaje DEMANDAR se utiliza para solicitar a un anunciante que INUNDE un subgrupo de CPAs PUBLICADOS. El valor de Esta Ocasión debe estar desglosado y comparado con el valor de EstaOcasiónDesglosado recibido en SOLICITAR original. El arreglo ID contiene IDs de PNRP que el remitente le gustaría que se inundaran otra vez al remitente para que pueda obtener los CPAs. El receptor de DEMANDAR es aprobado a través de un mensaje ACK. En una modalidad preferida de la presente invención, el Tipo de Mensaje en el Encabezado se fija a 3. Los detalles de la estructura de datos del mensaje .DEMANDAR construido de acuerdo con las enseñanzas de la presente- invención se presentan en el Cuadro 9. En este Cuadro A es eí # de entradas en el arreglo de ID.

CUADRO 9 Compensación Longitud Tpo Nombre Dehuipciun 0 4+8 ENCABEZADO PNRP Encabezado Encabezado 12 4+4 ESTAOCASION Esta ocasión Valor de Esta ocasión codificado 20 4+8+ PNRP ID ARREGLO ID del arreglo Arreglo clasificado de los IDs A*32 de PNPR disponibles para DEMANDAR El mensaje INUNDAR se utiliza mediante PNRP para propagar CPAs guardados en memoria caché a pares seleccionados. Los INUNDAR se inician en respuesta a un mensaje DEMANDAR, cuando se agrega un nuevo CPA al nivel más bajo del caché, o cuando al procesar un CPA revocado con una versión anterior en el nivel más bajo del caché. Los INUNDAR incluyen una lista de direcciones para ayudar a prevenir INUNDAR redundantes, llamados 'lista inundada'. La lista Inundada contiene las direcciones del remitente, cada destino al que se dirige el remitente directamente para transmitir el INUNDAR, y la dirección de cualesquiera otros nodos PNRP que el remitente sabe que ya han recibido el INUNDAR. Una 'Lista Inundada' tiene un número máximo de entradas. Si la lista se llena, las entradas son reemplazas de acuerdo con una forma FIFO. Esto asume que Laos receptores de INUNDAR es más probable qüe propaguen INUNDAR a vecinos "más cercanos" que a los distantes. El receptor de INUNDAR es aprobado por un mensaje ACK. El ID validado es un campo de opción. Si está presente, solicita que el receptor responda con un ACK si un CPA con el ID del PNRP especificado es localmente guardado en la memoria caché, de lo contrario un NACK si no está. En una modalidad preferida, el Tipo de Mensaje en el Encabezado se fija a 4. Los detalles de la estructura de datos del mensaje INUNDAR construido de acuerdo con las enseñanzas de la presente invención se presenta en el Cuadro 10. En este cuadro P es la longitud en bytes del CPA codificado, redondeado hasta el límite DPALABRA más cercano, y A es el número de entradas en el arreglo.

CUADRO 10 Compensación Longitud Tipo - , .. · ~ , „ Nombre Descripción ' 0 4+8 ENCABEZADO PNRP Encabezado Encabezado 12 4+2+2 CONTROLESJNUNDAR Controles Código que describe la razón para INUNDAR. Puede ser utilizado en el procesamiento de INUNDAR. También, es una protección para moverse a un límite de 4 bytes. 20 (4+32) VALIDAR_ID_PNRP Validar CPA ID de PNPR ID opcional para verificar 20(+36) 4+P CPA_MEJOR_COINCIDENCIA CPA CPA que se está inundando 24+P(+36) 4+8+ I PV6_PU NTOF I AL_ARREG LO Lista A+20 Inundada El mensaje INVESTIGAR se utiliza a través de los nodos PNRP para realizar la validación de identidad en los CPAs seleccionados antes de introducirlos en el caché local. Una validación de identidad confirma un CPA que aún es válido en su nodo de origen, y solicita información para ayudar a validar la autoridad del nodo de origen para registra ese CPA. Una bandera se define para el campo 'banderas': RF_ENVIAR_CADENA, la cual solicita al receptor enviar una cadena cert (si existe alguna) en la respuesta AUTORIDAD. El receptor de INVESTIGAR es aprobado con un mensaje AUTORIDAD si el ID de PNRP está localmente registrado. Por el contrario el mensaje INVESTIGAR es silenciosamente ignorado. En una modalidad preferida, el Tipo de Mensaje en el Encabezado se fija a 7. Los detalles de la estructura de datos de mensaje INVESTIGAR construido de acuerdo con las enseñanzas de la presente invención se presenta en el Cuadro 11. Como será aparente a partir de este cuadro, existen 2. bytes adicionales después del CAMPO_ABANDERADO pone el siguiente campo en un límite DPALABRA.

CUADRO 11 El mensaje AUTORIDAD se utiliza para confirmar o negar que un ID de PNRP aún está registrado en el nodo local, y opcionalmente provee una cadena de certificado que permite al receptor de AUTOE I DAD validar el derecho del nodo a registrar el CPA correspondiente al ID objetivo. Las siguientes banderas están definidas por el campo 'banderas': AF_ID_DESCONOCIDO-0x0001 , la cual indica que el ID de PNRP 'validado' específico no está registrado en su huésped; AF_FUENTE_INVALIDA-0x0002, la cual no se utiliza: AF_MEJOR_COINCIDENCIA_INVALIDA-0x0004, la cual tampoco se usa; AF_RECH AZAR_DEM ASI ADO_OCUPADO-0x0008, la cual es solamente válida en respuesta a RESOLVER e indica que el huésped está demasiado ocupado para aceptar un RESOLVER, y el remitente deberá enviarlo a algún otro lugar para el procesamiento; AF_RECHAZAR_EXTREMOFINAL- 0x0010, la cual no se utiliza; AF_RECHAZAR_BUCLE - 0x0020, la cual indica que le nodo ya ha procesado el mensaje RESOLVER y que no debería haber sido enviado aquí; AF_RASTREANDO_ACTIVADO - 0x0040, la cual se utiliza solamente para la depuración; AF_REDI RIGI R- 0x0080, la cual indica que ese nodo no está enviando el mensaje RESOLVER, pero ha incluido una dirección de Referencia en el mensaje AUTORIDAD; AF_SOLICITUD_INVALIDA - 0x0100, la cual indica que ese mensaje RESOLVER falló en la validación lo cual puede suceder si MáxPuntosConexión es demasiado largo; y AF_CADE A_CERT -0x8000, la cual indica que una cadena de certificado está incluida habilitando la validación de la relación entre el ID del PNRP Validado y la clave pública utilizada para firmar CPA. El ID del PNRP Validado tiene el ID para el cual la AUTORIDAD se envía. La Cadena de Certificado es opcional. La bandera AF_CADENA_CERTIFICADO indica, si está presente o no. El Punto Final de Referencia también es opcional. Este campo se utiliza a través de un nodo que no puede enviar un mensaje RESOLVER, pero conoce otro nodo al cual el mensaje RESOLVER se puede enviar. El punto final contiene una dirección IPv6 de un nodo par al cual RESOLVER se va a enviar. Actualmente este campo es ignorado excepto cuando un nodo está tratando de detectar una división de nube a través de un servidor de origen. El campo Clasificador contiene la cadena Clasificador actual que es parte del Nombre Par utilizado para crear el ID de PNRP. El receptor de AUTORIDAD no es explícitamente aprobado. AUTORIDAD solamente se envía como una aprobación/respuesta ya sea al mensaje INVESTIGAR o al RESOLVER. Si una AUTORIDAD alguna vez se recibe fuera de este contexto, debe ser descartada. En una modalidad preferida, el TipoMensaje en el Encabezado se fija a 8. Los detalles de la estructura de datos del mensaje AUTORIDAD construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 12. En este Cuadro C es la longitud en bytes de la cadena cert codificada, redondeada hasta el límite DPALABRA más cercano, y S es la longitud en bytes de la cadena Clasificadora.

CUADRO 12 El mensaje AUTORIDAD puede ser muy largo, ya que contiene una Cadena de Certificado y una cadena de Clasificador. Para facilitar la transmisión a través de una red, puede ser explícitamente separada en varios fragmentos cuando se envía. El receptor debe ser capaz de poner los fragmentos juntos antes de procesar el mensaje. Si el mensaje está dividido, entonces los campos del Encabezado y del Encabezado Ack'd se repiten en cada fragmento. Cada fragmento también contiene un campo de Control de División. En cada fragmento el valor de Compensación en el campo de Control de División se cambian para reflejar la Compensación del fragmento. El valor del Tamaño en los Controles de División es el tamaño del mensaje completo, menos el Encabezado, el Encabezado Ack'd y el tamaño del campo del Control de División. Cada fragmento excepto el último, deben tener el mismo tamaño. Si el mensaje no está dividido, entonces el campo de Controles de División es opcional. El mensaje ACK se utiliza a través del PNRP como si fuera un protocolo de solicitud/respuesta. En ciertas circunstancias, la utilizar un ACK en lugar de una respuesta simplifica el protocolo. Un ACK siempre se transmite una vez la recepción de los mensajes SOLICITUD, RESPUESTA e INUNDAR. Otros mensajes son aprobados por el tipo de mensaje de respuesta apropiado. El ACK puede actuar como un ACK, o en el caso de una INUNDAR con un ID Validado establecido, como un NACK estableciendo el campo de Banderas a KF_NACK = 1. En una modalidad preferida el TipoMensaje en el Encabezado se fija a 9. Los detalles de la estructura de datos del mensaje ACK construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 13.

CUADRO 13 El mensaje REPARAR se utiliza porque, en algunos casos, las nubes PNRP puede experimentar una división. Este mensaje se utiliza para probar una división e iniciar un REPRAR si es necesario. Un REPARAR le solicitará á otros nodos propagar REPARAR a otros niveles del caché. En una modalidad preferida el TipoMensaje en el Encabezado se fija a 10. Los detalles de la estructura de datos del menaje REPARAR construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 14. Como será aparente a partir de este cuadro, existen dos bytes adicionales después del NIVEL_CACHE para poner el siguiente campo en un límite DPALABRA.

CUADRO 14 Habiendo discutido los mensajes y sus estructuras de datos, ahora se vuelve la atención a los elementos de mensaje utilizados para construir estos mensajes. Lo siguiente detalla los códigos de bytes de las estructuras transmitidas en los mensajes PNRP. Todos los números se transmiten en el orden de bytes de la res y todo el texto está codificado como UTF-8 antes de la transmisión, a menos que se indique otra cosa. Estos elementos del mensaje están en los bloques de construcción para los mensajes justamente discutidos. El elemento básico del mensaje es una descripción del Campo. Cada elemento del Campo deberá de empezar en un límite de 4 bytes dentro de un mensaje. Esto significa que puede haber huecos entre los Campos. El elemento CAMPO_MENSAJE es la descripción del campo que se utiliza para asegurar que PNRP será fácilmente extensible en el futuro. Para cada grupo de datos en un mensaje, proporciona un 'ID de campo' de 16 bits identificando el tipo de campo, y un conteo de bytes de 16 bits para el campo. Los detalles de la estructura de datos del elemento CA PO_MENSAJE construido de acuerdo con las enseñazas de la presente invención se presentan en el Cuadro 15.

CUADRO 15 El ENCABEZADO_PNRP- tipo 0x0010 se utiliza para iniciar todos los mensajes PNRP. Protocolo + Versión forman un identificador de 4 bytes útil para determinar si un mensaje recibido verdaderamente pretende ser PNRP. Los de la estructura de datos del elemento ENCABEZADO_PNRP construido de acuerdo con las enseñazas de la presente invención se presentan en el Cuadro 16.

CUADRO 16 El ID del Mensaje en el ENCABEZADO_P P se utiliza para que un nodo pueda asegurar que un mensaje recibido que pretende ser la respuesta a un mensaje que el nodo envía, es de hecho dichia respuesta. Por ejemplo, suponer que un nodo envía un mensaje RESOLVER a otro nodo. Este primer nodo espera recibir un mensaje AUTORIDAD a cambio, como se ilustra en la Figura 4. Sin embargo, no existe ninguna garantía de que un mensaje de AUTORIDAD recibido sea legítimo o interceptado por un nodo malicioso en la nube. Al incluir un ID de Mensaje en el mensaje RESOLVER, el nodo que genera el mensaje AUTORIDAD puede incluir este ID del Mensaje en su respuesta en el campo PNRP_ENCABEZADO_ACKED discutido más adelante. El PNRP_ENCABEZADO_ACKED - tipo 0x0018 es un encabezado de mensaje PNRP completo, utilizado para identificar un mensaje que está siendo ACK'd. Los detalles de la estructura de datos del elemento PNRP_ENCABEZADO_ACKED construido de acuerdo con las enseñanzas de la presente invención se presenta en el Cuadro 17.

CUADRO 17 El elemento I PV6_PUNTOFINAL - tipo 0x0021 se utiliza porque PNRP está especificado para trabajar en nubes IPv6. Esta estructura especifica un punto final de red IPv6. También hay una bandera que puede ser utilizada para indicar la utilidad del nodo para un RESOLVER en progreso. La Bandera de la Trayectoria se utiliza para indicar si un RESOLVER enviado a la Dirección fue Aceptado o Rechazado. Además de si la Dirección estuvo cerca de un vecino más cercano, la bandera de Sospechoso puede ser establecida, ya que el nodo deberá conocer a todos su vecinos cercanos. El indicador de DireccionRemovida se utiliza durante la verificación del script del programa para marcar una entrada como removida, sin actualmente removerla. Estos indicadores son como siguen: PN RP_ABANDERADA_DIRECCION_ACEPTADA - 0x01; PNPR_ABANDERADA_DI ECCIO _RECH AZADA - 0x02; PN RP_ABADERADA_DIRECCIÓN_I INALCANZABLE - 0x04; PNPR_ABANDERADA_DIRECCION_BUCLE - 0x08; PNPR_ABANDERADA_DIRECCION_DEMASIADO_OCUPADA 0x10; PN PR A BANDERA DA_ID_D IR ECC ION _ A L_ VALI DADO - 0x20; PNPR_ABANDERADA_DIRECCION_REMOVIDA - 0x80; y PNPR_ABANDERADA_ID_REGISTROCANCELADO_SOSPECHO SO - 0x40: Los detalles de la estructura de datos del elemento IPV6_PUNTOFINAL construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 18.

CUADRO 18 El elemento PNRP_ID - tipo 0x0030 es una concatenación de un ID p2p de 128 bits y una ubicación del servicio de 128 bits. Los detalles de la estructura de datos del elemento PNPR_ID construido de acuerdo con las enseñanzas de la presente invención de presentan en el Cuadro 19.

CUADRO 19 El ID_PNRP_OBJETIVO- tipo 0x0038 es el ID objetivo para una solicitud RESOLVER o su RESPUESTA correspondiente. Los detalles de la estructura de datos del elemento ID_PNRP_OBJETIVO construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 20.

CUADRO 20 El VALIDAR_ID_PNRP - tipo 0x0039 es el ID de PNRP para el cual se solicita la validación y la autoridad. Los detalles de la estructura de datos del elemento VALI DAR_ID_PNPR construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 21.

CUADRO 21 Las banderas de identificación CAMPO_BANDERAS - tipo 0x0040 son un campo de bits utilizado para propósitos específicos de contenido. Los detalles de la estructura de datos del elemento CAMPO_BANDERAS construido de acuerdo con las enseñanzas de la presente invención en el Cuadro 22.

CUADRO 22 El campo RESOLVER_CONTROLES - tipo 0x0041 contiene información que se va a utilizar en el procesamiento de RESOLVER o RESPUESTA. Las banderas se utilizan para indicar si el RESOLVER está en retroceso o si un mensaje AUTORIDAD es solicitado. Las banderas incluyen RF_IGNORAR_SIGUIENTE_PUNTOCONEXION -0x0001; RF_EN VIAR_CADEN A - 0x0004; RF_NO_REMOVER_ENTRADAS_TRAYECTORI A - 0x0008; los cuales se utilizan solamente para depurar; y RF_RASTREANDO_ACTI ADO - 0x0010, el cual se utiliza solamente para depurar. Los Puntos de Conexión Máximos limitan el número de puntos de conexión antes de completar RESOLVER. El Código de Operación describe cómo la comparación deberá ser realizada. Las comparaciones solamente pueden ser los 128 bits superiores (ID P2P) para CUALQUEIR código, o deberán de considerar IDs registrados en el mismo nodo que el originador de RESOLVER. Los códigos de operación incluyen: BUSCAR_CODIGOOP_NINGUNO - 0; BUSCAR_CODIGOOP_CUALQUIER_NOMBREPAR - 1; BUSCAR_CODIGOOP_NOMBREPAR_MASCERCANO - 2; BUSCAR_CODIGOOP_NOMBREPAR_MASCERCAN064 - 4; y BUSCAR_CODIGOOP_BITS_SUPERIORES - 8. La precisión establece la precisión en la el ID coincidente con un número actual de bits. Este valor se utiliza si el código de operación es: BUSCAR_CODIGOOP_BITS_SUPERIORES. Se utiliza la razón para indicar si RESOLVER fue enviado como parte de un proceso de Reparar, debido al mantenimiento del caché, como parte de un Registro, o debido a una solicitud de aplicación. La Razón incluye: RAZON_SOLICITUD_APP - 0; RAZO REGISTRO -1; RAZON_MANTENIMIENTO_CACHE - 2; RAZO N_D ETE C C ION_RE PARAR - 3; RAZON_SINC_SOLICITUD -4; RAZON_CPA_VIA_RESOLVER- 5; RAZON_CPA_VIA_INUNDACION -6; RAZO N_RE PARAR -7; y RAZON_CPA_VIA_RETROCESO_INUNDACION - 8. El código del Resultado indica porque RESOLVER fue completado y convertido a una RESPUESTA. Esto puede indicar un éxito o una falla debido a que el conteo de puntos de conexión se excedió, no se encontró una mejor trayectoria, o demasiados vecinos fallaron en localizar un objetivo. Estos Códigos de Resultado incluyen: RESULTADO_NINGUNO - 0; RESULTADO_ENCONTRAR_COI CIDENCI A - 1; RESULTADO_PUNTOSCONEXION_MAXIMOS_LIMITE_HIT - 2; RESULTADO_NO_SEENCO TRO_ME JOR_TRAYECTORI A - 3; y RESULTADO_DEMASIADOS_ERRORES - 4. El ID de la transacción se utiliza mediante el originador de una solicitud para correlacionar la RESPUESTA. El originador de RESOLVER establece el valor ID de Trans y el nodo que inicia la RESPUESTA repetida del valor en el mensaje RESPUESTA. Los nodos intermedios no deberán alterar este valor. Los detalles de la estructura de datos del elemento RESOLVER_CONTROLES construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 23.

CUADRO 23 El elemento N I VEL CACHE - tipo 0x0042 describe que nivel de caché se va a utilizar cuando se ejecuta un REPARAR. Este se utiliza cuando se hace una dividir reparación de caché. Los detalles para la estructura de datos del elemento NIVEL_CACHE construido de acuerdo con las enseñanzas de la presente invención de presentan en el cuadro 24.

CUADRO 24 El elemento CONTROLE S_ INUNDAR - tipo 0x0043 contienen información que se va a utilizar en el procesamiento de INUNDAR. La Razón por la que INUNDAR fue enviado es el único código utilizado. Los detalles de la estructura de datos del elemento CONTROLES_INUNDAR construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 25.

CUADRO 25 CPA_FUENTE- tipo 0x0058 es el CPA utilizado como el CPA fuente en un mensaje SOLICITAR. El CPA está codificado para la transmisión en la red. Los detalles de la estructura de datos del elemento CPA FUENTE construido de acuerdo con las enseñanzas de la presente invención se muestran en el Cuadro 26.

CUADRO 26 El elemento CPA_MEJOR_COINCIDENCIA es el CPA utilizado como la 'mejor coincidencia' en un RESOLVER o RESPUESTA. El CPA se codifica para la transmisión en la red. Los detalles de la estructura de datos para el elemento CPA_MEJOR_COINCIDENCIA construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 27.

CUADRO 27 El elemento P RP_I D_ARREGLO - tipo 0x0060 incluye los IDs de PNRP para los mensajes PUBLICAR y DEMANDAR almacenados en el arreglo. Los datos, incluyendo los tamaños del arreglo se describen a continuación. Los detalles de la estructura de datos del elemento PNRP_ID_ARREGLO construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 28. i CUADRO 28 i I PV6_PUNTOFINAL_ARREGLO - tipo 0x0071 es un arreglo de todos los nodos que ya se han visitado. Los menajes inundados visitan una variedad de nodos. Cada nodo que ya ha sido visitado o transmitido se introduce en este arreglo. Los datos incluyendo los tamaños del arreglo se describen a continuación. Los detalles de la estructura de datos del elemento IPV6_PUNTOFINAL_ARREGLO construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 29.

CUADRO 29 El elemento IPV6_DIRECCION_REFERENCIA - tipo 0x0072 es un PuntoFinal IPv6 utilizado para proporcionar una dirección alternativa para enviar un RESOLVER. Este campo se utiliza en un mensaje AUTORIDAD cundo un nodo no quiere enviar un RESOLVER, pero quiere proporcionar una dirección que algún otro nodo puede tratar. Los detalles de la estructura de datos del elemento IPV6_DIRECCION_REFERENCIA construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 30.

CUADRO 30 El elemento IPV6J D_REFERENCIA - tipo 0x0073 se utiliza junto con IPv6_Dirección_Referencia para indicar el ID del PNRP que se está utilizando para la referencia. Los detalles de la estructura de datos del elemento IPV6_ID_REFERENCIA construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 31.

CUADRO 31 El elemento Cadena Cert (CADEN A_CERT) - tipo 0x0080 se construye utilizando el API CAPI de Windows. Primero el certificado que forma la cadena se pone dentro del almacén cert de memoria CAPI y después se exporta como un almacén cert codificado PKCS7.

Este almacén exportado se envía sin modificación. El elemento WCHAR - tipo 0x0084 se define para controlar un carácter UNICODE individual. Solamente se utiliza como parte del campo del arreglo UNICODE, tal como Clasificador. El Elemento CLASIFICADOR - tipo 0x0085 es la cadena del Clasificador UNICODE que fue utilizado como una base para el Nombre Par. Se codifica como un arreglo de elementos WCHAR. Los detalles de la estructura de datos del elemento CLASIFICADOR construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 32.

CUADRO 32 El elemento ESTAOCASION_DESGLOSADO - tipo 0x0092 es un valor de Esta Ocasión codificado que está incluido en un mensaje PUBLICAR. El receptor se espera que tenga la clave para descodificar el valor de EstaOcasión. Los detalles de la estructura de datos del elemento ESTAOCASION_DESGLOSADO construido dej i acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 33.

CUADRO 33 El elemento ESTAOCASION - tipo 0x0093 es un valor de EstaOcasión descodificado que está incluido en un mensaje DEMANDAR. El receptor se espera que valide que el valor de EstaOcasión coincida con el valor enviado antes de que fuera codificado. Los detalles de la estructura de datos del elemento ESTAOCASION construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 34.

CUADRO 34 El elemento DIVIDIR_CONTROLES - tipo 0x0098 se utiliza cuando un mensaje largo es enviado como series de fragmentos, en lugar de un mensaje individual. Cada fragmento incluye el campo Controles de División por lo que el mensaje puede ser construido a través del receptor. Los detalles de la estructura de datos del elemento DIVI DI R_CONTROLES construido de acuerdo con las enseñanzas de la presente invención se presentan en el Cuadro 35.

CUADRO 35 El elemento PNPR_RASTREAR - tipo 0x0099 se utiliza durante la depuración para controlar datos que pueden ser llevados a cabo de punto de conexión a punto de conexión entre los mensajes RESOLVER y RESPUESTA. Se utiliza para almacenar datos de rastreo. Puede no estar soportado en la versión final del protocolo. La descripción anterior de varias modalidades de la invención ha sido presentada para propósitos de ilustración y descripción. No pretende ser exhaustiva o limitar la invención a las modalidades precisas descritas. Numerosas modificaciones y variaciones son posibles en luz de las enseñanzas anteriores. Las modalidades descuidas se seleccionan y se describen para proporcionar la mejor ilustración de los principios de la invención y su aplicación práctica para por lo tanto habilitar a uno con experiencia en la técnica a utilizar la invención en varias modalidades y con varias modificaciones según sean adecuadas a un uso particular contemplado. Todas dichas modificaciones y variaciones están dentro del alcance de la invención según se determina a través de las reivindicaciones anexas cuando se interpretan de acuerdo con el alcance con el cual están honestamente, legalmente y equitativamente facultadas.

Claims (100)

REIVINDICACIONES

1. Un medio legible por computadora que tiene almacenado en el mismo una estructura de datos para uso en un protocolo de resolución de nombre interpar (PNRP), que comprende: un primer campo de mensaje que tiene un primer elemento de mensaje almacenado en el mismo; y por lo menos un segundo campo de mensaje que tiene un segundo elemento de mensaje almacenado en el mismo; y en donde cada elemento de mensaje comprende una estructura de datos del elemento de mensaje que comprende un campo de identificación de campo, un campo de longitud, y una carga útil.

2. El medio legible por computadora de acuerdo con la reivindicación 1, que comprende además una pluralidad de campos de mensaje cada uno teniendo un elemento de mensaje almacenado en el mismo.

3. El medio legible por computadora de acuerdo con la reivindicación 1, en donde el primer elemento de mensaje almacenado en el primer campo de mensaje comprende un elemento de mensaje de encabezado.

4. El medio legible por computadora de acuerdo con la reivindicación 3, en donde la carga útil del elemento de mensaje de encabezado incluye información que identifica un tipo de mensaje como siendo uno de los mensajes RESOLVER, RESPUESTA, SOLICITAR, PUBLICAR, DEMANDAR, INUNDAR, INVESTIGAR, AUTORIDAD, ACK, y REPARAR.

5. El medio legible por computadora de acuerdo con la reivindicación 3, en donde la carga útil del elemento de mensaje del encabezado incluye información que identifica un tipo de mensaje como siendo un mensaje RESOLVER, en donde el segundo elemento de mensaje almacenado en el segundo campo comprende un elemento de mensaje de controles de resolver, RESOLVER además comprende un tercer campo de mensaje que contiene un elemento de mensaje de identificación objetivo de PNRP, un cuarto campo de mensaje que contiene un elemento de mensaje de identificación de PNRP validado, un quinto campo de mensaje que contiene un elemento de mensaje de mejor coincidencia de la dirección par certificada (CPA), y un sexto campo de mensaje que contiene un elemento de mensaje de arreglo de punto final IPV

6. 6. El medio legible por computadora de acuerdo con la reivindicación 5, en donde la carga útil del elemento de mensaje de controles de resolver comprende un campo de bits para banderas específicas de contexto, un número máximo de nodos que el mensaje RESOLVER puede visitar, códigos de operación para controlar la operación resolver, un número de precisión de bits significativos para comparar, un código de razón que describe una razón para iniciar un RESOLVER, un código de resultado que describe una razón para devolver una respuesta, y un valor de identificación de transacción.

7. El medio legible por computadora de acuerdo con la reivindicación 5, en donde la carga útil del elemento de mensaje dei identificación de PNRP objetivo comprende un desglose de un nombre par de un par objetivo y una ubicación de servicio derivada de una dirección de servicio publicada.

8. El medio legible por computadora de acuerdo con la reivindicación 5, en donde la carga útil del elemento de mensaje de identificación de PNRP validado comprende un desglose de un nombre par de un nodo para el cual la validación y una autoridad es solicitada y una ubicación de servicio derivada de una dirección de servicio publicada del nodo para el cual la validación y autoridad son sol ¡citados.

9. El medio legible por computadora de acuerdo con la reivindicación 5, en donde la carga útil del elemento de mensaje de mejor coincidencia CPA comprende un CPA codificado.

10. El medio legible por computadora de acuerdo con la reivindicación 5, en donde la carga útil del elemento de mensaje de arreglo de punto final IPV6 comprende un número de entradas en un arreglo, una longitud total del arreglo, un identif icador para un tipo de cada entrada del arreglo, una longitud para cada elemento de arreglo, y un arreglo de las direcciones de cada nodo ya visitado o al cual el mensaje RESPUESTA fue transmitido.

11. El medio legible por computadora de acuerdo con la reivindicación 3, en donde la carga útil del elemento de mensaje del encabezado incluye información que identifica un tipo de mensaje que como siendo un mensaje de RESPUESTA, en donde el segundo elemento de mensaje almacenado en el segundo campo comprende un elemento de mensaje de controles de resolver y en donde el mensaje RESPUESTA además comprende un tercer campo de mensaje que contiene un elemento de mensaje de controles resolver, un cuarto campo de mensaje que contiene un elemento de mensaje del ID de PNRP objetivo, un quinto campo del mensaje que contiene un elemento de mensaje de mejor coincidencia CPA, y un elemento de mensaje de arreglo de punto final IPV6.

12. El medio legible por computadora de acuerdo con la reivindicación 11, en donde la carga útil del elemento de mensaje de los controles resolver comprende un campo de bits para banderas específicas de contexto, un número máximo de nodos que el mensaje RESOLVER puede visitar, códigos de operación para controlar la operación resolver, un número de precisión de bits significativos para comparar, un código de razón que describe una razón para iniciar un RESOLVER, un código de resultado que describe una razón para devolver una respuesta, y un valor de identificación de transacción.

13. El medio legible por computadora de acuerdo con la reivindicación 11, en donde la carga útil del elemento de mensaje de identificación de PNRP objetivo comprende un desglose de un nombre par de un par objetivo y una ubicación del servicio derivada de una dirección del servicio publicada.

14. El medio legible por computadora de acuerdo con la reivindicación 11, en donde la carga útil del elemento de mensaje de I I 93 mejor coincidencia de CPA comprende un CPA codificado.

15. El medio legible por computadora de acuerdo con la reivindicación 11, en donde la carga útil del elemento de mensaje de arreglo de punto final de IPV6 comprende un número de entradas en un arreglo, una longitud total del arreglo, un identificador para un tipo de cada entrada al arreglo, una longitud de cada elemento del arreglo, y un arreglo de las direcciones de cada nodo ya visitado o al cual el mensaje RESPUESTA fue transmitido.

16. El medio legible por computadora de acuerdo con la reivindicación 3, en donde la carga útil del elemento de mensaje del encabezado incluye información que identifica un tipo de mensaje como siendo un mensaje SOLICITAR, en donde el segundo elemento de mensaje almacenado en el segundo campo comprende un elemento de mensaje de la fuente CPA y en donde el mensaje SOLICITAR además comprende un tercer campo de mensaje que contiene el elemento de mensaje de está ocasión desglosado.

17. El medio legible por computadora de acuerdo con la reivindicación 16, en donde la carga útil del elemento de mensaje de la fuente CPA comprende un CPA fuente codificado.

18. El medio legible por computadora de acuerdo con la reivindicación 16, en donde la carga útil del elemento de mensaje de esta ocasión desglosado comprende un valor de esta ocasión codificado.

19. El medio legible por computadora de acuerdo con la reivindicación 3, en donde la carga útil del elemento de mensaje del encabezado incluye información que identifica un tipo de mensaje como siendo un mensaje de PUBLICAR, en donde el segundo elemento de mensaje almacenado en el segundo campo comprende un elemento de mensaje reconocido del encabezado PNRP, y en donde el mensaje PUBLICAR además comprende un tercer campo de mensaje que contiene un elemento de mensaje de arreglo de ID de PNRP, y un cuarto campo de mensaje que contiene un elemento de mensaje de esta ocasión desglosado.

20. El medio legible por computadora de acuerdo con la reivindicación 19, en donde la carga útil del elemento de mensaje reconocido del encabezado PNRP comprende una identificación de mensaje de que está siendo reconocido.

21. El medio legible por computadora de acuerdo con la reivindicación 19, en donde la carga útil del elemento de mensaje del arreglo de ID del PNRP comprende un número de entradas en un arreglo de ID de PNRP, una longitud total del arreglo, un identif icador para cada tipo de entrada del arreglo, una longitud para cada elemento del arreglo y un arreglo de IDs de PNRP.

22. El medio legible por computadora de acuerdo con la reivindicación 19, en donde la carga útil del elemento de mensaje de esta ocasión desglosado comprende un valor de esta ocasión codificado.

23. El medio legible por computadora de acuerdo con la reivindicación 3, en donde la carga útil del elemento de mensaje del encabezado incluye información que identifica un tipo de mensaje como siendo un mensaje de DEMANDAR, en donde el segundo elemento de mensaje almacenado en el segundo campo comprende un elemento de mensaje de esta ocasión, y en donde el mensaje DEMANDAR además comprende un tercer campo de mensaje que contiene un elemento de mensaje del arreglo de ID de PNRP.

24. El medio legible por computadora de acuerdo con la reivindicación 23, en donde la carga útil del elemento de mensaje de esta ocasión comprende un valor de esta ocasión descodificado.

25. El medio legible por computadora de acuerdo con la reivindicación 23, en donde la carga útil del elemento de mensaje del arreglo de ID del PNRP comprende un número de entradas en un arreglo de ID de PNRP, una longitud total del arreglo, un identif icador para un tipo de cada una de las entradas en el arreglo, una longitud de cada elemento del arreglo, y un arreglo de IDs del PNRP.

26. El medio legible por computadora de acuerdo con la reivindicación 3, en donde la carga útil de elemento de mensaje de encabezado incluye información que identifica un tipo de mensaje como siendo un mensaje INUNDAR, en donde el segundo elemento de mensaje en el segundo campo comprende un elemento de mensaje de controles de inundar, y en donde el mensaje INUNDAR además comprende un tercer campo de mensaje que contiene un elemento de mensaje de mejor coincidencia de CPA y un cuarto campo de mensaje que contiene un elemento de mensaje de arreglo de punto final de IPV6. 96

27. El medio legible por computadora de acuerdo con la reivindicación 26, en donde la carga útil del elemento de mensaje de controles de inundar comprende un campo de bits para banderas específicas de contexto, y un código de razón que describe la razón para la iniciación del mensaje INUNDAR.

28. El medio legible por computadora de acuerdo con la reivindicación 26, en donde la carga útil del elemento de mensaje de mejor coincidencia de CPA comprende un CPA codificado.

29. El medio legible por computadora de acuerdo con la reivindicación 26, en donde la carga útil del elemento de mensaje del arreglo del punto final de IPV6 comprende un número de entradas en un arreglo, una longitud total del arreglo, un identificador para un tipo de cada entrada de arreglo, una longitud de cada elemento del arreglo, y un arreglo de las direcciones para cada nodo ya visitado o al cual el mensaje RESPUESTA fue transmitido.

30. El medio legible por computadora de acuerdo con la reivindicación 3, en donde la carga útil del elemento de mensaje del encabezado incluye información que identifica un tipo de mensaje como siendo un mensaje de INVESTIGAR, en donde el segundo elemento de mensaje en el segundo campo comprende un elemento de mensaje del campo de banderas, y en donde el mensaje INVESTIGAR además comprende un tercer campo de mensaje que contiene un elemento de mensaje de identificación del PNRP.

31. El medio legible por computadora de acuerdo con la reivindicación 30, en donde la carga útil del elemento de mensaje de del campo de banderas comprende un campo establecido para banderas específicas de contexto.

32. El medio legible por computadora de acuerdo con la reivindicación 30, en donde la carga útil del elemento de mensaje de identificación del PNRP validado comprende un desglose de un nombre par de un nodo para el cual la validación y una autoridad son solicitados y una ubicación de servicio derivada de una dirección de servicio publicada del nodo para el cual la validación y una autoridad son solicitadas.

33. El medio legible por computadora de acuerdo con la reivindicación 3, en donde la carga útil del elemento de mensaje del encabezado incluye información que identifica un tipo de mensaje como siendo un mensaje de AUTORIDAD, en donde el segundo elemento de mensaje almacenado en el segundo campo comprende un elemento de mensaje de aprobación de encabezado PNRP, y en donde el mensaje AUTORIDAD además comprende un tercer campo de mensaje que contiene un elemento de mensaje de controles de división, un cuarto campo de mensaje que contiene el elemento de mensaje de campo de banderas, un quinto campo de mensaje que contiene un elemento de mensaje de ID de PNRP validado, un sexto campo de mensaje que contiene un elemento de mensaje de cadena de certificado, un séptimo campo de mensaje que contienen un elemento de mensaje de dirección de referencia IPV6, un octavo campo de mensaje que contiene un elemento de mensaje de identificación de referencia IPV6, y un noveno campo de mensaje que 98 contiene un elemento de mensaje clasificador.

34. El medio legible por computadora de acuerdo con la reivindicación 33, en donde la carga útil del elemento de mensaje de la aprobación del encabezado PNRP comprende una identificación de mensaje de un mensaje que está siendo aprobado.

35. El medio legible por computadora de acuerdo con la reivindicación 33, en donde la carga útil del elemento de mensaje de controles de división que comprende la información de un tamaño de la fragmentación y una compensación de la fragmentación.

36. El medio legible por computadora de acuerdo con la reivindicación 33, en donde la carga útil del elemento de mensaje del campo de banderas comprende un campo establecido para las banderas específicas de contexto.

37. El medio legible por computadora de acuerdo con la reivindicación 33, en donde la carga útil del elemento de mensaje de identificación de PNRP validado que comprende un desglose de un nombre par de un nodo para el cual la validación y una autoridad son solicitadas y una ubicación de servicio derivada de una dirección de servicio publicada del nodo para el cual la validación y una autoridad son solicitadas.

38. El medio legible por computadora de acuerdo con la reivindicación 33, en donde la carga útil del elemento de mensaje de de la cadena de certificado comprende un almacén de certificado codificado PKCS7.

39. El medio legible por computadora de acuerdo con la reivindicación 33, en donde la carga útil del elemento de mensaje de la dirección de referencia de IPV6 comprende una bandera de trayectoria par un punto final del nodo, un número de protocolo IP, un puerto IPV6, y una dirección IPV6 como una dirección del nodo alternativa.

40. El medio legible por computadora de acuerdo con la reivindicación 33, en donde la carga útil del elemento de mensaje de de la identificación de referencia de IPV6 que comprende un desglose de un nombre par y una ubicación de servicio para un nodo al cual la referencia está siendo hecha.

41. El medio legible por computadora de acuerdo con la reivindicación 33, en donde la carga útil del elemento de mensaje de del clasificador comprende una cadena del clasificador Unicode que se utilizó como una base para un nombre par, codificada como un arreglo de elementos WCHAR incluyendo un número de entradas en un arreglo de dirección, una longitud total del arreglo, un identificador para un tipo o cada entrada del arreglo, una longitud de cada elemento del arreglo, y un arreglo de caracteres Unicode.

42. El medio legible por computadora de acuerdo con la reivindicación 3, en donde la carga útil del elemento de mensaje de del encabezado incluye información que identifica un tipo de mensaje como siendo un mensaje ACK, en donde el segundo elemento de mensaje almacenado en el segundo campo comprende un elemento de mensaje de aprobación del encabezado PNRP.

43. El medio legible por computadora de acuerdo con la 100 reivindicación 42, en donde la carga útil del elemento de mensaje de de aprobación del encabezado comprende una identificación del mensaje de un mensaje que está siendo aprobado.

44. El medio legible por computadora de acuerdo con la reivindicación 3, en donde la carga útil del elemento de mensaje de encabezado incluye información que identifica un tipo de mensaje como siendo un mensaje de REPARAR, en donde el segundo elemento de mensaje almacenado en el segundo campo comprende un elemento de mensaje de identificación PNRP objetivo, y en donde el mensaje REPARAR además comprende un tercer campo de mensaje que comprende un elemento de mensaje del nivel de caché, y un cuarto campo de mensaje que comprende un elemento de mensaje del punto final de IPV6.

45. El medio legible por computadora de acuerdo con la reivindicación 44, en donde la carga útil del elemento de mensaje de identificación de PNRP objetivo comprende un desglose de un nombre par de un par objetivo y una ubicación de servicio derivada de una dirección de servicio publicada.

46. El medio legible por computadora de acuerdo con la reivindicación 44, en donde la carga útil del elemento de mensaje de del nivel del caché comprende un número de nivel de caché que identifica que nivel del caché será utilizado cuando se ejecuta una reparación .

47. El medio legible por computadora de acuerdo con la reivindicación 4, en donde la carga útil del elemento de mensaje de 101 del encabezado además incluye información que identifica un mensaje particular para permitir el rastreo de las respuestas a un mensaje particular.

48. El medio legible por computadora de acuerdo con la reivindicación 1, en donde el campo de longitud comprende información que identifica una longitud del elemento de mensaje, incluyendo la longitud del campo de identificación del campo, el campo de longitud, y la carga útil.

49. Un medio legible por computadora que tiene almacenado en el mismo una estructura de datos del mensaje RESOLVER para uso en un protocolo de resolución de nombre interpar (PNRP), que comprende: un primer campo de mensaje que tiene un elemento de mensaje de encabezado PNRP; un segundo campo de mensaje que tiene un elemento de mensaje de controles de resolver; un tercer campo de mensaje que contiene un elemento de mensaje de identificación de objetivo PNRP; un cuarto campo de mensaje que contiene un elemento de mensaje de identificación de PNRP validado; un quinto campo de mensaje que contiene un elemento de mensaje de mejor coincidencia de dirección par certificada (CPA); y un sexto campo de mensaje que contiene un elemento de mensaje del arreglo de punto final de IPV6.

50. El medio legible por computadora de acuerdo con la 102 reivindicación 49, en donde cada elemento de mensaje comprende una estructura de datos del elemento de mensaje que comprende un campo de identificación de campo, un campo de longitud y una carga útil.

51. El medio legible por computadora de acuerdo con la reivindicación 50, en donde la carga útil del elemento de mensaje de controles de resolver comprende un campo de bits para banderas específicas de contexto, un número máximo de nodos que el mensaje RESOLVER puede visitar, códigos de operación para controlar la operación resolver, un número de precisión de bits significativos para comparar, un código de razón que describe una razón para iniciar un RESOLVER, un código de resultado que describe una razón para devolver una respuesta, y un valor de identificación de transacción .

52. El medio legible por computadora de acuerdo con la reivindicación 50, en donde la carga útil del elemento de mensaje de la identificación de PNRP objetivo comprende un desglose de un nombre par de un par objetivo y una ubicación de servicio derivada de la dirección de servicio publicada.

53. El medio legible por computadora de acuerdo con la reivindicación 50, en donde la carga útil del elemento de mensaje de identificación de PNRP validado que comprende un desglose de un nombre par de un nodo para el cual la validación y una autoridad son solicitadas y una ubicación de servicio derivada de una dirección de servicio publicada del nodo para el cual la validación y una autoridad fueron solicitadas.

54. El medio legible por computadora de acuerdo con la reivindicación 50, en donde la carga útil del elemento de mensaje de la mejor coincidencia CPA comprende un CPA codificado.

55. El medio legible por computadora de acuerdo con la reivindicación 50, en donde la carga útil del elemento de mensaje del arreglo de punto final IPV6 comprende un número de entradas en un arreglo, una longitud total del arreglo, un identif icador para un tipo de cada entrada en el arreglo, una longitud de cada elemento del arreglo, y un arreglo de direcciones para cada nodo ya visitado o al cual el mensaje RESPUESTA fue transmitido.

56. Un medio legible por computadora que tiene almacenado en el mismo una estructura de datos del mensaje RESPUESTA para uso en un protocolo de resolución de nombre interpar (PNRP), que comprende: un primer campo de mensaje que tiene un elemento de mensaje de encabezado PNRP; un segundo campo de mensaje que tiene un elemento de mensaje de controles de resolver; un tercer campo de mensaje que contiene un elemento de mensaje de controles de resolver; un cuarto campo de mensaje que contiene un elemento de mensaje de ID del PNRP objetivo; un quinto campo de mensaje que contiene un elemento de mensaje de mejor coincidencia de dirección par certificada (CPA); y \ 104 un sexto campo de mensaje que contiene un elemento de mensaje del arreglo de punto final de IPV6.

57. El medio legible por computadora de acuerdo con la reivindicación 56, en donde cada elemento de mensaje comprende una estructura de datos del elemento de mensaje que comprende un campo de identificación de campo, un campo de longitud y una carga útil.

58. El medio legible por computadora de acuerdo con la reivindicación 57, en donde la carga útil del elemento de mensaje de controles de resolver comprende un campo de bits pata banderas de contexto específico, un número máximo de nodos que el mensaje de RESOLVER puede visitar, códigos de operación para controlar la operación de resolver, un número de precisión de bits significativos para coincidir, un código de razón que describe una razón para iniciar un RESOLVER, un código de resultado que describe una razón para regresar una respuesta, y un valor de identificación de transacción.

59. El medio legible por computadora de acuerdo con la reivindicación 57, en donde la carga útil del elemento de mensaje de la identificación de PNRP objetivo comprende un desglose de un nombre par de un par objetivo y una ubicación de servicio derivada de la dirección de servicio publicada.

60. El medio legible por computadora de acuerdo con la reivindicación 57, en donde la carga útil del elemento de mensaje de la mejor coincidencia CPA comprende un CPA codificado. 105

61. El medio legible por computadora de acuerdo con la reivindicación 57, en donde la carga útil del elemento de mensaje del arreglo de punto final IPV6 comprende un número de entradas en un arreglo, una longitud total del arreglo, un identificador para un tipo de cada entrada en el arreglo, una longitud de cada elemento del arreglo, y un arreglo de direcciones para cada nodo ya visitado o al cual el mensaje RESPUESTA fue transmitido.

62. Un medio legible por computadora que tiene almacenado en el mismo una estructura de datos del mensaje SOLICITAR para uso en un protocolo de resolución de nombre interpar (PNRP), que comprende: un primer campo de mensaje que tiene un elemento de mensaje de encabezado PNRP; un segundo campo de mensaje que tiene un elemento de mensaje de la fuente CPA; y un tercer campo de mensaje que contiene un elemento de mensaje de esta ocasión desglosado.

63. El medio legible por computadora de acuerdo con la reivindicación 62, en donde cada elemento de mensaje comprende una estructura de datos del elemento de mensaje que comprende un campo de identificación de campo, un campo de longitud y una carga útil.

64. El medio legible por computadora de acuerdo con la reivindicación 63, en donde la carga útil del elemento de mensaje de la fuente CPA comprende un CPA codificado. I 106

65. El medio legible por computadora de acuerdo con la reivindicación 63, en donde la carga útil del elemento de mensaje de de esta ocasión desglosado comprende un valor de esta ocasión codificado.

66. Un medio legible por computadora que tiene almacenado en el mismo una estructura de datos del mensaje PUBLICAR para uso en un protocolo de resolución de nombre interpar (PNRP), que comprende: un primer campo de mensaje que tiene un elemento de mensaje de encabezado PNRP; un segundo campo de mensaje que tiene un elemento de mensaje aprobado de encabezado PNRP; un tercer campo de mensaje contiene un elemento de mensaje de arreglo de ID de PNRP; y un cuarto campo de mensaje que contiene un elemento de mensaje de esta ocasión desglosado.

67. El medio legible por computadora de acuerdo con la reivindicación 66, en donde cada elemento de mensaje comprende una estructura de datos del elemento de mensaje que comprende un campo de identificación de campo, un campo de longitud y una carga útil.

68. El medio legible por computadora de acuerdo con la reivindicación 67, en donde la carga útil del elemento de mensaje de encabezado PNPR aprobado comprende una identificación de mensaje de un mensaje que está siendo aprobado / 107

69. El medio legible por computadora de acuerdo con la reivindicación 67, en donde la carga útil del elemento de mensaje de arreglo del ID de PNRP comprende un número de entradas en un arreglo de ID de PNRP, una longitud total del arreglo, un identificador para un tipo de cada entrada al arreglo, una longitud para cada elemento del arreglo y un arreglo de los IDs de PNRP.

70. El medio legible por computadora de acuerdo con la reivindicación 67, en donde la carga útil del elemento de mensaje de esta ocasión desglosado comprende un valor de esta ocasión desglosado.

71. Un medio legible por computadora que tiene almacenado en el mismo una estructura de datos del mensaje DEMANDAR para uso en un protocolo de resolución del nombre interpar (PNRP), que comprende: un primer campo de mensaje que tiene un elemento de mensaje de encabezado de PNRP; un segundo campo de mensaje que tiene un elemento de mensaje de esta ocasión; y un tercer campo de mensaje que contiene un elemento de mensaje arreglo del ID de PNRP.

72. El medio legible por computadora de acuerdo con la reivindicación 71, en donde cada elemento de mensaje comprende una estructura de datos del elemento de mensaje que comprende un campo de identificación de campo, un campo de longitud y una carga útil. 108

73. El medio legible por computadora de acuerdo con la reivindicación 72, en donde la carga útil del elemento de mensaje de esta ocasión comprende un valor de esta ocasión descodificado.

74. El medio legible por computadora de acuerdo con la reivindicación 72, en donde la carga útil del elemento de mensaje del arreglo del ID de PNRP comprende un número de entradas en un arreglo de ID de PNRP, una longitud total del arreglo, un identificador para un tipo de cada entrada al arreglo, una longitud para cada elemento del arreglo, y un arreglo de los IDs de PNRP.

75. Un medio legible por computadora que tiene almacenado en el mismo una estructura de datos del mensaje INUNDAR para uso en un protocolo de resolución del nombre interpar (PNRP), que comprende: un primer campo de mensaje que tiene un elemento de mensaje de encabezado de PNRP; un segundo campo de mensaje que tiene un elemento de mensaje de controles de inundar; un tercer campo de mensaje que contiene un elemento de mensaje de mejor coincidencia CPA; y un cuarto campo de mensaje que contiene un elemento de mensaje del arreglo del punto final de IPV6.

76. El medio legible por computadora de acuerdo con la reivindicación 75, en donde cada elemento de mensaje comprende una estructura de datos del elemento de mensaje que comprende un campo de identificación de campo, un campo de longitud y una carga 109 útil.

77. El medio legible por computadora de acuerdo con la reivindicación 76, en donde la carga útil del elemento de mensaje de controles de inundar comprende un campo de bits para banderas especificas de contexto, y un código de razón que describe una razón para iniciar un mensaje INUNDAR.

78. El medio legible por computadora de acuerdo con la reivindicación 76, en donde la carga útil del elemento de mensaje de la fuente CPA comprende un CPA codificado.

79. El medio legible por computadora de acuerdo con la reivindicación 76, en donde la carga útil del elemento de mensaje del arreglo de punto final IPV6 comprende un número de entradas en un arreglo, una longitud total del arreglo, un identificador para un tipo de cada entrada en el arreglo, una longitud de cada elemento del arreglo, y un arreglo de direcciones para cada nodo ya visitado o al cual el mensaje RESPUESTA fue transmitido.

80. Un medio legible por computadora que tiene almacenado en el mismo una estructura de datos del mensaje INVESTIGAR para uso en un protocolo de resolución del nombre interpar (PNRP), que comprende: un primer campo de mensaje que tiene un elemento de mensaje de encabezado de PNRP; un segundo campo de mensaje que tiene un elemento de mensaje de campo de banderas; y un tercer campo de mensaje que contiene un elemento de mensaje de identificación de PNRP validado.

81. El medio legible por computadora de acuerdo con la reivindicación 80, en donde cada elemento de mensaje comprende una estructura de datos del elemento de mensaje que comprende un campo de identificación de campo, un campo de longitud y una carga útil.

82. El medio legible por computadora de acuerdo con la reivindicación 81, en donde la carga útil del elemento de mensaje de campo de banderas comprende un campo establecido para banderas específicas de contexto.

83. El medio legible por computadora de acuerdo con la reivindicación 81, en donde la carga útil del elemento de mensaje de identificación de PNRP validado comprende un desglose de un nombre para de un nodo para el cual la validación y una autoridad se solicitan y una ubicación de servicio derivada de una dirección de servicio publicada del nodo para el cual la validación y una autoridad son solicitadas.

84. Un medio legible por computadora que tiene almacenado en el mismo una estructura de datos del mensaje RESOLVER para uso en un protocolo de resolución de nombre interpar (PNRP), que comprende: un primer campo de mensaje que tiene un elemento de mensaje de encabezado PNRP; un segundo campo de mensaje que tiene un elemento de mensaje de encabezado PNRP aprobado; un tercer campo de mensaje que contiene un elemento de mensaje de controles de división; un cuarto campo de mensaje que contiene un elemento de mensaje campo de banderas; un quinto campo de mensaje que contiene un elemento de mensaje de ID de PNRP validado; un sexto campo de mensaje que contiene un elemento de mensaje de la cadena de certificado; un séptimo campo de mensaje que contiene un elemento de mensaje de la dirección de referencia IPV6; un octavo campo de mensaje que contiene un elemento de mensaje de la identificación de referencia IPV6; y un noveno campo que contiene un elemento de mensaje de clasificador.

85. El medio legible por computadora de acuerdo con la reivindicación 84, en donde cada elemento de mensaje comprende una estructura de datos del elemento de mensaje que comprende un campo de identificación de campo, un campo de longitud y una carga útil.

86. El medio legible por computadora de acuerdo con la reivindicación 85, en donde la carga útil del elemento de mensaje de encabezado PNRP aprobado comprende una identificación del mensaje de un mensaje que está siendo aprobado.

87. El medio legible por computadora de acuerdo con la reivindicación 85, en donde la carga útil del elemento de mensaje de I 112 controles de división comprende información de un tamaño de la fragmentación y una compensación de la fragmentación.

88. El medio legible por computadora de acuerdo con la reivindicación 85, en donde la carga útil del elemento de mensaje del campo de banderas comprende un campo establecido para las banderas específicas de contexto.

89. El medio legible por computadora de acuerdo con la reivindicación 85, en donde la carga útil del elemento de mensaje de identificación del PNRP validado comprende un desglose de un nombre par de un nodo para el cual la validación y una autoridad se solicitan y una ubicación de servicio derivada de la dirección de servicio publicada del nodo para el cual la validación y una autoridad se solicitan.

90. El medio legible por computadora de acuerdo con la reivindicación 85, en donde la carga útil del elemento de mensaje de la cadena de certificado comprende un almacén de certificado codificado PKCS7.

91. El medio legible por computadora de acuerdo con la reivindicación 85, en donde la carga útil del elemento de mensaje de la dirección de referencia IPV6 comprende una bandera de trayectoria para un punto final del nodo, un número de protocolo IP, un puerto IPV6, y una dirección IPV6 como una dirección del nodo alternativa.

92. El medio legible por computadora de acuerdo con la reivindicación 85, en donde la carga útil del elemento de mensaje de 113 de identificación de referencia IPV6 comprende un desglose de un nombre par y una ubicación de servicio para un nodo al cual se hace una referencia.

93. El medio legible por computadora de acuerdo con la reivindicación 85, en donde la carga útil del elemento de mensaje clasificador comprende una cadena de clasificador Unicode que se utilizó como una base para un nombre par, codificado como un arreglo de elementos WCHAR incluyendo un número de entradas en un arreglo de dirección, una longitud total de arreglo, un identificador para un tipo o cada entrada al arreglo, una longitud de cada elemento del arreglo, y un arreglo de los caracteres Unicote.

94. Un medio legible por computadora que tiene almacenado en el mismo una estructura de datos del mensaje ACK para uso en un protocolo de resolución de nombre interpar (PNRP), que comprende: un primer campo de mensaje que contiene un elemento de mensaje de encabezado PNRP; y un segundo campo de mensaje que contiene un elemento de mensaje de encabezado PNRP aprobado.

95. El medio legible por computadora de acuerdo con la reivindicación 94, en donde cada elemento de mensaje comprende una estructura de datos del elemento de mensaje que comprende un campo de identificación de campo, un campo de longitud, y una carga útil.

96. El medio legible por computadora de acuerdo con la reivindicación 95, en donde la carga útil del elemento de mensaje del 114 encabezado PNRP aprobado comprende una identificación del mensaje de un mensaje que está siendo aprobado.

97. Un medio legible por computadora que tiene almacenado en el mismo una estructura de datos del mensaje REPARAR para uso en un protocolo de resolución de nombre interpar (PNRP), que comprende: un primer campo de mensaje que contiene un elemento de mensaje de encabezado PNRP; un segundo campo de mensaje que contiene un elemento de mensaje de identificación del encabezado PNRP objetivo; un tercer campo de mensaje que contiene un elemento de mensaje del nivel de caché; y un cuarto campo de mensaje que contiene un elemento de mensaje de punto final IPV6.

98. El medio legible por computadora de acuerdo con la reivindicación 97, en donde cada elemento de mensaje comprende una estructura de datos del elemento de mensaje que comprende un campo de identificación de campo, un campo de longitud, y una carga útil.

99. El medio legible por computadora de acuerdo con la reivindicación 98, en donde la carga útil del elemento de mensaje de identificación del PNRP objetivo comprende un desglose de un nombre par de un par objetivo y una ubicación de servicio derivado de una dirección de servicio publicada.

100. El medio legible por computadora de acuerdo con la reivindicación 98, en donde la carga útil del elemento de mensaje del nivel de caché comprende un número de nivel de caché que identifica que nivel del caché se va a utilizar cuando se ejecuta una reparación.