Dynamic addressing in transient networks

TECHNICAL FIELD The present invention relates to computer networks, and more specifically, to methods, systems, and computer program products used in a transient networking environment.

BACKGROUND In a peer-to-peer (or P2P) network, each communication node has a networking program that allows the node to initiate communication with another node that has the program. Because the network is decentralized, where each node has the same status (for P2P exchange purposes), these nodes are considered "peer nodes." The P2P network promises people that it will become a more efficient network, in which resources such as central processing unit (CPU) cycles, memory, and storage devices will not be wasted. These networks are ad hoc, because nodes can join and leave the network at will. Thus, P2P networks can be defined as "transient" networks.

Existing P2P programs provide facilities for dynamic query and discovery of peer nodes. However, the prior art has several disadvantages. The lack of a permanent network address is one of the disadvantages. Due to the dynamic addressing scheme used to assign network addresses to nodes, each time a specific node enters a P2P network, it generally has a different Internet Protocol (IP) address. (Users with dial-up accounts have different IP addresses each time they log in. Some users of "always connected" networks, such as certain digital subscriber line (or "DSL") accounts, may also have different logins for different logins. IP address). This lack of permanent network addressing will make it difficult for nodes to "remember" where they can obtain specific services or content resources. On the contrary, when a node needs content or a certain type of service, it generally must issue a new discovery request, and then determine whether to choose from a potentially large number of responses. This communication leads to very bursty network traffic.

Another disadvantage of existing P2P networks is that they do not have a trust model: because nodes do not have permanent network addresses, there is no existing method to permanently track which nodes are considered trustworthy and which nodes are considered untrustworthy. Then, when a node (or a user at that node) selects a peer node from which to obtain services or content, there is no "tracking record" or history can be used to determine how to choose from the set of nodes that respond to dynamic queries. The lack of this trust model means that the existing

03807173.8 p.

The P2P network does not provide support for secure transactions between transient communication members. (Sun Microsystem

03807173.8 The company's JXTA project is a P2P architecture that provides the concept of "peer group" or "shared space", in which nodes in the peer group can publish services. There is a set of core services in these services, which include membership, access rights, and resolver services. The defined method applies a client/server model for authentication, authorization, and naming in peer groups. That is, the concept of centralization is maintained, but only at the user group level. These peer groups are incorrectly portrayed as transient communities. Similarly, Groove Networks' Groove® products provide a collection of "shared services" within a peer-to-peer community (community), where the collection includes security, membership, and access control services. The security mechanism is a public key infrastructure ("PKI") for identity verification and key exchange with a shared secret key for confidentiality. Therefore, the implied need of digital signatures, digital certificates, and shared security services negates the concept of transient communities. ) A widely used P2P network is called GnutellaNet. GnutellaNet uses the following protocol, which allows users to exchange files directly between the storage resources of their computers without first going to the "download" website. Napster" is another well-known P2P network implementation in which users connect to Central website to find the MP3 music file, and then download the MP3 music file from each others computers. Although Napster is used exclusively for MP3 files, GnutellaNet allows downloading of any type of file content. There are many other P2P network implementations.

