Dynamic addressing in transient networks

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 technique

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. Thus, PWP 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 the 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 P2P network does not provide support for secure transactions between transient communication members. (Sun Microsystem'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. In these services there is a set of core services, which include membership , Access rights, and resolver services. The defined method applies the client/server model for authentication, authorization, and naming in the peer group. 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 The Groove(R) product of Networks provides a collection of "shared services" in a peer-to-peer 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 a central website to find MP3 music files, and then download the MP3 music files from each other's 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 P2P systems and their potential for efficient load distribution have been touted as the next revolution in information technology ("IT") architecture. However, because of the above-mentioned restrictions, the existing P2P networks belong to consumers and "free" markets, which are not very suitable for large-volume commerce (such as e-commerce or business-to-business transactions). (As mentioned above, existing P2P implementations are not very 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.

Summary of the invention

The invention provides a method, a system and a computer program product for improving a peer-to-peer computing network. 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 preferably 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 identifier of the domain in which the initial entry occurred .

The permanent node identifier can then be used to track the behavior of each node in the network (for example, how the specific 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.

Description of the drawings

Figure 1 shows the 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 location and interconnection relationships in a networked environment; Figure 3A provides a simple sample The Object Access Protocol ("SOAP") header is used 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 Figures 4A and 4B provide sample extensible markup language ("XML") documents to illustrate the preferred implementation and how alternative implementations specify node reputation as node metadata; Figure 5 provides a sample XML document to illustrate the preferred How to use content metadata to describe content resources in the implementation mode; Figure 6 provides a sample XML document to illustrate how the preferred embodiment specifies a resource collection. According to the preferred embodiment, the resource collection is created to record the relationship between the permanent node identifier and the current network endpoint 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; Figure 8 shows the preferred embodiment from the P2P network The bootstrapping process performed by the node during initialization; Figure 9 provides a sample XML document to illustrate how the preferred embodiment transmits the reputation information in the "alive" notification message sent 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 the node used to locate the content provision according to the preferred embodiment The process of requester or service provider, 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 the figure 13 provides a sample SOAP shell to show how the node can query; Figure 14 provides a sample Hypertext Transfer Protocol ("HTTP") request message, which contains the SOAP shell to illustrate that during the requester process of Figure 11, the preferred The embodiment how to request the sending of content/service from the 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; Figure 16 shows, according to the preferred embodiment, The node is used to respond to the query from the requester, and if selected by the requester, the provider process that responds with the requested content or the result of the requested service; Figures 17A-17C show that it can be used here. The sample header of the disclosed optional system management function; and Figure 18 shows the management process that can be implemented by the system node that provides the optional system management function.

detailed description

The embodiment(s) described below define techniques to improve the operation of the P2P network. 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, permanent content path and context node information 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 outside of 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 operations, including network management, transactions, and the application of security policies.

In addition, the disclosed technology facilitates the provision of a self-healing network. A self-healing network is a network in which the network performs task management/monitoring while it 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 existing P2P networks that need to broadcast queries to the entire subnet, the present invention discloses a hierarchical broadcast technology, which uses the permanent knowledge of nodes in the network to reduce the generated network traffic.

Various peer nodes will coexist in a general 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 Pledge. If the SLA promises are not fulfilled, customer charges may be adversely affected. In a P2P network, nodes that need storage can issue dynamic network queries to find other nodes that provide this capability. 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 of 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, find out 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 a request is received, 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.

Web 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 network access to software for program-to-program operations in these networks. Web services make use of many open web-based standards, such as HTTP, SOAP, and/or XML protocols, Web Services Description Language ("WSDL"), and Universal Description, Discovery, and Integration ("UDDI). HTTP is generally used to communicate via the Internet such as The TCP/IP ("Transmission Control Protocol/Internet Protocol") network exchanges messages. SOAP is an XML-based protocol used to call methods in a distributed environment. The XML protocol is the evolving World Wide Web Consortium ("W3C") The specification is used to design the application layer transfer protocol used to enable 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 registration Table technology, using 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 realized 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, the web service provides the requester 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/NOTES-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/NOTE-wsdl-20010315, titled "Web Services Description Language (WSDL) 1.1, W3C Note (March 15, 2001)". For more WSDL information about UDDI, see http://www.uddi.org/specification.html. Requests from the Internet Engineering Task Force HTTP is described in the comment ("RFC") 2616, titled "Hypertext TransferProtocol-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.

Preferably, a directed graph is used to model operations involved in executing a network service including multiple sub-services using the prior art. For example, see the commonly assigned US patent application (serial number 09/956276, filed September 19, 2001, 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 connecting the graph nodes represent operations from one service to another Possible transfer of 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, 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). The document can be obtained from the IMB or via the Internet at http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf.

Preferably, UDDI messages that access the UDDI registry are used to provide automatic discovery 120 and release 130 of network services (for example, network services available from various nodes in the P2P network). 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, message queue ("MQ"), etc. 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 information from its WSDL 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, nodes in a P2P network can be modeled as categories instead of strict peers. For example, this embodiment describes a "system" node. The term "system node" as used herein refers to the following nodes in a P2P network: the node provides a type of function 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. (See, for example, the discussion of "spy" messages, which 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 implementing 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 about Apache AXIS, see ttp: //xml.apache.org/axis/index.html, which is the Apache Software Foundation's implementation of the SOAP protocol).

"AXIS" is the runtime environment of the SOAP service, in which the web service uses the container model to run. A servlet called a "router" receives an 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 finishes executing, the router serializes the result 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. A "processor" is an executable code that implements a specific function, 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. When a message containing encrypted data is received, 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.

The AXIS engine supports three types of processor chains. One is the transmission chain, which specifies the message transmission mechanism (such as HTTP). The 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.

In the preferred embodiment, three AXIS processors (described in detail below) are used, 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 Used as a means to represent a directed graph that defines a content path that is permanent. XLink language is in "XML Linking Language (XLink) Version 1.0, W3C Recommendation (June 27, 2001)", which can be found from the Internet address http://www.w3.org/TR/xlink/. As known in the art, XLink syntax can be used to define simple, markup Type links (including outbound links pointing to remote resources and inbound links identifying resources linked to local nodes), or more complex "extended" links. (Then the prior art does not know the XLink links disclosed here. ) Extended links are used to represent nodes and the arcs between them. One type of extended link is a "third-party" link. The third-party XLink associates remote resources, which means that the link definition is stored independently of the content linked together Figure 7 described below illustrates how the preferred embodiment of the present invention utilizes XLink to perpetuate 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 here 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 contains a <traversalPathref> tag 305 (in the example of FIG. 3A, the tag is prefixed with a namespace identifier "p", which means "path"), and the <traversalPathref> tag provides information for storage The reference 310 of the traversal path link collection of the specified content in the peer-to-peer 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/linkbase" /lb.xml" access.

Upon receiving the SOAP header with the 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 traverse 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 more information on how traversal paths identify paths between nodes, see Figure 7 below.

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

Referring now to Figures 4A and 4B, the preferred and replacement techniques for designated reputation data are shown. 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 numeric value (called a "status" value) that the specific node responds to other nodes in the network, and the numeric value indicates how well the specific node responds to queries it receives from other nodes in the network success. The quality of service part of the node reputation indicates a malicious node in some cases (for example, a node that has shown a tendency to become a malicious agent or resource source). The ability to associate reputation with dynamic addressing nodes facilitates trust in a decentralized P2P world, and once reputation information is available, a trust model using security policies can be applied to P2P interactions. As a result, the main obstacle to e-commerce in the P2P network is removed. (Note that although the preferred embodiment described here is aimed at dynamically learned reputation, in certain embodiments 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. It is considered to fall within the scope of the present invention. This method can be used to give selected nodes a relatively high status, so as to actually mark these nodes as system nodes.) According to the preferred embodiment, the link library identifier (" ID) or "LBuuid to identify transient nodes in the 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 Figure 4A has LBuuid9.37.43.2-05/04/01-12:02:05:37-Netzero.net which is displayed as <Description> label 405 "about" The value of attribute 410. In this example, the IP address part is "9.37.43.

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 current address of the node (the resource set will be described below with reference to FIG. 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 designated, and the subtag has a "stature" (status) attribute. In a preferred embodiment, the status attribute has a numerical value indicating 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 -1 to +1, where a negative status value indicates a malicious node. Preferably, the corresponding "totalQueries" attribute is also specified, the value of which is an integer representing the total number of queries processed by the node. 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 "ID" attribute is shown, which uses the conventional UUID format to provide the value used to uniquely identify the query set 415.) In an alternative embodiment, the status (ie success rate) information can be independent of The query is related, not the entire collection of queries. An alternative is shown in Figure 4B, in which 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 -1 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 grammar used in the preferred embodiment, the <QuerySet> tag 415 has one or more <Query> child elements, where the <Query> element set lists the queries that can be satisfied by the node Collection (preferably 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 process queries of the form "purchase_order 999-9999-999", 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. (In the example used here, 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 the expression as "partner profile list" "The text string. 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.

Reputation provides remote nodes with hints 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 with this description?". The responding node provides its reputation to notify 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 FIG. 4A) or provide the specific file (using the method of FIG. 4B) Method) how to succeed.

Referring now to FIG. 5, there is shown an example illustrating a preferred technique for specifying content metadata (ie, information about specific content). 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 can 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. Thus, 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 may 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 programmatic 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 a <reputationRef> 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 the reputation metadata is processed 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 W3C's 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 make a query and declare its reputation, traverse path, etc., another "category N" node (such as the system node described here) can 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, the link library according to the preferred embodiment of the present invention Including 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 of FIG. 6 illustrates a collection of resources. The resource collection is defined as a collection of XLink locator links. A set of such links is used to define the mapping between the dynamically assigned network address of each node known to the current node and the permanent LBuuid value. These links are specified as <node> elements. The other group is used to define a link that maps the downloaded content description to the current location of the content in the local content library. These links are specified as <content> elements.

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 current address of the node. The root element of the document storing the resource set is <ResourceSet>, which is defined as an extended XLink (see the "type" attribute at 605.) As shown in Figure 6, the first three elements 610, 630, and 645 are newly resolved definitions The <node> element of the mapping between the network endpoint (ie 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 permanent LBuuid. 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 XLink (see, for example, the "type" attribute at 615), which has an "href" indicating the end of the node network that is maintaining a link library with an ID equal to the "role" attribute value "Attributes. For example, the "href" attribute 620 has the value "http://9.56.34.12/soap/rpcrouter". According to the mapping in the element 615, the URL represents the node that manages the link library with the 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 its value set to "local" attribute), while the other <node> elements 630, 645 are about remote nodes (with its 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_order123-4567-890.xml" currently used to save the local content identified as "purchase_order123-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 XLink elements having a "type" attribute of "arc" (arc). These <arc> attribute values specify the movement of the content from one node to another. The arc XLink element utilizes the role of the resource and locator node. The locator node is defined in the resource collection, as shown in Figure 6, and in Figure 7, the "resource" attribute of the <arc> element is used to identify the resource node. This is described by referring now to the path beginning with the <arc> link 710, which specifies the content identified at 725 as "purchase_order 123-4567-890.xml" (according to element 670 in Figure 6, It is currently stored in the location "file://usr/awes ley/etc/downloads/purchase_order123-4567-890.xml" and it represents the customers purchase order 123-4567-890) is managed by "12.37.43.5-03/03/01-08:35:13:04-MindSpring The node generation of the ".com" link library (see the value of the "from" attribute 720). The value of the "to" attribute 725 indicates that the content is subsequently managed by "12.37.43.5-03/02/01-03:45:23:02 -MindSpring.com" link library node download.

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 This is a further traversal of the same content. 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 do so by using the <content>XLink defined in the resource collection. See reference number 660, where the corresponding <content> element is defined. By matching the value of the "resource" attribute 750 with the value of the "role" attribute 670, the <content> element is selected from the resource collection, and then the "href" attribute 665 is used to find the actual location of the content. Therefore, under normal circumstances, the permanent 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. Connected, where 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 phase (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 the prior art dynamic address allocation technology (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 in the form disclosed herein. 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) Preferably, the "a" parameter is used as the IP address provider The indicator (such as 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 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. A sample live message is completed midway in FIG. 9, where 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 <linkBaseID> at 925) and a reference to the node's own reputation version (see <reputationRef> at 930). The 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 sound information of the permanent node is located. Therefore, 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), where the current IP address of the node is provided and another attribute 915 that specifies one of the following: 1) points to The inquiry uniform resource indicator ("URI") of 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) Some non-UDDI ways of discovering node file sharing services, such as Web Service Inspection Language ("WSIL") references. WSIL is a concept designed for the purpose of assisting viewing sites to find available services and specifying 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 "Web Services Inspection Language (WS-Inspection) 1.0" by Keith Ballinger et al. (November 2001), published by IBM on the Internet at http://www-106.ibm .com/developerworks/library/ws-wsilspec.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. As mentioned above, the reputation of a node contains a status value, which indicates how successful the node is in processing 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 (ie, 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 merging 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 lags in its knowledge of the remote node.) However, if the local node identifies the remote node as malicious, then (under normal circumstances) the local node is better to ignore the incoming remote nodes view of its own 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, fusing 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. Propagate to every node on the network known to others. 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 gathered from the returned live message is used to build the 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 an infinite loop of 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 includes 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 needed, 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 "DOM" tree, adding a new item 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 No. 1234-4567-890, as shown in the previous example, 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 based on 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 specific node cannot respond to the "purchase_order 1234-4567-890" query pattern represented by the syntax at 420, 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 to the pattern matching operation, a site summary can be used. "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 site queries). When the description set changes (for example, to add new site content), RSS can be used 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, the query is sent using a directed "broadcast" method (on HTTP), 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 number 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 a 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, 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 The latest information of its query collection). 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, at 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, in which the <content-meta-data> tag 1305 of the SOAP header provides a simple XLink element pointing to the location of the content metadata. In this example, the value of the "href" attribute 1310 indicates that the information identified as "purchase_order-123-4567-890.rdf" is embedded here as the first child of the <querResponse> element (see xpointer syntax at 1315) . At 1320, the <querResponse> element is displayed, 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 including the creation date and time and the creator's name (see <Creator> Element 1135); and an overview about the famous 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 peers can best satisfy the query, and then issues a content request as a SOAP POST request (block 1140).

Figure 14 provides a sample SOAP POST request 1400 used to deliver content requests in accordance with the preferred embodiment. In this example, the SOAP shell contains the <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 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) describes A standard method of associating SOAP messages with one or more native format attachments using the multi-part MIMI structure for transporting attachments. An example of the 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 reputation (See 1510).

The processing performed at block 1150 includes extracting the traversal path and remote reputation information (after first decrypting the message using 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 includes increasing 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. Then store these updated values locally. In alternative embodiments, the status can be calculated in other ways.

In block 1180, assuming that the peer has successfully verified the identity, the traversal path message obtained from the node's response message (refer to the number 1505 of document 1500 in FIG. 15) will be stored locally and be related to the newly received content. Associated. (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 (that is, by creating The new <arc> element of the 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 begins 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 Narrated.

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 (e.g., 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 "can you support this query" message received in block 1610, the content request waiting is a "please perform this query" request. According to a preferred embodiment, the node will monitor incoming content requests at a configured time interval. 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 to return to block 1600 to wait for the next "can you support this query" request message. (As you will see below, it is best to use a separate thread so that the node continuously monitors incoming requests.) Otherwise, if the waiting "please make this query" 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 into 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 node's local reputation (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 the time interval has passed without receiving the "please make this query" Request, the provider node preferably counts the interaction as a failure to satisfy the content request. Otherwise, it is better for the provider node to count the interaction as a success. Considering the success or failure result, the "stature" attribute is recalculated, as described above for block 1170 of FIG. 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 SOAP header and attachment) (block 1670), and then sends it to the requester Return the response message.

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 reputation with a relatively high status level.

Due to the evolutionary trust model disclosed here, any node may obtain 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.

In a 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 the 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 packaged 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: by 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, allowing the receiving node to identify the sender of the header.

In the example <access> header 1760 of FIG. 17C showing a read operation, the command provides a "linkBaseURI" 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 concept of xpointer to indicate that the <content> element will be located within the <ResourceSet> document, where the sample document is stored in "http://9.56.34.12/linkbase/lb.xml ". Alternatively, an attribute for accessing the reputation library or content library may be provided on the access command. 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, the receiving node can issue a 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 Figures 17A-17C Shown.

Referring now to FIG. 18, a management process that can be implemented by system nodes is shown to perform 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 node is displayed as evaluating the monitored network flow to detect security events. Preferably, when declaring false reputation information and when disseminating contaminated content, 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 best 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 (wherein the reserved area cannot be covered by malicious nodes) can be provided in the reputation database, 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). The link library can also use a reserved area, and 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 stored locally on the node, as described above for using other attributes on the access header. The processing of the access commands affecting the content library can be performed in a manner similar to the commands affecting the reputation and the content traversal path 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 be used to monitor the information collected from the peer-to-peer node network flow. For other purposes. Examples of other uses include failover and high availability scenarios. In a failover scenario, for example, the 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 an alternative 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.

MicroSoft's Hailstorm (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, do not support the functions disclosed here for transient communities.

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 which contains computer-usable storage media. 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.