P2P networks have the potential to be more efficient than client-server networks. The potential for higher efficiency stems from the fact that P2P networks do not have a central server. In the client/server model, most of the processing power exists in the central server, so the processing load tends to be concentrated on the server. In a P2P network, it is possible to distribute tasks among all nodes in the network, leading to more efficient use of network resources. The dynamic nature of the P2P system and its potential for efficient load distribution have been touted as the next revolution in the information technology (TT") architecture. However, due to the above-mentioned limitations, the existing P2P network ownership and consumption It is not suitable for large-volume businesses (such as e-commerce or business-to-business transactions). (As mentioned above, existing P2P implementations are not suitable for secure transactions in transient communities, which are generally critical for e-commerce).

In addition, the existing P2P system cannot be managed (unmanage) and is isomorphic, making it unsuitable for implementing P2P in a large-scale robust IT architecture. In a large-scale robust IT architecture, many different types of services must be manageable. The way to interoperate.

The following technology needs to be provided: it can be used to take advantage of the advantages and potential of P2P networks while avoiding the shortcomings and limitations of existing methods.

03807173.8 Summary of the invention The present invention provides methods, systems and computer program products for improving peer-to-peer computing networks. In one aspect of the preferred embodiment, the improvement includes permanently identifying nodes in a network with a transient network community in which the set of nodes that make up the network can change over time. Preferably, the technique includes: assigning an initial network address to each node when it initially enters the network; creating a permanent node identifier for each of these nodes; storing the initial network address and the mapping between the permanent node identifier; and The permanent node identifier is used to resolve the identity of each node when each node enters the network later, even if the node may be assigned a different network address when entering the network later.

Whenever a specific node re-enters the network with a different network address, the stored mapping for the specific node is updated so that the stored mapped network address from the specific node is replaced by the different network address.

The permanent node identifier for a specific node is best generated based on the following: the initial network address of the specific node, the date on which the initial entry into the network occurred, optionally the time when the initial entry into the network occurred, and the number of domains in which the initial entry occurred Identifier.

The permanent node identifier can then be used to track the behavior of each node in the network (for example, how the particular node satisfactorily respond to requests from other nodes) and to track the network traversal path taken by content resources in the network.

Other aspects of the invention are defined in the dependent claims.

The embodiment(s) of the present invention will now be described with reference to the accompanying drawings, in which the same reference numerals always refer to the same elements.

Brief Description of the Drawings Figure 1 shows a prior art network service stack, which can be utilized by the implementation of the present invention; Figure 2 provides a diagram showing the components of the present invention, including an abstract view of their locations and interconnection relationships in a networked environment; Figure 3A A sample Simple Object Access Protocol ("SOAP") header is provided to illustrate how the preferred embodiment identifies the traversal path of a specific content resource, and Figure 3B provides a sample SOAP header to illustrate how the preferred embodiment identifies the reputation of a specific node (reputation);

Figures 4A and 4B provide example sample Extensible Markup Language ("XML") documents to illustrate the preferred

03807173.8 How to specify node reputation as node metadata in the first and alternative embodiments; Figure 5 provides a sample XML document to illustrate how the preferred embodiment uses content metadata to describe content resources; Figure 6 provides a sample XML document to illustrate In the preferred embodiment, how to specify the resource set, and according to the preferred embodiment, the resource set is created to record the mapping between the permanent node identifier and the current network endpoint and the mapping between the permanent content identifier and the current storage location of the content.

Figure 7 provides a sample XML document to illustrate how the preferred embodiment specifies the content traversal path definition, which identifies the path taken by a specific content resource since it entered the P2P network; The bootstrapping process performed by the nodes in the network during initialization; Figure 9 provides a sample XML document to illustrate how the preferred embodiment transmits the reputation information in the "alive Γ notification message" issued during the bootstrapping process of Figure 8 Figure 10 provides a sample XML document to illustrate the "spy" message, which can be used by the preferred embodiment to propagate the "live" message in the P2P network; Figure 11 shows that the node is used for positioning according to the preferred embodiment The content provider or service provider, the requester process for requesting content/service and receiving content/service; Figure 12 provides a sample SOAP envelope used to illustrate how the preferred implementation in the requester process of Figure 11 broadcasts the query, And Figure 13 provides a sample SOAP shell used to show how the node should query; Figure 14 provides a sample Hypertext Transfer Protocol ("HTTP") request message, which contains the SOAP shell to illustrate the process of the requester in Figure 11 , How the preferred embodiment requests sending content/service from a selected node, and Figure 15 provides an example HTTP response message to show how to send the requested content or the result of the requested service to the requester; FIG. 16 shows the provider process in which the node responds to the query from the requester according to the preferred embodiment, and if selected by the requester, responds with the requested content or the result of the requested service Figures 17A-17C show sample headers that can be used for the optional system management functions disclosed herein; and Figure 18 shows a management process that can be implemented by a system node that provides optional system management functions.

Detailed ways

03807173.8 The implementation (various) described below defines techniques to improve the operation of P2P networks. Each network participant (ie, node) is assigned a permanent identifier so that it can be identified after it leaves and re-enters the network. The path taken by the content traversing the network is tracked and permanent. As disclosed here, making the content path and the context node information permanent will be able to maintain a peer-to-peer relationship between launches. Therefore, the disclosed technology overcomes the shortcomings of the prior art and enables the relationship between peer-to-peer devices to continue beyond a single session, even if the community in which participants communicate is a strictly defined transient network.

The disclosed technology supports the inherent dynamic network addressing characteristics of the P2P network, and at the same time provides support for heterogeneous network nodes. Persistent information can be used to support business enterprise operations, including network management, transactions, and the application of security policies.

In addition, the disclosed technology is conducive to providing a self-healing network. A self-healing network is a network in which task management/monitoring is performed while the network is running, and is independent of human intervention or management by an independent computing system. The technology disclosed here enables nodes to cultivate relationships with their peers, and to make this information permanent, so that malicious or poorly performing nodes for performance or functional integrity can be found (and then once detected, they can be prevented Adversely affect the network). (See http: //www. research, ibm. com/automatic/, which discusses the concept of self-healing networks in general, using the term "automatic calculation." The technology described here does not explain transients without centralized authorization. Change the self-repair in the network community.) The technology disclosed here is also conducive to improving the efficiency of P2P network operations. Unlike in the existing P2P network, which needs to broadcast the query to the entire subnet, the present invention discloses a hierarchical broadcast technology, which uses the permanent knowledge of the nodes in the network to reduce the generated network traffic.

Various peer-to-peer nodes will coexist in Yiwushang P2P network. The peer-to-peer network itself can represent a group of vertical peers that interact with each other in a consumer/supplier relationship (for example, perform a series of related services that can be defined as a directed graph between sub-services). Business Activity). Alternatively, the network can represent a group of horizontal peers that provide common functionality. The technology of the present invention can be used to improve the P2P architecture to provide automation and management functions to these nodes.

As an example, a group of peer nodes can provide storage resources within a storage area network (or "SAN"). The storage service provider ("SSP") maintains the SAN on a customer subscription or pay-per-use basis, and generally has a service-level agreement ("SLA") that specifies the SSP's Monthly service commitment. If the SLA promises are not fulfilled, customer charges may be adversely affected. In the P2P network, the node that needs storage can issue a dynamic network query to find the

03807173.8 Other nodes of the first ability. This type of peer dynamic query and discovery exists in the existing P2P network. However, as mentioned above, the existing P2P network does not have a trust model, and it is impossible to know how to choose a "good" node that provides storage. By using the technology of the present invention, the SSP can manage an autonomous storage partition as a P2P storage device, which has a reputation determined in real time, which reflects how well the storage request is currently processed. By using this dynamically obtained information, the storage device that is most capable of responding to the storage request can be determined, thereby facilitating the dynamic allocation of memory to the requester. In addition, using the technology of the present invention can more easily find specific storage resources that can respond to specific content requests.

(How the storage node processes the storage request can include the success rate of responding to the request, how efficiently the node responds to the request, the available storage capacity of the node, what content can be obtained from the node, etc.).

By making the content path and the context node information permanent, as will be detailed below, peer nodes can maintain their mutual relationship and their mutual understanding across the session-even if one or more nodes may leave And then re-enter the P2P network (where these re-entered nodes generally have changed network addresses). In addition, according to the technology disclosed herein, when information about the context of a specific node is obtained, the node develops what is referred to herein as "reputation." This reputation can then be used as the basis for the trust model. Reputation will be described in more detail below. (See the discussion in Figures 4A and 4B, which describes the best permanent information for the node's reputation).

The preferred embodiment of the present invention is deployed by using a network service model and a network service method for P2P networking, as described below with reference to FIG. 1, but the disclosed technology can also be used in other environments. The advantageous technology of the present invention discussed here is mainly applied to file sharing (that is, to find which content can be obtained from which node; remember the path taken by specific content when traversing the network; request content from peers and receive the content, etc. ). However, this is for illustrative purposes only, not for limitation. In addition to simple file sharing, the disclosed technology can be used for more complex interactions. For example, as known in the art, the network service model facilitates complex interactions. Generally, "network service" is an interface that describes a collection of operations that can be accessed by the network. A network service implements a specific task or set of tasks, and can work with one or more other network services in an interoperable manner to perform their part of a complex workflow, or define business transactions as a network service. As an example, completing a complex purchase order transaction may require an automatic interaction between the order placement service (ie, order placement software) of the ordering business and the order fulfillment service at one or more of its business partners. When the process is described as a network service, a node using the technology of the present invention can locate a peer node that can perform the service, and select a specific node (for example, based on the reputation of the node). When requested, the located peer node performs The service (which generally contains many sub-services), and then returns the result of the service to the requesting node.

03807173.8 The first network service technology is a well-known mechanism in the art for distributed application integration in client/server networks such as the World Wide Web, and this technology allows distributed networks in these networks to access software for program-to-program operations. Web services utilize many open web-based standards, such as HTTP, SOAP, and/or XML protocols, Web Service Description Language ("WSDL"), and Universal Description, Discovery, and Integration ("UDDI). HTTP is generally used to pass The TCP/IP ("Transmission Control Protocol/Internet Protocol") network such as the Internet exchanges messages. SOAP is an XML-based protocol used to call methods in a distributed environment. The XML protocol is the World Wide Web Consortium ("W3C") The evolving specification is used to design the application layer transfer protocol used to enable application to application messages. The XML protocol may be combined with SOAP. WSDL is an XML format used to describe distributed network protocols. UDDI is an XML-based protocol. With this technology, each company can list its services, and each service requester can find companies that provide specific services.

Distributed application integration in the client/server network is achieved by the following ways: issuing UDDI requests to locate distributed services through the UDDI registry, and by using SOAP/XML protocol and HTTP message, platform-independent WSDL format delivery Service information to dynamically bind the requester to the located service. (The reference to SOAP here should be understood to refer to the semantically similar aspects of the XML protocol peer-to-peer.) By using these components, web services provide requesters with access to program components that may reside in one or more remote locations. Transparent access, even if these components may be running on a different operating system from the requester and written in a different programming language. (For more information on SOAP, see http:/www.w3.org/TR/2000/N0TES-SOAP-20000508, titled Simple Object Access Protocol (SOAP) 1.1, W3C Note (May 8, 2000) For more information about XML, see http://www.w3.org/2000/xp. For more WSDL information about XML, see http://www.w3. org/TR/2001/NOTEwsdl-20010315, titled Web Services Description Language (WSDL) 1. 1, W3C Note (March 15, 2001). For more WSDL information about UDDI, see http: //ww. uddi. org/specification, html. HTTP is described in the Request for Comments (RFC) 2616 of the Internet Engineering Task Force, titled Hypertext Transfer Protocol-HTTP/1.1 (June 1999)).

Referring now to FIG. 1, a preferred embodiment of the technology disclosed herein utilizes the IBM Web Services Interoperability Stack 100 to provide underlying support for communication between nodes in a P2P network. However, this is only for illustration, not for limitation: other support mechanisms can also be used without departing from the concept of the invention disclosed herein. The components of the network service interoperability stack 100 will now be described.

03807173.8 Preferably, a directed graph is used to model the operations involved in executing a network service including multiple sub-services using the existing technology. For example, see the commonly assigned US patent application (serial number 09/956276, filed September 19, 01, titled Dynamic, Real-Time Integration of Software Resources through Services of a Content Framework). In the technology disclosed here, the nodes of the graph represent operations performed when a service is performed (where these services can also be called sub-services), and the edges of the graph nodes and graphs connecting graph nodes represent operations from one service to another Possible transfer of service operations. These graph edges, or "service links" can be defined by one or more transition conditions, and if applicable, can also be defined by data mapping information. These conditions specify the conditions under which the next linked service should be invoked. The results of previous service calls are usually used to determine these conditions. Data mapping refers to the following ability to link the various operations of the directed graph and transfer the data of one operation to another. For example, the data mapping information may indicate that the output parameter of one sub-service can be mapped to the input parameter of another sub-service.

Preferably, the Web Service Flow Language ("WSFL") is used to support these directed graphs. This is represented by service flow support 110 in FIG. 1. The way in which the WSFL engine processes the directed graph to perform complex network services has nothing to do with the understanding of the present invention, so it will not be described in detail here. For a detailed description of WSFL, see the WSFL specification, titled Web Services Flow Language (WSFL 1.0) (Professor F. Leymann, PhD, May 2001). This document can be obtained from IMB, or via the Internet at http://www-4.ibm. com/sof tware/solutions/webservices/pdf/WSFL.pdf.

Preferably, the UDDI message that accesses the UDDI registry is used to provide automatic discovery 120 and release 130 of network services (for example, network services available from various nodes in the P2P network)_o The WSDL layer 140 supports service description documents. SOAP can be used to provide XML-based messages 150. Protocols such as HTTP, file transfer protocol (FTP"), email, and message queue (MQ") can be used for network support 160. At runtime, you can use the UDDI service discovery process to discover services in the registry, and bind the service to use the information from its WS definition. Then, WSFL at runtime uses these definitions to aggregate services.

According to a preferred embodiment of the present invention, file sharing operations are facilitated by using information retrieved from the UDDI registry, and more complex network services can be supported in the same way. (See the discussion of Figure 2 below for more information on the use of the registry).

This embodiment discloses the following technology: through this technology, the nodes in the P2P network can be modeled as categories instead of strict peers. For example, this embodiment describes the "system" node. Here

03807173.8 The term "system node" used in Section 3 refers to the following nodes in a P2P network: the node provides functions of the type managed by a system administrator in an existing client/server network. These functions include network operations such as network management, load balancing, monitoring, and security. The P2P network with nodes implementing the present invention can span local area networks and enterprises, and is only limited by the scope of the World Wide Web. (For example, see the discussion of "snooping" messages that enable nodes to learn about nodes that may be on different subnets). On the other hand, in the existing P2P network, due to the configuration of the filter that monitors the IP address, the broadcast service flow is generally limited to the nodes in the subnet). Therefore, various types of nodes can join the network, and new types of nodes can also join the network; by using the technology disclosed here, this occurs in a non-interfering manner.

The concept of node (especially system node) category is an optional aspect of the present invention and can be used to create a hybrid form of P2P network, where some nodes direct other nodes or influence the information stored by these nodes. The special functions available to the system nodes will be described in more detail below.

According to a preferred embodiment, the nodes that implement one or more aspects of the present invention use a web service model running in the Apache Extensible Interaction System ("AXIS") engine environment, which has a processor that utilizes the AXIS link framework. (For more information on Apache AXIS, see ttp: //xml. apache, org/axis/index. html, which is the implementation of the SOAP protocol by the Apache Sof tware Foundation).

"AXIS" is the runtime environment of the SOAP service, in which the web service uses the container model to run. The servlet called router receives the inbound SOAP request message, determines which nodes are needed to execute the request, parallelizes the objects required by the code, and calls the code. When the called code is finished executing, the router will The result is serialized into an outbound SOAP response message.

The term "AXIS chain" refers to a configurable "chain" or sequence of message processors, which indicates the order of execution for inbound and outbound messages. "Processor" is executable code that implements specific functions and can be linked with other processor functions (through a link mechanism). The processor performs pre-processing or post-processing of the SOAP request. The deployment descriptor is used to specify how to deploy a particular service, including how to serialize/parallelize the objects used by the service and which AXIS processor chains to use. For example, SOAP message exchange may use encrypted data. Upon receipt of a message that contains confidential data, the decryption processor will decrypt the data (as a preprocessing step) and pass it to the appropriate message processing code. When the result is returned, the encryption processor encrypts the result (as a post-processing step) before sending the result in another SOAP message.

03807173.8 p.

The AXIS engine supports three types of processor chains. One is the transmission chain, which specifies the message transmission mechanism (such as HTTP)_oThe other is a service-specific chain. For example, for a specific service "XYZ", the service-specific chain specifies which processors are called when a message for service XYZ is received or a message is generated by service XYZ. The third type of processor is a global processor, which specifies the processor that is called for all messages.

Figure 2 shows the components used in the preferred embodiment, which abstractly shows how to locate and interconnect these components in a network environment. These components are now described.

In a preferred embodiment, the runtime engine 220 includes an AXIS execution engine 225; three AXIS processors 230, 235, 240 in the global processor chain; a link library 245; a metadata library 150; and a digital certificate library 255. Preferably, the runtime engine 220 is implemented in a network service and is represented by the network service 200. Optionally, the web service may choose to implement the tModel instance 205. It is known from the prior art that the tModel indicates the behavior or specification implemented by the network service. The tModel is stored in the UDDI registry to facilitate scanning the registry to find the realization of a specific service. The tModel can be used in the environment of the preferred embodiment of the present invention to specify the query type supported by the network service. One or more content libraries (eg, content library 210) store the local content of the node and/or references to remotely located content that can be accessed by the node represented by the runtime engine 220.

Three AXIS processors (described in detail below) are used in the preferred embodiment, and are referred to herein as "path declarator" 230, "rumor spreader" 235, and digital signature ("DSIG") processor 240. These processors are now described.

As described above, one or more aspects of the present invention define the following technology: the technology is used to perpetuate the path traversed by context node information and content shared between P2P network nodes. The path declarator 230 manages the permanent content path, which is defined here as using a directed graph model. In these directed graphs, graph nodes correspond to peer nodes through which content flows, and graph arcs indicate that content passes between nodes connected by each edge. (Do not confuse these directed graphs with the previously described directed graphs. The previously described directed graphs are used to define complex network service interactions and use WSFL support.) According to the preferred embodiment, the XML link (XLink) language is used as Represents a means of a directed graph that defines a content path to be permanent. XL ink language is defined in XML Linking Language (XL ink) Version 1.0, W3C Recommendation (June 27, 2001), which can be accessed from the Internet address http://www.w3. Found at org/TR/xl ink/. As known in the art, the XL ink grammar can be used to define simple, tagged links (including outbound links to remote resources and inbound links to identify resources linked to local nodes), or more complex extensions." Links. (Then the prior art does not know the XLink links disclosed here.) Extended links are used to represent nodes

03807173.8 The graph of the first and the arcs in between. One type of extended link is a "third party" link. The third-party XL ink is associated with remote resources, which means that the link definition is stored independently of the content linked together. FIG. 7 described below illustrates how the preferred embodiment of the present invention uses XL ink to permanentize the content traversal definition (or more generally, the message traversal path definition).

Note that although a permanent path definition that remembers the path taken by the content resource is used here to describe the preferred embodiment, this is only for illustration and not limitation. Path definitions can also be permanent for other information, such as the result of executing a service. Therefore, the term "content" used herein can be interpreted as referring to any type of information transmitted between nodes, and in particular, "content" is used to refer to content that has been generated or content that can be generated by requesting a node to perform a service. Abbreviation. In addition, a permanent path can be interpreted as a path representing a message regardless of the type of information carried by the message.

When a third-party XLink collection is stored together in an XML document, the collection is called a "link library" or "link library document". Therefore, the term "link library" as used herein refers to a collection of traversal paths of the third-party XLink. Use the format disclosed here to define the link library identifier to uniquely identify the node in the P2P network. (For more information on link library identifiers, see the discussion in Figure 4A below).

Therefore, the path declarator 230 manages the permanent message path as a link library. These link libraries include link collections, which define the paths traversed by specific content resources. These link libraries will be discussed in detail below.

The path declarator 230 is responsible for appending the SOAP header in the format shown in FIG. 3A to the outbound SOAP message to convey content traversal information. The header 300 includes a <traversalPathref> tag 305 (in the example of FIG. 3A, the tag is prefixed with a namespace identifier ρ, which represents a path), and the <traversalPathref> tag provides the equivalent for storing the specified content. Reference 310 of the link collection of the traversal path within the network. In the example of FIG. 3A, the value of the "href" attribute 310 indicates that the traversal path is stored in the link library document, and the link library document can use the uniform resource locator ("URL") "http://9. 56. 34" . 12/1 inkbase/lb. xml access.

When receiving a SOAP header with an incoming <traversalPathref> element, the path declarator 230 of the receiver is responsible for updating the link library of the receiver accordingly. This process involves adding the LBuuid of the receiving node in the arc to the end of the traversal path identified by reference 310. (Therefore, if the receiving node subsequently forwards content related to the traversal path, the modified traversal path identified in the SOAP header described with reference to FIG. 3A will correctly identify the forwarded node). For related traversal paths such as

03807173.8 See Figure 7 below for more information about the path between the identified nodes.

The rumor spreader 235 manages the reputation as metadata of the related node. In addition, the rumor spreader 235 will process the content metadata, and evaluate the content metadata when modifying nodes and reputation. The preferred embodiment of the present invention uses the resource description framework (RDF") concept (notion) to specify metadata describing both content and nodes. (RDF is a concept designed to specify network-based metadata. For more information about RDF For more information, see Resource Description Framework, (RDF) Model and Syntax Specification, W3C Recommendation (February 22, 1999), which is published by W3C on the Internet http://www.w3. org/TR/REC-rdf-syntax/). Because (as described above) P2P networks are highly distributed and the IP addresses of nodes can change over time, the gossip spreader disclosed here provides an evolutionary trust model in which trust evolves over time. In the beginning, the node trusts itself, and over time the node collects metadata about the content it receives through interacting with its peers and the path taken by the content. The collected metadata can be regarded as providing some kind of history or audit records. The more content with positive results received from a particular peer, the stronger the trust relationship with that peer. Optionally, the node can also derive trust from the relationship information obtained by its peers, where the relationship information describes how these nodes have interacted with other peer nodes (for the other peer nodes, the node may I haven't interacted with it yet).

Now refer to Figures 4A and 4B, which show the designated reputation data optimization and replacement technology. In a preferred embodiment, the reputation data of a node includes an indication of the service provided by the node and/or content available from the node, and the quality of service provided by the node. The reputation of a node is best implemented as metadata in messages sent from the node (and stored by the receiver). In a preferred embodiment, the quality of service is designated as a numerical value that represents the specific node's response to other nodes in the network (referred to as the "status value), which represents how successful the specific node responds to queries it receives from other nodes in the network The quality of service part of node and reputation indicates malicious nodes in some cases (for example, nodes that have shown a tendency to become malicious agents or resource sources). The ability to associate reputation with dynamically addressed nodes is beneficial in decentralized P2P Trust in the world, and once reputation information is available, the trust model using security policies can be applied to P2P interactions. This removes the main obstacles to e-commerce in P2P networks. (Note that although the preferred implementation described here is aimed at dynamic understanding However, in certain implementations, it may be desirable to initialize or configure the reputation of one or more nodes in advance, for example, to allow system administrators to perform system management, and such implementations are considered to fall within the scope of the present invention. The method can be used to give the selected node a relatively high

03807173.8 In the first place, these nodes are labeled as system nodes) According to a preferred embodiment, a link library identifier ("ID") or "LBuuid" is used to identify transient nodes in a P2P network, where the LBuuid has the following form: ( IP address-date-time-domain) and is based on the conceptual model of Uniform Resource Identifier or "UUID". UUID is a well-known technology that uniquely identifies objects or entities on the public Internet in this field. (However, the LBuuid format is not publicly known. The UUID in the prior art generally contains a reference to the IP address of the host generating the UUID, a timestamp, and a randomly generated part used to ensure uniqueness.) As an example of the LBuuid disclosed here , The node represented by the sample reputation in the document 400 of FIG. 4A has LBuuid

9. 37. 43. 2-05/04/01-12: 02: 05: 37-Netzero. net It is displayed as the value of the <Description> tag 405 about attribute 410. In this example, the IP address part is "9.37.43.2", the date part is 05/04/01, the time part is "12:02:05:37", and the domain part is "Netzero.net". As shown here As defined, the information indicates that the original IP address of the node when it first entered the P2P network was "9.37. 43.2", and the initial entry into the network occurred on the date "05/04/01" and the time "12:02" :05:37" in the network domain Netzero.net. As disclosed here, the LBuuid will be used to identify the specific node, so that the reputation of the node can be permanent, and the content path to be resolved is also allowed Traverse the reference to the node in the definition.

It should be noted that at a given point in time, the current IP address of the node represented by LBuuid in Figure 4A is not guaranteed to be the IP address indicated in the LBuuid, and is likely to be assigned from a dynamic address when subsequently entering the P2P network Some other value obtained by the scheme. Through the mapping stored in the resource set, the LBuuid that permanently represents the node is associated with the node and the current address (the resource set will be described below with reference to Figure 6).

The <Description> tag 405 holds up the reputation information of the node. In this example, a subtag 415 with a title of <QuerySet> is specified, and the subtag has a "stature" (status) attribute. In a preferred embodiment, the status attribute has a function that indicates how successful (or unsuccessful) the node executes the query The status attribute value is preferably specified as a non-integer value in the range of T to +1, where a negative status value indicates a malicious node. Preferably, the corresponding totalQueries" attribute is also specified, and its value indicates that the node has processed Integer of the total number of queries. Therefore, in the example of Figure 4A, the node has received 2145 queries and has successfully executed 34% of these queries. (In this example, the optional

03807173.8 The "ID" attribute, which uses the conventional UUID format to provide a value that uniquely identifies the query set 415. ) In an alternative implementation, the status (ie success rate) information can be associated with independent queries instead of the entire set of queries. An alternative is shown in Figure 4B, where the stature and totalQueries attributes are specified in the <Query> tag instead of the <QuerySet> tag. As will be seen below, other methods of representing status information can also be used without departing from the principle of the present invention. For example, a single attribute can be used that has a value in the format "34% of 2145" or "34, 2145". As another alternative, instead of using status values in the range of T to +1, separate attributes can be used to indicate unsuccessful (or malicious) results and successful results; alternatively, counters can be used instead of percentages.

Returning to the discussion of FIG. 4A, in the syntax used in the preferred embodiment, the <QuerySet> tag 415 has one or more <Query> child elements, where the <Query> element set lists the node and the set of queries that can be satisfied ( It is best expressed as a regular expression). In this example, the node can satisfy three different queries 420, 425, 430.

The regular expression syntax of the first <Query> tag 420 indicates that the node can be processed in the form ^tcpurchase-order 999-9999-999 query, that is, the text string purchase-order (purchase order)" followed by three numeric values, a hyphen, four numeric values, another hyphen, and three numeric values. (here In the example used, these numeric fields are used to specify the customer number.) The second <Query> tag 425 in the sample query set indicates that the node can process a text string expressed as a partner profile list. The third <Query> tag 430 represents a query of a text string ending with "-NDA. tiff".

Optionally, different or additional information can be used to determine the node reputation, so the information shown in FIGS. 4A and 4B is for illustrative purposes and not for limitation. For example, it may be beneficial to track the efficiency of nodes, and reputation data can be used for this purpose. If the efficiency is measured as the response time of processing the query (for example), the response time attribute can be added to the node reputation (or as a query-specific value using the method of FIG. 4B or more generally using the method of FIG. 4A). As mentioned above, node reputation is processed by the rumor spreader processor. Therefore, the reputation processing described here can be extended by the processor as needed to support additional or different types of reputation data.

The efficiency of tracking nodes helps to make more informed choices among content/service providers than those available in prior art P2P networks. When used in the previously discussed SSP environment, the SSP using the node efficiency information can make run-time judgments on how to select storage resources and provide storage resources, thereby improving the service to SSP customers and increasing the number of commitments in the SLA. possibility.

03807173.8 The reputation provides a hint to the remote node about the node's capabilities, and as described here, provides this information in the form of the node's ability to respond to queries. When used for file sharing purposes, sending a query to a node means asking the node "Do you have a file that meets this description?". The responding node provides its reputation to inform the requester that it can respond to the query (that is, it can provide the requested file), and also instructs it to provide the file in the past (using the method of Figure 4A) or provide the specific file (using the method of Figure 4B) Method) how to succeed.

Referring now to FIG. 5, an example illustrating a preferred technique for specifying content metadata (ie, information about specific content) is shown. By using this form of metadata information, a node can programmatically determine which queries it can respond to. In a preferred embodiment, RDF is used to specify content metadata in a similar manner as RDF is used for reputation metadata (refer to FIGS. 4A and 4B). As shown in the example in FIG. 5, the about attribute 510 of the <Description> tag 505 specifies the identifier of the content described in the document 500. According to a preferred embodiment, the "about" attribute value is an identifier that specifies the file name or other storage location for storing the content in response to a specific query. Therefore, in this example, the content is stored in the location purchase_order 123-4567-890.xml. This identifier is used as a permanent content key that can be used to associate content metadata with actual content.

In this example syntax, the <Description> tag 505 has subtags <Creator> 515 (creator) and <synopsis> 520 (summary). The <Creator> tag preferably has a date attribute and a time attribute, and its value specifies the creation date and time of the described content. (Alternatively, the date and time can be combined into a single Date-Time attribute.) The value of the <Creator> tag 515 identifies the person who created the content (in this example). Alternatively, the process identifier may be used as the value of the <Creator> tag (for example, the LBuuid of the P2P node of the content source). The <synopsis> tag 520 preferably has a free text value and can be used to provide a human-readable description of the corresponding content. Therefore, in this example, <synopsis> 520 indicates that the content stored at purchase_order 123-4567-890. xml is the purchase order No. 123-4567-890 of the AMEX customer.

The information in the <Description> element or selected parts thereof can be presented to the human user, for example, to help the person select a content/service provider from multiple candidates. In a more automated environment, the information from the <Description> element can be analyzed by the programming selection process. It will be seen that the content metadata shown in this example only describes the type of information that can be stored and the format in which that information can be expressed.

The gossip spreader is responsible for appending the SOAP header in the format shown in FIG. 3B to the outbound SOAP message to announce reputation information to the receiving node. The additional reputation header 350 contains <reputationRef>

03807173.8 Tag 355, which provides (using the "href" attribute 260) a reference to the reputation library that stores the reputation of the sending node. (The stored reputation information is about the sending node itself, and preferably also contains reputation information about peer nodes known to the sending node.) The rumor propagator 235 of the receiver finds the header field in the inbound SOAP message > Reputation metadata, and handle the reputation metadata as described below.

The digital signature processor 240 digitally signs the message entity to ensure the integrity of the message and the authenticity of the sender. The processor preferably follows the W3C SOAP digital signature specification, and uses PKI to manage certificates and apply/verify signatures. The SOAP digital signature and PKI technology are well known in the art, and will not be described in detail here.

If the system node is given the appropriate AXIS processor or gossip spreader privilege, the system node can actually directly read/write the remote peer link library and meta-database, for example, to force itself to be added to the pair In the peer group, insert the content traversal path definition, or manage the reputation of the peer (for example, modify the stored reputation information of node X so that it now identifies the member Z of the peer group of node X as malicious). Preferably, a new AXIS processor is used to implement this type of system management function, where the system management function can be used as a super rumor spreader because it can surpass the role of other rumor spreaders. Or, when multiple categories of nodes are supported, the existing AXIS processor can be modified to recognize category identifiers and determine which operations the corresponding node can access. For example, just when the "category 0" node (ie the default peer node) can query and declare its reputation, traverse path, etc., another "category N" node (such as the system node described here) may be allowed To read and write each link library and library, so as to actually manage the network view maintained by the node. (For more information about using additional AXIS processors to implement system management functions, see Figures 17A-17C and 18 below) Now return to the discussion of the content path stored in the link library, according to the preferred embodiment of the present invention The link library contains volatile parts and permanent parts. Here the volatile part is called the resource collection, and the permanent part is the traversal path definition collection. The XML document 600 in Figure 6 illustrates the resource collection. The resource collection is defined as a collection of XLink locator links. A group of such links is used to define The mapping between the dynamically assigned network address of each node known by the current node and the permanent LBuuid value. These links are specified as <node> elements. The other group is used to define the mapping of the downloaded content description to this The links to the current location of the content in the local content library. These links are specified as the <content> element.

The collection of link library resources is best stored as a memory-resident table to allow quick lookup of the mapping. Therefore, if a node wishes to interact with a peer node, it can query the table to find the nodes current

03807173.8 First address. The root element of the document storing the resource set is <ResourceSet>, which is defined to extend XL ink (see the type attribute at 605.) As shown in Figure 6, the first three elements 610, 630, and 645 define the newly parsed network The <node> element of the mapping between the end point (URL) and the ID of the permanent link library. The href attribute of the <node> element identifies the new end point, and the role attribute identifies the LBuuid that is permanently 4b. The fourth element 660 is a <content> element that specifies content resources and identifies local content that has been downloaded from the peer-to-peer network. The href attribute of the <content> element identifies the current storage location of the content, and the role attribute identifies the permanent storage location identifier.

Each <node> element is such a locator XL ink (for example, refer to the type attribute at 615), which has an href attribute indicating that the node network end point of the link library with an ID equal to the "role" attribute value is being maintained. For example, the href attribute 620 has the value http://9. 56. 34. 12/soap/rpcrouter. According to the mapping in element 615, this URL represents a node that manages a link library with a permanent LBuuid "9.37. 43. 2-05/04/01-12: 02: 05: 37-NetZero.net". The first <node> element 610 is about the local node (with the "local" attribute set to "true"), while the other <node> elements 630, 645 are about the remote node (with the value set to "false") "Local" attribute).

The <content> element 660 is also the locator XLink. The href attribute 665 of the mapping indicates the storage location file://usr/awesley/etc/downloads/purchase_order 123-4567-890. xml is currently used to save the local content identified as purchase-order 123-4567-890. xml" ( See "role" attribute 670).

The permanent part of the link library (that is, the traversal path definition) is represented in the resource collection by a set of arcs representing the traversal path of a specific content resource from one node to another node, where the nodes are identified by their respective link library IDs.

Referring now to FIG. 7, a sample traversal path 700 is provided. This sample illustrates how a directed graph can be used to track the path taken by content resources after it enters the P2P network. Use the <traversalPath> element to specify the traversal path. In this example, one or more <arc> elements represented by elements 710 and 735 are XL ink elements with arc (arc) type attribute. These <arc> attribute values specify the movement of the content from one node to another. The arc XL ink element utilizes the role of resources and locator nodes. Define the locator node in the resource collection, as shown in Figure 6, and use the resource attribute of the "> element in Figure 7 to identify the resource node. Now refer to the path starting with the <arc> link 710 for description, the < arc> link 710 is designated at 725 as

03807173.8 The content of "purchase-order 123-4567-890. xml" (according to element 670 in Figure 6, it is currently stored in the location file: //usr/awesley/etc/downloads/purchase-order 123-4567-890. xml ", and it means that the customer's purchase order for 123-4567-890) is generated by the node that manages the "12. 37. 43. 5-03/03/01-0&amp; 35: 13: 04-MindSpring. com" link library (see The value of the "from" attribute 720). The value of the "to" attribute 725 indicates that the content is subsequently downloaded by the node that manages the "12. 37. 43. 5-03/02/01-03: 45: 23: 02-MindSpring. com" link library.

Continuing with the <arc> node 735, the value of the resource attribute 750 is the same as the resource attribute 730, and the "from" attribute 740 has the same value as the to attribute 725 of the previous <arc> element 710, thereby indicating that this is a further step to the same content. Traverse. Therefore, the final "to" attribute 750 indicates that the content has been downloaded by the current node. If an application that reads the link library identified at 750 wants to access the content specified at 750, it can be used in the resource collection This is done by the defined <content> XL ink. See label 660, which defines the corresponding <content> element. By matching the value of the resource attribute 750 with the value of the role attribute 670, the <content> is selected from the resource set Element, and then use its href attribute 665 to find the actual location of the content. Therefore, in general, the arc represented by the <arc> element in the traversal path definition will link the library through its resource attribute value and The role attribute value of the <content> element in the resource collection is connected, and the <content> element provides the location of the permanent content resource.

The preferred embodiment of the present invention uses a bootstrapping process, where the bootstrapping process is described as having 7 stages for initializing all nodes on the network during loading (including system nodes during implementation). The flow will now be described with reference to FIG. 8. In the first stage (block 800), the current node resolves its own IP address. Assuming that the node does not have a static IP address, it is preferable to use existing dynamic address allocation technologies (such as dynamic host configuration protocol, namely "DHCP", or automatic IP protocol, etc.) to achieve this goal. (If the node has a static IP address, this stage can be skipped.) As the start of the second stage, a test (block 810) is performed to see if the node already has LBuuid of the form disclosed here. If the result of the test is negative, the LBuuid of the node link library is generated in the second stage (block 820). The negative result is generated when the peer node is started for the first time, and the link library must be initialized at this time. The LBuuid generated at this stage is used as the UUID of the node link library, where LBuuid has the following form:

LBuuid=f (current IP address, current date, current time, a)

03807173.8 Preferably, the "a" parameter is used as an indicator of the IP address provider (for example, its domain name), as described above. Alternatively, "a" may be a parameter used in the prior art UUID, which uses a random number. Any UUID generation algorithm can be used, but in order to allow accountability and tracking as described above, the value generated is preferably to provide the link library to be traced to its owner and thus to trace the content resource to its source (and already The form of the ability to download the content of the peer node).

When the link library is initialized, a set of arcs is created to indicate how the local content of the node traverses the network. (Refer to Figure 7, which discusses some examples.) Once LBuuid is available for the node's link library, the third stage begins to broadcast "live" messages from the node (block 830). The live message announces the node's existence on the network. In the preferred embodiment of the present invention, the live message utilizes SOAP on HTTMU. HTTMU is a UDP-based multicast version of HTTP, and allows live messages to be sent to all nodes on the subnet. The sample live message is finished midway in FIG. 9, in which the (notification) element 905 has a type attribute 910 set to alive (live). According to a preferred embodiment, the live message also specifies the LBuuid value of the node link library (see <1 inkBaselD> at 925) and a reference to the node's own reputation version (see <reputationRef> at 930)_oThe reputation information is displayed in FIG. 9, as provided by a simple link to the document identified by the "href" attribute 935. This attribute value provides the URL where the reputation information of the permanent node is located_OTherefore, the live message informs the peer node how to find the location of the sending node's permanent identifier and its reputation. The live message preferably also contains callback information indicating the callback address of the response message (see callback attribute 920), which provides the current IP address of the node and another attribute 915 that specifies one of the following:

) Inquiry uniform resource indicator ("URI") pointing to the UDDI registry and the binding key value of the file sharing service that can be obtained from the node. Therefore, when using a web service model with a UDDI registry, the live message in this option not only identifies the registry with the Publish and Inquiry Application Program Interface ("AIP") for the service, but also contains the binding to the file service. Set the key value.

2) Certain non-UDDI methods for discovering node file sharing services, such as Web Service Inspection Language ("WSIL") references. WSIL is a preconceived idea designed for the following purposes: to assist in viewing sites to find available services and to specify a set of rules that indicate how viewing-related information should be made available. WSIL is defined by IBM and Microsoft, and combines the concepts seen in the early development of IBM called "ADS" and Microsoft called "DISCO". (For more information about WSIL, see Keith Ballinger et al. Web Services Inspection Language (WS-Inspection) 1.0, (November 2001), published by IBM on the Internet

03807173.8 No. http://www-106. ibm. com/developerworks /1 ibrary/ws-wsi 1 spec, html ).

In the example of FIG. 9, the second option has been selected, so the attribute 915 is the "wsil" attribute, which specifies the URL in which the WSIL information is stored.

Continuing to the fourth stage (represented by block 840), the node listens for SOAP on the HTTP response to be sent by the peer who received the live message sent at block 830. According to a preferred embodiment, the response message from each of these remote nodes is also a live message, and specifies the LBuuid of the remote peer and the URL that identifies where to find the reputation information of the remote node's self-management_OAs mentioned above, the reputation of a node contains a status value, which indicates how successfully the node processes the query. (As discussed with reference to Figures 4A and 4B, the status value can represent the query of all nodes, or can provide query-specific values.) If the local (receiving) node has its own version of the reputation of the remote node, it is better to combine these two Reputation is merged to be stored in a local library (such as a memory-resident table) created by the local node to represent the remote node it knows about (that is, the remote node in its resource collection). According to a preferred embodiment, when the remote node's local node view is different from the remote node's view of its own reputation, the merge operation includes copying the remote node's input on the local node information. (This may be appropriate when the local node is not on the network for a period of time, and the remote node is updated during this period; or the local node may have missed some propagation of the remote nodes activity for some reason, thus making the local The node is lagging in its knowledge of the remote node.) However, if the local node identifies the remote node as malicious, then (under normal circumstances) it is better for the local node to ignore the incoming remote nodes view of its reputation. ). Without departing from the scope of the present invention, other techniques can be used to derive the local reputation value for a remote node, such as averaging the local view with the remote node view, or extrapolating (for example, integrating the local node's knowledge about another node's interaction And what I don't know).

When a system-level gossip spreader is defined and has permission to inject reputation information into the library maintained by a peer node, the local gossip spreader may cover its attempts to the remote node's reputation by the system-level gossip spreader.

In the fifth stage (represented by block 850), the local node sends out what is referred to herein as a "spy" message. Preferably, the spy message is sent directly to all peers that have responded (at block 840) the local node to initiate a "live" request, and the spy message actually requests each peer to send the live request to the pair. Every node on the network known to others, spread. Then, multi-master peers (that is, peers that support multiple network connections) can forward the live request to peers outside the current subnet. Then, these peer nodes will respond with their own live response messages, so that the local node can dynamically understand the topology of the P2P network. The information collected from the returned live messages is used to establish

03807173.8 p.

LBuuid to URL mapping (in the local resource collection), thereby enabling the node to resolve the identifier of its peer node.

Note that spying messages are considered optional, and the depth of propagation of spying messages is best determined by the requesting application. Spying messages can have an optional depth attribute, which determines the maximum number of sequential forwarding. It is better to provide the UUID of the spy message to avoid triggering the infinite loop recursive processing of the spy message.

Figure 10 shows how to implement a sample spy message 1005 in a SOAP message 1000. In this example, the "UUID" attribute 1010 is specified to prevent recursive forwarding. (The "[LBuuid]" syntax in this example is replaced by the actual LBuuid of the local node.) Returning to the discussion of Figure 8, in the sixth stage (represented by block 860), the local node uses what it receives as its own live A live message in response to a message (and when a spy message is implemented, as a response to its spy message) to update its memory-resident entry that maps the network endpoint to the remote node link library ID. The collection of these items contains the <node> element in the local link library resource collection, as shown in the example in Figure 6. The update process includes updating the URL as required, so that the memory resident table identifies the current location of the node related to each LBuuid. (Note that because the resource collection is an XML document, and the document is best stored using the Document Object Model or the DOM tree, adding new items corresponds to creating a new DOM tree node. In this field, building DOM from XML language elements The technology of tree nodes is well known.) The node can also update locally stored reputation information about remote nodes that return live messages in response to spying messages. See the discussion of block 840, where this reputation update is described for the node responding to the node's own live message.

Finally, in the seventh stage (block 870), the local node listens to live messages from other peer nodes and sends a live message as a response (similar to the live response message described in block 840). The monitoring process is preferably continuous, so that the node can maintain the knowledge of its peers on the P2P network, and can update its resource collection accordingly (the resource collection caches the relationship between LBuuid and URL) and Peer reputation information stored locally.

Figure 11 provides a flowchart showing the flow that a node can use when requesting content from its peers. The process begins at block 1100, where the user defines the query of interest. The query is best expressed as a query string, which can be input by the user, selected by the user from a menu, read from a file designated by the user, and so on. The general user is a human user, but alternatively, the program process can also determine the query and provide the query string. For example, in order to request the purchase order of customer 1234-567-890, as before

03807173.8 As shown in the example above, the format of the query string can be purchase-order 1234-4567-890. At block 1110, it is better to perform an optimization process, and the node therefore evaluates the reputation of its peer node to analyze what is referred to here as the "broadcast layer". These broadcast layers specify a hierarchical method for query analysis, and select peer nodes on each layer according to what they see and their ability to satisfy the query. This classification method attempts to reduce the number of query requests and response messages traversing the network. Preferably, by using the <QuerySet> in the reputation of each node, a pattern matching method is used to determine which node can respond to a specific query. Refer to Figures 4A and 4B. For example, if a particular node cannot respond to the purchase-order 1234-4567-890 represented by the syntax at 420⁵⁵In the query mode, it is inefficient to send this form of query to the specific node. Instead, the node whose reputation indicates that it supports the query and has a relatively high status value is selected as the first broadcast layer.

As an optional improvement of the pattern matching operation, you can use the site and summary. "Site summary" refers to the use of content syndication technology provided by RDF, and is called "RSS" in the art. A site summary can include a collection of content descriptions, which describe the content/services available from a specific site (ie, a collection of queries on the site). When the description set changes (for example, to add new site content), you can use RSS to push the description to the content syndicator in advance. The nodes initially learn about each other's reputation through live news, as described above. As nodes participate in interactions with other nodes, their reputation (including their status and possibly their query set) generally changes. It is possible that some nodes do not interact with other nodes often, thus making these nodes' views of mutual reputations obsolete. Therefore, site summary can be advantageously used to regularly disseminate reputation information among the nodes of the network.

In block 1120, a request is sent to the identified "priority provider". Preferably, a directional "broadcast" method (in HTTP _L) is used to send the query, where the result set is used to determine the current IP address of each target node. (If the broadcast layer is not used, the target of the query message can be determined in another way, including sending a message to all peers represented in the resource collection.) A sample query implemented with SOAP message 1200 is illustrated in Figure 12 . As shown in this example, the <query> tag 1205 is represented by the text string of the query as its value 1210, in which the account of interest («123-4567-890) has been provided as the input parameter value. (Note that the query will be interpreted by the receiving node as some kind of probe, through which the probe will query these nodes to determine whether they really support the query, and the current status of their claimed response to the query. The message sent at 1120 is not The actual content request.) If no satisfactory response is received from any node in the first layer (ie, none of the queried peers can respond to the query with an acceptable status), then control returns to block 1110, among them

03807173.8 First find the second layer consisting of the next set of best peers. (Preferably, a configurable time interval can be used to limit the time spent waiting for a response from the queried peer.) The second layer preferably contains pairs that also support the query but have a lower status than the first layer Etc. Then, the request is sent again at block 1120.

This process of sending query requests to peers at all levels will continue until all non-malicious peer nodes have been queried or a satisfactory response to the query request has been received. Then, control reaches block 1130.

Note that in some cases, it may be better to eventually send a query request to a node that does not indicate that it supports the query: due to the temporary nature of the network, the local node generally does not always know about the reputation of all its peers (including Its query collection) latest information. Therefore, a peer node that can respond well to the requested query can be found, even if the local node's information does not show that the node is a better candidate.

Returning to FIG. 11 again, assuming that one or more responses of the queried peer do support the query, in block 1130, the local rumor propagator processor processes the metadata from the responding node. That is, the response message from the remote peer will contain metadata describing the content that can best satisfy the request in the content library of the remote node, and the information from the response message is preferably cached locally for processing in block 1140. Refer to the sample SOAP response message 1300 in FIG. 13, where the <content-meta-data> tag 1305 of the SOAP header provides a simple XL i nk element pointing to the location of the content metadata. In this example, the value of the "href" attribute 1310 indicates that the identifier is embedded here^t£purchase_order_ 123-4567-890. The rdf information is used as the first child of the <querResponse> element (see the xpointer syntax at 1315). The <querResponse> element is displayed at 1320, which contains the RDF specification of the content metadata from the response node (see 1325). As shown in this example, the responder indicates the name of the document it will return (see the about attribute value at 1330); the content creator information containing the date and time of creation and the creator's name (see <Creator> element 1135) ; And an overview of the well-known document (see <synopsis> element 1340).

The user then evaluates the content metadata from a set of response nodes. As mentioned above, the user evaluation can be performed by a person or by a program process. When the user is a human, it is better to display the value of the <synopsis> element 1340 on the graphical user interface panel, and other values from the <Description> element 1325 can be displayed if desired. After analyzing the content metadata, the user identifies his/her/its preference for which peer or which peers are most able to satisfy the query, and then issues an action

03807173.8 The content request of the SOAP POST request (block 1140).

Figure 14 provides a sample SOAP POST request 1400 used to transfer content requests according to the preferred embodiment. In this example, the SOAP shell contains a <getContent> element 1405, which has the user content request text as its "ID" attribute 1410 value (which is sent in the query request message of FIG. 12). Alternatively, the value received in the "about" attribute 1330 of the response message may be used as the value of the "ID" attribute 1410.

Preferably, the peer node returns the requested content encoded as a SOAP response message, the response message having a Multipurpose Internet Mail Extension ("MIME") structure. Upon receiving the requested content, the receiving node processes the content (block 1160). The description of the specification published by W3C titled "SOAP Messages with Attachments, W3C Note (December 21, 2000)" (see http: //www. w3. org/TR /2000/NOTE-SOAP-attachments-20001211) A standard method of associating SOAP messages with one or more attachments in native format using a multi-part MIMI structure for transporting attachments. An example of this SOAP response message is shown at 1500 in FIG. 15, where the response to the content request specified in the MIME attachment is represented by reference numeral 1520. According to a preferred embodiment, the SOAP response also has a header indicating that the content has traversed the path since entering the peer-to-peer network (see 1505), and the remote node that satisfies the request preferably also provides a URL that identifies its own representation of its own reputation (See 1510).

The processing at block 1150 includes extracting the traversal path and remote reputation information (after first decrypting the message with a decryption processor if necessary).

Then, the digital signature processor verifies all digital signatures on the message (block 1160). If the identity verification of the sender fails, or the message integrity check fails, the reputation of the peer will be adversely affected, and the reputation claimed by the peer node will best be ignored. (Alternatively, in certain implementations, it may be desirable in this case to reduce the local version of the reputation for the node.) Update the locally maintained reputation for all peer nodes that are sent to the content request 1400 (block 1170) to reflect its success rate in satisfying the query. Preferably, this involves adding the value of the "totalQueries attribute" and incrementing or not incrementing the success count value suitable for the particular responder, and then recalculating the status. In a preferred embodiment, the status is calculated by dividing the success count value by the totalQueries value The updated values are then stored locally. In alternative implementations, the status can be calculated in other ways.

In block 1180, assuming that the peer has successfully verified the identity, the traversal path message (refer to the number 1505 of document 1500 in FIG. 15) obtained from the response message of the node will be stored locally,

03807173.8 First and associated with newly received content. (See, for example, the <content> element 660 in the resource set 600 in FIG. 6.) In addition, the traversal path will be expanded to include the current node as the latest target node in the directed graph (ie, by creating the location at 735 in FIG. The new <8"> element in the display format).

Finally, the received content is presented to the application (block 1190), and then the application processes the content in an application-specific way. Then, the requester flow of the content request in FIG. 11 is ended in this way.

Note that as an optional extension of the processing shown in FIG. 11, the user can provide feedback on whether the content finally meets his/her/its request, and this feedback may affect the status of the provider node.

Turning now to Figure 16, a preferred embodiment of the provider process used by the (remote) peer node to evaluate and respond to content requests is described. The process starts at block 1600, where the peer node receives the query and extracts the query string from the received query.

In block 1610, the peer node performs pattern matching to match the extracted query string with its own content metadata to determine whether it can respond to the query. (Refer to Figures 4A and 4B, where the sample <QuerySet> element identifies the query that a specific node can support.) Note that specific embodiments of the present invention can use site overviews to speed up the pattern matching process, as described above for identifying the target node of the query message .

If the peer node can perform the requested query, it creates a SOAP response message in the form described above for block 1130 (which describes that the requesting node receives a response from a potential content provider), and returns the message to the requester (block 1620) . As described above, the response message contains a SOAP shell with an RDF message that includes metadata describing the content provided by the peer node that satisfies the query request.

It should also be noted that in some cases, the response message sent by block 1620 may contain multiple RDF messages. This can happen when a particular node can support queries in more than one way. In addition, the query request specified using the SOAP header 1200 (as sent as described for block 1120) may contain more than one query pattern (for example, formatted as more than one <query> tag 1205). In this case, the response may also contain multiple RDF messages.

After sending the response message, the provider node listens for incoming content requests from the requester node (block 1630). Unlike the message received in block 1610 can you support this query", the content request waiting is a "please perform this query" request. According to the preferred embodiment, the node will monitor incoming content at a configured time interval Request. If the time interval has passed without receiving the waiting request, it is considered that the processing of the content request is complete, and therefore the control is shown as returning to block 1600 to wait for the next "Can you support this query" request message .(As you will see below, the most

03807173.8 It is better to use a separate thread so that the node continuously monitors incoming requests. ) Otherwise, if the waiting "please make this inquiry" request message is received, the process goes from block 1630 to block 1640.

Block 1640 initiates the processing of the requested query and formats the result as a SOAP response message using a multi-part MIME attachment (as described above for Figure 15).

In block 1650, the provider node's path declarator appends a reference to the content traversal path in front as the SOAP header of the outbound message. Referring to FIG. 15, the SOAP header 1505 provides traversal path definition information, as shown in FIG. 3A. (As described above, the <traversalPathRef> tag 305 in the header document 300 provides a reference 310 to a collection of links storing the specified content traversal path in the peer-to-peer network.) The present invention also updates the locally stored content traversal path definition ( For example, it is appropriately forwarded by the node with a specific date and time value).

Then, the rumor spreader of the provider node updates the local reputation of the node (block 1660), stores the updated information, and includes the reputation information in the SOAP header of the outbound message. (Refer to Figure 15 again, where the SOAP header 1510 contains the version of the reputation of the responding node, as shown in Figure 3B.) When updating its reputation, if it has not been received after the stated time interval, please perform this query" request , The provider node should count the interaction as a failure that cannot satisfy the content request. Otherwise, the provider node should count the interaction as a success. Considering the success or failure result, recalculate the stature attribute, as above As described in block 1170 of Figure 11. (Note that as a result of the negative result in block 1630, failure processing will be performed) Then, the digital signature processor digitally signs the generated response message (including the SOAP header and attachment) (Block 1670), and then return the response message to the requester.

Figures 17A-17C show sample headers that can be used for the optional system management functions already described here. Preferably, an additional AXIS processor is provided in the node to be managed, and one or more nodes with management "authorization" transmit management information processed by the AXIS processor of the receiving node. Because there is no centralized management node in the preferred embodiment of the present invention, the nodes that can be used as management nodes (for example, directing other peer nodes in a certain way) are preferably nodes that have a relatively high level of reputation, ο Due to the evolutionary trust model disclosed here, any node may obtain a management status and therefore act as a system node. Therefore, if necessary, system management functions can be deployed on any node or multiple nodes on the network. The management code in the system node is preferably approved by a certificate authority, so that other nodes can trust the messages sent by the code: the digital signature on these messages allows the management processor in the receiving node to verify the source of the message.

03807173.8 In the preferred embodiment, the management processor supports two new header types, referred to herein as "peek" and "visit". The peek header can be used to inform the node that its network flow will be monitored by the system node. The access node can be used to read or write the link library, reputation library, or content library of the node.

Figure 17A provides an example of a peek header. The system node sends a peek message to notify the management processor of the receiving node to copy the SOAP message using the specified system code. Therefore, the header shown as element 1700 is a simple XLink, which specifies an address 1710 that identifies the sender of the message (ie, the system node). The receiving node then uses this address to copy its SOAP traffic. Optionally, attributes can be specified in the <peek> element to inform the receiver of the type of SOAP message to be copied. By default, it is best to copy all SOAP messages.

Figures 17B and 17C show access commands. The access command can be used to access the system resources of the receiving node, as described above. Through the corresponding value on the command attribute, the command format can be specified as a write operation or a read operation. In the example <access> header 1730 in FIG. 17B showing a write operation, the system node instructs the management processor at the receiving node to provide new reputation information in the encapsulated reputation reference 1750. The management processor can then forward the information to the rumor spreader processor in the same location. In this example, the reputation reference 1750 identifies the location of the reputation database where the claimed reputation information can be found. The receiving node can choose to retrieve a copy of the reputation for local storage; or the receiving node can choose to store the link, and when the information is needed, access the reputation from the library. Alternatively, the following grammatical form (not shown) can be used: through this grammatical form, the reputation itself is encapsulated in the header (with the LBuuid identifying the peer node, its claimed status, and optionally its query set attributes) . The href attribute 1740 provides the address of the system node, thereby allowing the receiving node to identify the sender of the header.

In the example <access> header 1760 of Figure 17C showing the read operation, the command provides the TinkBaseURI" attribute 1780 to identify the link library that the system node is trying to access. In this example, the value of this attribute uses the xpointer concept, To indicate that the <content> element will be located within the <ResourceSet> document, where the sample document is stored at http://9. 56. 34. 12/linkbase/lb. xml. Alternatively, it can be used in the access command To access the attributes of the reputation library or content library. The href attribute 1740 provides the address of the system node, thereby allowing the receiving node to identify the sender of the header and return the requested information for the read command.

Preferably, the receiving node determines the status of the system node in the process of verifying the sender, so as to determine whether the sending system node has earned enough trust to perform the management function. Preferably, the digital signature added by the management processor is also verified to ensure that the header message comes from the corresponding system node. Optionally, then

03807173.8 The receiving node can issue an identity verification command (challenge) to the sender to verify the identity of the sender; this can be facilitated by using the "href" attribute that identifies the sending system node, as shown in the example in Figure 17A-17C .

Referring now to Figure 18, it shows the management process that can be implemented by system nodes for system management functions (such as monitoring and managing peer communities). At block 1800, the system node initiates a peek operation; preferably, a peek header is sent to the node when it joins the network (this can be detected by sending it a "live" message, as described above for Figure 8).

Once the peer node starts to replicate its SOAP flow, the system node will monitor the network flow (block 1810). Specifically, it is best for system nodes to monitor all transmissions of reputation and content. Therefore, the system node can observe what various peer nodes are claiming their reputation, and can also observe whether the content from a particular node is being accepted as if it constitutes a successful interaction.

At block 1820, the system nodes are displayed as evaluating the monitored network flow to detect security events. Preferably, when false reputation information is declared and when contaminated content is spread, the system node triggers a security event. For example, if a node claims that it has a high positive status value, but the system node observes that many peers reject content from the node, the system node can conclude that the claimed node is a malicious node. Similarly, system nodes can detect peer nodes that reject specific content, and can conclude that the content is contaminated; in this case, it is best to trigger a security event.

When the detected security event contains a false reputation (see block 1830), the management process at the system node will go to block 1840, where the system node issues an access command to access the reputation of the node (it is better to use a write operation to The receiving node imposes a view of the reputation of the system node.) Note that the system node can notify the node of its own reputation, or the reputation of another peer node. A reserved area can be provided in the reputation database (where the reserved area cannot be covered by malicious nodes), and then the write operation can cause information to be written to the reserved area. It can prevent malicious nodes from writing to the area in the library in order to falsely establish a higher status value. When a node subsequently accesses the reputation database, it is best to interpret the information stored in the reserved area as superior to other data about the same reputation. Alternatively, if the reserved area is not used, the information sent by the system node in the access header will be written into the non-reserved storage area.

(Note that peer nodes can also send reputation information to each other, as described above, either in the form of reputation references, or in the form of messages containing reputation information.) The test at block 1850 determines whether the security incident is related to contamination content. If so, the process reaches block 1860, where the system node sends an access command to declare that the content stored by the node is tainted (for example, access and overwrite link library data to modify the traversal path). Link library can also

03807173.8 The first use reserved area, the system node can write path traversal information into the reserved area.

In a specific implementation, if necessary, the system node may also be allowed to issue a command to overwrite the content of the node and locally stored, as described above for using other attributes on the access header. The processing of access commands affecting the content library can be performed in a manner similar to the commands affecting reputation and content traversal paths described above.

Once the security event processing is completed, control returns to block 1810 to continue monitoring the network flow of the peer node. (As you will see later, the security processing is best performed by a separate thread so that monitoring is not interrupted.) Although the monitoring function has been described for security, the implementation of the present invention can collect information from monitoring peer-to-peer network flows Used for other purposes. Examples of other uses include failover and high availability scenarios. In a failover scenario, for example, an access command can be used to replace the reference to the failed node with the reference to the standby node, or perhaps to delete the reference to the failed node. These changes can be made in the following ways: identifying the faulty node in the resource collection, and replacing or deleting the item that references the node's LBuuid. In the high availability plan, when the system node detects that a particular node is overloaded or the resources of other nodes are underutilized, the access command can be used to modify the link library reference to the content (or service), so that the network flow can be redirected to alternative locations. Different nodes to obtain the content (or service).

As described above, the technology disclosed herein provides a framework for a managed peer-to-peer network, and makes it possible to maintain peer-to-peer relationships across call locations, and reuse these relationships and identities that form temporary communities. As mentioned above, peer nodes can enter and leave the network as they wish, and the technology disclosed here enables it to provide security, management, and other system-level functions in front of these transient communities. The disclosed technology enables the P2P network to enable transient communities to be managed, and allows the exchange of secure transactions in the transient communities in which message integrity can be ensured.

Microsofts Hadingstorm (also known as .Net My Services") project is portrayed as P2P technology. But the P2P support seems to be limited to instant messaging. Other existing P2P networking technologies, such as the previously discussed JXTA, are not Support the functions disclosed here for the transient community.

Those skilled in the art should understand that the embodiments of the present invention may be provided as methods, systems, or computer program products. Correspondingly, the present invention may adopt all hardware implementations, all software implementations, or a combination of software and hardware implementations. In addition, the present invention may take the form of a computer program product, which is implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.), and

03807173.8 The first section contains computer-usable program code.

The preferred embodiments have been described with respect to the flowcharts and/or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present invention. It should be understood that each flow and/or flow chart and/or each block of the block diagram and the flow and/or block combination of the flow chart and/or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a general-purpose computer, a processor of a special-purpose computer, an embedded processor, or a programmable data processing device of other manufacturing machines, so that the computer processor or other programmable data processing device executes the The instruction creation implements the means specified in the flowchart or process and/or block diagram or block.

These computer program instructions can also be stored in a computer-readable storage, which can instruct a computer or other programmable data processing device to function in a specific manner, so that the generation of instructions stored in the computer-readable memory is included in the flow chart. Or the process and/or block diagram or the product of the instruction component specified in the block.

The computer program product can also be loaded into a computer or other programmable data processing device to cause a series of operation steps to be executed on the computer or other programmable data processing device to generate a computer-implemented process to make the computer or other programmable data processing device The instructions executed on the programming data processing device provide steps used to implement the functions specified in the flowcharts or procedures and/or block diagrams or blocks.

Although the preferred embodiments of the present invention have been described, those skilled in the art can think of various other changes and modifications to these embodiments after understanding the basic concept of the present invention. Please also note that although the preferred embodiments have been described for a network service environment, the disclosed technology can also be used in other P2P network environments. In addition, although the preferred implementations have been described here for the specific syntax of SOAP messages and message headers, documents, etc., this is only for illustrative purposes and not for limiting purposes. Alternatives can be used without departing from the scope of the present invention. Message format and alternative syntax. In addition, although the transient network is referred to here, it is also possible that the network topology becomes stable over time. Therefore, the term "transient network" can be understood as referring to a network with an architecture that supports the transient topology. Therefore, the claims should be understood to include both the preferred embodiments and all modifications and improvements falling within the scope of the present invention.

03807173.8