KR20150116392A - Service discovery using collection synchronization with exact names - Google Patents

Abstract

One embodiment provides a system that facilitates service discovery based on the synchronization of manifests between devices in a content centric network by using a synchronization protocol based on exact match names. During operation, a local device receives an advertisement corresponding to a remote manifest of a remote device. A manifest represents a collection of service records, and the advertisement includes a service record corresponding to the remote device. The local device updates its local manifest, in response to determining that the local manifest and the remote manifest correspond to a same namespace, by inserting the advertised service record into the local manifest.

Description

{SERVICE DISCOVERY USING COLLECTION SYNCHRONIZATION WITH EXACT NAMES}

This disclosure generally relates to data synchronization. More particularly, this disclosure relates to service discovery that performs synchronization of collections between peers on a network using an exact match name.

In many computing applications, it is sometimes important for peers on the network to synchronize their respective data collections. The proliferation of digital content creates an enormous amount of collection that requires coordination. A content-based network (CCN) architecture is designed to facilitate access to and processing of such digital content. The CCN includes nodes such as entities or network clients, forwarders (e.g., routers) and content producers, which transmit "INTERRESS" packets for various content items and receive do. The CCN interleaves and content objects are identified based on a unique name, which is typically a hierarchically structured variable length identifier (HSVLI) that includes adjacent name components aligned to the most specific level at the most general level.

The current CCN synchronization protocol uses the longest-prefix matching method, where the inter- ests in "/ parc / events /" are matched to "parc / events / calendar.txt" and "parc / events / conference.txt" something to do. This current synchronization protocol is based on a response that extends the name of the inter- est. This synchronization protocol is described in the following applications: U.S. Patent Application No. 13 / 720,736, entitled "DYNAMIC ROUTING PROTOCOLS USING DATABASE SYNCHRONIZATION ", filed on December 19, 2012 by inventors Van L. Jacobson and Marc E. Mosko (Attorney Docket No. PARC-20111397-US-NP) (hereinafter "US Patent Application 13 / 720,736"); And U.S. Patent Application No. 13 / 681,306 (Attorney Docket No. PARC-20111317-US) entitled " DATA TRANSPORT BY NAMED CONTENT SYNCHRONIZATION ", inventors Van L. Jacobson and Marc E. Mosko, filed on November 19, -NP) (hereinafter "U.S. Patent Application 13 / 681,306").

As the CCN architecture evolves, there is a need to discover devices and services provided by these devices based on a synchronization protocol that allows the use of precise name matching rather than the current longest-prefix matching. In this new architecture, the current CCN synchronization protocol will not work.

One embodiment provides a system that facilitates service discovery based on synchronization of a manifest between devices in a content-centric network by using a synchronization protocol based on an exact match name. During operation, the local device receives an advertisement corresponding to a remote manifest of the remote device. The manifest represents a collection of service records, and the advertisement includes a service record corresponding to the remote device. The local device updates its local manifest by inserting the advertised service record into the local manifest in response to the determination that the local manifest and the remote manifest correspond to the same namespace.

In some embodiments, the local device sends a query for an advertisement corresponding to the remote manifest of the remote device.

In some embodiments, the local device transmits an advertisement corresponding to a local manifest of the local device, and the advertisement includes a service record corresponding to the local device.

In some embodiments, the local device receives a query for an advertisement corresponding to a local manifest from a remote device, and the advertisement includes a service record corresponding to the local device.

In some embodiments, the packet transmitted or received by the local device includes a prefix that can be routed identifying the manifest, an identifier that determines that the packet corresponds to a transport of data, a determination that the packet corresponds to an advertisement of data The root hash value of the manifest, the name of the service record in the manifest, and the service record.

In some embodiments, in response to determining that the serial number of the service record of the advertisement is greater than the serial number of the service record in the local manifest having the same name as the service record of the advertisement, And updates the value of the record with the value of the service record of the advertisement.

In some embodiments, the local device initializes on a network, without a manifest. The local device generates a service record corresponding to the local device and generates a manifest for the local device containing the service record.

In some embodiments, the local device sends a request for a remote manifest in response to determining that the root hash value of the local manifest is different from the root hash value of the advertised remote manifest, wherein the root hash value is a manifest Identify the service record. Based on the received remote manifest, the local device determines which service record represented in the remote manifest differs from the service record represented in the local manifest. The local device transmits a set of interleaves for different service records.

In some embodiments, in response to the occurrence of a time to live (TTL) of a service record in the local manifest, the local device updates the local manifest by deleting the expired service record from the local manifest. The local device sends an advertisement corresponding to the updated local manifest.

1 illustrates a system that facilitates synchronization of a manifest between nodes in a content-centric network, in accordance with an embodiment of the present invention.
2 illustrates communication between a local node and a remote node, in accordance with an embodiment of the present invention.
3 is a flow chart illustrating a method for synchronizing content associated with a remote manifest and a local manifest according to an embodiment of the present invention.
4 is a flow diagram illustrating a method for synchronizing content associated with a remote manifest and a local manifest based on a modified time, in accordance with an embodiment of the present invention.
5 is a flow diagram illustrating a method for transmitting an advertisement corresponding to a manifest, in accordance with an embodiment of the present invention.
6A is a table showing a format of a manifest and a content object represented in a collection according to an embodiment of the present invention.
6B is a table depicting the format of two manifests during synchronization, in which a local manifest is missing a content object from a remote manifest, in accordance with an embodiment of the present invention.
6C is a flow diagram illustrating the formatting of two manifests during synchronization, where the digest of a content object of the same name in the local manifest is different from the digest in the remote manifest, and the remote node advertises its manifest, in accordance with an embodiment of the present invention. Table.
FIG. 6D is a diagram illustrating a format of two manifests during synchronization, in which a digest of a content object of the same name in a local manifest is different from a digest in a remote manifest, and a local node advertises its manifest, in accordance with an embodiment of the present invention Table.
6E is a table depicting the format of two manifests during synchronization, where the digest of a content object of the same name in the local manifest is different from the digest in the remote manifest, in accordance with an embodiment of the present invention.
Figure 7 illustrates a computer system that facilitates service discovery based on synchronization of manifests between devices in a content-centric network, in accordance with an embodiment of the invention.
Figure 8 shows communication between two devices, in accordance with an embodiment of the present invention.
9A and 9B are flowcharts illustrating a method for facilitating service discovery based on synchronization of manifests of two devices in a network, in accordance with an embodiment of the invention.
Figure 10A shows a table depicting the format of a manifest and service record represented in a collection, according to an embodiment of the present invention.
Figure 10B shows a table depicting the format of two manifests during service discovery using a synchronization protocol, where the local device does not need to retrieve the remote manifest, in accordance with an embodiment of the present invention.
Figure 10C shows a table depicting the format of two manifests during service discovery using a synchronization protocol, in which a local device receives an updated service record from a remote device, in accordance with an embodiment of the present invention.
Figure 10D shows a table depicting the format of two manifests during service discovery using a synchronization protocol, in which a local device initiates, performs service discovery, and retrieves a remote manifest, in accordance with an embodiment of the present invention.
Figure 11 shows a computer communication system that facilitates service discovery based on synchronization of manifests between devices in a content-centric network, in accordance with an embodiment of the present invention.
In the drawings, like reference numerals refer to like elements of the same features.

The following description is presented to enable one of ordinary skill in the art to make and use the embodiments, and is provided in the context of specific applications and requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art to which the invention pertains and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit or scope of the disclosure. Accordingly, the present invention is not limited to the embodiments described herein but is to be accorded the widest scope consistent with the principles and features disclosed herein.

Embodiments of the present invention provide a system that facilitates devices in a content-centric network (CCN) and service discovery provided by these devices, based on synchronization of manifests between nodes on the network by using exact match names . In the following description of embodiments of the present invention, the associated CCN entity is a local node and a remote node, although roles can be reversed. In some embodiments, the associated CCN entity is a device at the local node ("local device") and a device at the remote node ("remote device"). Each local and remote node or device is associated with a manifest, which represents a collection of content objects at the node. The manifest is identified by a specific prefix and the two manifests with the same prefix correspond to the same collection of content objects.

In some embodiments, the manifest is an ordered list that identifies the content objects. Each content object in the collection is identified by its name and corresponding digest, and the digest is a hash value of the content object. In some embodiments, each content object is also identified by a change time that indicates the time at which the content was changed. For purposes of this description, the manifest is described as an ordered list, but other embodiments include a structured manifest as a synchronization tree, which includes content objects as well as an inherent collection of content objects. The system generates a root hash value for the manifest. The root hash value is an additional hash value based on the hash value of the individual content objects in the collection. The root hash value of the manifest is the unique identifier for the manifest.

The system synchronizes the collection in the local manifest with the content in the local manifest using the correct match name. The remote node advertises a hash of its manifest. The local node receives the advertisement and determines if the advertised remote manifest corresponds to a local manifest, where the remote manifest and the local manifest correspond to the same collection of content objects. The local node compares the root hash value of the local manifest with the root hash value of the remote manifest to determine whether the content of the local manifest is synchronous with the content of the remote manifest. If they do not match, the local node retrieves the remote manifest by sending a request to the remote manifest to the remote node. In some embodiments, the local node transmits a set of intercepts based on a chunking protocol, with each intercept corresponding to a numbered chunk of the manifest. In some embodiments, the remote node may advertise the number of chunks corresponding to the manifest. The local node, which owns the remote manifest, determines which content object indicated in the remote manifest is different from the indicated content object in the local manifest. In succession, the local node transmits a set of interleaves for different content objects, wherein the interleaves include the name of the requested content object. In some embodiments, the interrest also includes a corresponding hash value of the requested content object. In this way, the system receives a different set of content objects using the exact name matching the request.

In some embodiments, the manifest is transmitted using a structured technique, such as a rolling hash technique in the rsync protocol, rather than sending a complete manifest.

In some embodiments, the content object in the collection is further identified with a corresponding modified time, indicating the time at which the content object was changed. For each content object determined to be different, the local node determines whether the modified time of the content object in the remote manifest is more recent or less recent than the corresponding content object in the local manifest. If the remote content object corresponds to a more recent version, the local node updates the value of the content object in the local manifest with the value of the content object from the remote manifest. A description of how to remove or "white-out" an item of content from a data collection is included in U.S. Patent Application No. 13 / 681,306.

The name of the content object is a hierarchically structured variable length identifier (HSLVI) and indicates a version number, a timestamp, or an implied sort order, which is used instead of the modification time in the manifest to determine the most recent version of the content object .

In some embodiments, if the remote content object corresponds to a less recent version, the system determines whether to retain the history by inserting the value of the content object from the remote manifest into the history field of the corresponding content object in the local manifest . The system appropriately updates the value for each content object determined to be different. In this way, the system synchronizes the manifest on the local node with the manifest on the remote node.

In some embodiments, network clients, network nodes (e.g., routers such as routers), and publishers communicate via an information center network (ICN). In the ICN, each part of the content is named separately, and each part of the data is bound to a unique name that distinguishes the data from the other parts of the data, such as data from different versions of the same data or from different sources. This unique name allows the network device to request data by distributing a request or an address representing a unique name, and can obtain data independent of the storage location of the data, the network location, the application and the means of transmission. A named-data network (NDN) or CCN is an example of an ICN network, and the following terms describe the components of an NDN or CCN architecture.

Content object : a single part of the named data, subject to a unique name. The content object is "persistent ", which means that the content object may move within the computing device or across different computing devices, but does not change. If any component of the content object changes, the entity that made the change creates a new content object containing the updated content and binds the new content object to a new unique name.

Unique Names : Names within the ICN are typically position-independent and uniquely identify the content object. The data-delivery device may use a name or a name prefix to deliver the packet to a network node that creates or stores the content object, regardless of the network address or physical location of the content object. In some embodiments, the name may be a hierarchically structured variable-length identifier (HSVLI). HSVLI is divided into several hierarchical components and can be structured in various ways. For example, the individual name components parc, home, ndn, and test.txt are structured in a left-oriented prefix-major fashion and have the name "parc / home / ndn / test.txt" . Thus, the name "parc / home / ndn" can be "parent" or "prefix" of "parc / home / ndn / test.txt ". Additional components may be used to distinguish different versions of content items, such as collaborative documents.

In some embodiments, the name may include a non-hierarchical identifier, for example, derived from data (e.g., a checksum value) of the content object and / or derived from a component of the name of the content object There is a hash value. An explanation of the hash-based name is given in U.S. Patent Application No. 13 / 847,814, entitled "ORDERED-ELEMENT NAMING FOR NAME-BASED PACKET FORWARDING ", inventor Ignacio Solis, filed March 20, do. The name can also be a flat label. Hereinafter, the "name" may be a name, such as a hierarchical name or a name prefix, a flat name, a fixed-length name, an arbitrary-length name or label (eg, a Multiprotocol Label Switching (MPLS) label) Is used to refer to the name of the data portion within the data network.

Interest : A packet that indicates a request for a data portion and contains a name (or name prefix) for the data portion. A data consumer can disseminate requests or inter- ests across an information-centric network, and the CCN / NDN router can satisfy requests or inter- ests by providing the requested data to a storage device (e.g., a cache server) To the creator of the data.

In some embodiments, the ICN system may include a content-based networking (CCN) architecture. However, the method disclosed herein is also applicable to other ICN architectures. A description of the CCN architecture is given in U.S. Patent Application (entitled "CONTROLLING THE SPREAD OF INTERESTS AND CONTENT IN CONTENT CENTRIC NETWORK" by inventors Van L. Jacobson and Diana K. Smetters, filed December 18, 2008) 12 / 338,175.

Figure 1 illustrates a network 100 that facilitates synchronization of a manifest between nodes in a content-centric network (CCN), in accordance with an embodiment of the present invention. The network 100 may include a router or other forwarder of the client device 116, content production device 118 and nodes 102, 104, 106, 108, 110, 112 and 114. Each node 102-114 may include one or more manifests. For example, the node 112 includes a manifest 120. The manifest 120 includes a collection name 124 and an ordered list of content objects identified by one or more of the following: a content object name 130.1-130.n; Digest (132.1-132.n), and change time (134.1-134.n). Digests 132.1-132.n include hash values of the content objects identified by names 130.1-130.n. The digest may be a SHA-256 hash of the content object, at which time the likelihood of a hash collision (where the one-way hash of two different content objects causes the same value) is sufficiently low that the digest is a unique identifier for the content object. The manifest 120 also includes a root hash 122, which is an additional hash value based on the hash value (132.1-132.n) of each content object in the collection. The root hash 122 is a unique identifier for the manifest 120 and represents a content object in the collection.

In some embodiments, the manifest indicates a name and a corresponding digest, but does not indicate a modified time. Such a system includes, for example, a file server where the previous version of the text file is important and held by the system. In another embodiment, the manifest indicates a name, a corresponding digest, and a modification time. The system uses the modification time to determine which version of the item of content should be retained. For example, if an item of content indicates a link status, the system does not need information related to the previous version. In this case, the content object having the most recently changed time is held.

Any two nodes in the network may maintain a manifest representing the same collection of data, where the manifests may be synchronized using the method described herein. The terms "local node" and "remote node" are applicable to nodes in a content-centric network (CCN) and are used in this disclosure for differentiation between two nodes within a CCN.

Synchronization of manifests representing the same collection of data between two nodes is based on the names of the three parts. The first part is a routable prefix that identifies the collection, such as "/ a / b ". The second part contains the identification of the relevant namespace and is "/ adv" for advertising or "/ data" for data transfer. The third part includes the hash value or content to be advertised or transported. Thus, the CCN name has the following format:

/ collection_prefix / adv_or_data / protocol_data

An example of an interlace to send a hash advertisement is as follows.

/ a / b / adv / <roothash>

The local node receiving this advertisement and containing the local manifest with the prefix "/ a / b" that can be routed in the same way will be able to receive the advertised manifest within the chunk number m in chunks 0, 1, . This interlude looks like this:

/ a / b / data / <roothash> / <chunk number>

Based on the entries in the retrieved manifest, the system determines whether any content objects identified in the retrieved manifest are different from the identified content objects in the local manifest. The system searches for different content objects based on the name of the content object:

/ a / b / data / <name of content object>

In some embodiments, the system retrieves a different content object based on the hash value of the requested content object:

/ a / b / data / <hash (content object)>

In some embodiments, the system retrieves a different content object based on the name in the manifest. Technique allows the system to retrieve a cached copy of an object rather than using the name of the content under the collection's namespace. For example, to retrieve the first item from the manifest 140 of FIG. 6B, the system will send an interlude and digest for the name:

/chef/events/calendar.txt, digest = {1}

2 shows a communication 200 between a node 202 (remote node) and a node 206 (local node), in accordance with an embodiment of the present invention. Node 202 and node 206 each contain a manifest with the same routing prefix, or collection name "a / b ". The remote node 202 sends an advertisement_transmitter 220, which is a hash advertisement containing the root hash value of the manifest identified by the collection name "a / b ". The interpreter takes the form of "/ a / b / adv / <roothash>". The local node 206 receives the advertised interlaces and determines whether the node 206 includes a manifest that points to the same collection as the advertised manifest, based on the same collection prefix ("a / b" And performs an ad_collection_check procedure 222 to determine whether the advertisement_collection_check procedure 222 is performed. The set of interrupts is divided into chunks based on the chunking protocol. Next, the local node 206 determines whether the root hash of its local manifest differs from the root hash of the remote manifest. The different hash values indicate that the collections should be synchronized with each other. The local node 206 then performs the manifest_earch procedure 224 by sending a set of intercepts for the manifest. &Quot; / a / b / data / < roothash / C0 &quot;, "a / b / data / &lt; roothash / C1 &quot;, / a / b / data / <roothash> / C2 ", where" C0 "represents the first chunk of the manifest, and so on. In some embodiments, the ad node may include a number of chunks that are required to transmit its manifest. In the Manifest_Chunk_Send message 228, the remote node 202 may send back the requested manifest in response to a set of interludes. The requested content object takes the form of "a / b / data / <roothash> / C0 + payload", where the payload contains the requested chunk of the manifest.

The local node 206, which owns the remote manifest, performs the set_difference_determination procedure 230. In some embodiments, the result of this procedure is a list of content objects identified by name. In another embodiment, the result is a list of content objects identified by their corresponding digests. The local node 206 sends a set_difference_request 234 for each content object determined to be different. The interrest takes the form of, for example, "/ a / b / data / name 130.3 ". The local node 206 receives the requested content object when the remote node 202 sends the set_different_content object 236, where the requested content object is "/ a / b / data / name 130.3 + payload ". Thus, the local node 206 requests and receives all content objects that are determined to be different, so that the content of the local manifest is synchronized with the content of the remote manifest. In some embodiments, the local node 206 performs a change_time_based sync procedure 240, which is described below with respect to FIG.

FIG. 3 is a flowchart 300 illustrating a method for synchronizing content associated with a remote manifest and a local manifest, in accordance with an embodiment of the present invention. In the following description, the local node is depicted as node 106 in FIG. 2, and the remote node is depicted as node 102 in FIG. The local node receives an advertisement corresponding to the remote manifest at the remote node (act 302). The manifest represents a collection of content objects at the node. The local node determines that the remote manifest and the local manifest point to the same collection of content objects (action 304, corresponding to the advertised collection collection check 222 of FIG. 2). In some embodiments, the local node determines whether the manifest points to the same collection by comparing the manifest's collection name or the routing prefix. The local node then determines whether the root hash value of the local manifest is different from the root hash value of the remote manifest (act 306). The root hash value of the manifest is the unique identifier for the manifest and contains the additional hash value of the digest of the content object represented in the manifest. If the root hash value of the local manifest is the same (decision 308), the procedure returns.

If the local hash value of the local manifest is not equal to the root hash value of the remote manifest (decision 308), this indicates that the local and remote manifests representing the same collection are not synchronous and should be adjusted. The local node downloads or sends the remote manifest by sending a request to the remote manifest and receiving a response to the request (operation 310 corresponding to the manifest_detection procedure 224 of FIG. 2).

The local node determines whether the identified content object in the remote manifest is different from the identified content object in the local manifest (operation 312, corresponding to the set_difference_determination operation 230 of FIG. 2). In some embodiments, the local node determines the set difference by comparing the digest of the content object identified in the local manifest with the digest of the content object of the same name identified in the remote manifest. The local node transmits a set of interlaces corresponding to different sets of determined content objects (action 234), and receives the requested content objects in response (action 236). This corresponds to the set_tag_resolve operation 232 shown in FIG. Thus, the content of the local manifest is synchronized with the content of the remote manifest.

If the local node is changed, the local node advertises a new root hash value. It can do so immediately, or schedule the next ad based on network or other timing considerations. For example, the local system can advertise its root hash at least once per second, but not more than four times per second. Therefore, during adjustment, when the root hash is changed due to an update, the system can advertise up to four changes per second. Otherwise, in steady state, you can advertise once per second.

4 is a flow diagram 400 illustrating a method for synchronizing content associated with a remote manifest and a local manifest based on a modified time, in accordance with an embodiment of the present invention. Synchronization of content may also be based on a sequence number associated with the content object, where a larger sequence number indicates a more recent version of the content object. The synchronization of the content may be based on the order of the names of the content objects, and the inherent sort order indicates a more recent version of the content object. The flowchart 400 depicts a method based on the modification time of the content object, which is depicted as the change_time_based sync operation 240 of FIG. Based on the previously determined set difference, the local node receives a requested set of content objects that includes a change time indicating the time at which the corresponding content object was changed (act 402). For each content object, the local node determines whether the modification time of the content object in the remote manifest is more recent or less recent than the corresponding content object in the local manifest (operation 404). If the modification time of the content object from the remote manifest is more recent (decision 406), the system updates the value of the content object in the local manifest with the value of the content object from the remote manifest (act 408). In some embodiments, the local node inserts the corresponding value and the modification time of the (less recent) content object into the history field in the local manifest, before updating the value of the content object in the local manifest, &Lt; / RTI &gt; latest) content object. If there are more content objects in the set to be searched (act 410), the system returns to act 404. If not, the system has finished searching for the required content object.

If the modification time of the content object from the remote manifest is less recent than the corresponding content object in the local manifest (decision 406), the system updates the corresponding value and the modification time of the (less recent) (Act 414) to determine whether to store the value of the (less recent) content object from the remote manifest (decision 412). If there are more content objects in the set to be searched (act 410), the system returns to act 404. If not, the system has finished searching for the required content object. Thus, all content objects determined to be different have been updated and possibly held or stored in the history field of the local manifest, so that the content of the local manifest is synchronized with the content of the remote manifest.

5 is a flow diagram 500 illustrating a method for transmitting an advertisement corresponding to a manifest, in accordance with an embodiment of the present invention. The node of FIG. 5 is described as a local node because it transmits the packet to the remote node. Note that the local node in FIG. 5 corresponds to node 202 in FIG. 2, which was previously referred to as remote node 202. Recall that a node in a network, such as a content-centric network (CCN), may be referred to as a remote node or a local node.

The local node sends an advertisement corresponding to the manifest, and the manifest represents a collection of content objects at the node (action 502 corresponding to the advertisement_sending message 220 of FIG. 2). This ad is an beacon-like interlace, and does not require content in a reply based on the "/ adv" namespace used. Upon receiving a request for a manifest from a remote node, the local node sends the manifest to the remote node (manifest_in_chunk_request 226 and manifest_chunk_request 228 in FIG. 2) Lt; / RTI &gt; operation 504). Upon receiving a request for a content object identified in the local manifest from the remote node, the local node forwards the requested content object to the requesting remote node (set_difference_request 234, Corresponding to receipt of a transmissioninterpret 236, operation 506).

6A is a table showing the format of a content object and the manifest 120 represented in the collection according to an embodiment of the present invention. The manifest 120 includes an ordered list of content objects identified by the collection name 124 and also includes a list of content object names 130.1-130.n, digests 132.1-132.n, 134.n). Digests 132.1-132.n include hash values of the content objects identified by names 130.1-130.n. The manifest 120 also includes a root hash 122, which is an additional hash value based on the hash value (132.1-132.n) of the individual content objects in the collection. The root hash 122 of the manifest 120 is a unique identifier for the manifest 120.

As described in connection with FIG. 1, the manifest 120 may indicate a name and a corresponding digest for each content object represented in the collection. In some embodiments, the manifest 120 may include a modification time for each content object represented in the collection. The use of the change time field depends on the underlying application or service being executed. Note that the manifest 120 points to the collection name 124. The manifest depicted in Figures 6b-e also includes the collection name, but since the manifest contains the same collection of data, the collection name is not included in Figures 6b-e.

Figures 6b-6e depict two nodes 102 and 106, each of which includes a manifest. In this example, node 102 is a remote node and node 106 is a local node. The local node 106 includes a manifest 160 and the remote node 102 includes a manifest 140. Manifests 140 and 160 contain the same collection name or routing prefix, and thus contain the same collection of content objects or data. The times are indicated by labels T1, T2, etc., and the contents of the manifests 140, 160 are depicted relative to these time labels.

The manifest is further identified by the root hash value, shown as the root hash 122 in Figure 6A, which is an additional hash value based on the digest of the individual content objects in the collection. In the example below, the root hash value and digest are indicated in parentheses, for example, "{999}", but the number may be much larger. In addition, the time-varying digest of the content object and the root hash value of the manifest 140,160 are depicted only as an equivalent representation of the additional hash value.

6B is a table depicting the format of two manifests during synchronization, in which a local manifest is missing a content object from a remote manifest, in accordance with an embodiment of the present invention. At time T1, the local node 106 receives a hash advertisement from the remote node 102 of the manifest 140, having a root hash value of {999}. The local node 106 determines that its manifest 160 represents a collection of the same data as the remote manifest 140 and retrieves the manifest 140. [ Local node 106 determines that local manifest 160 with root hash value {60} is not synchronous with remote manifest 140 with root hash value {999}. The local node 106 then determines the set difference between its local manifest 160 and the remote manifest 140. In this example, the content object identified by the name "/ fruit / lychee / peel" in the manifest 160 is missing and accordingly the local node 106 sends the content object with that name to the remote node 102 And transmits the interlace. The remote node 102 returns the requested content object. At time T2, the local node 106 updates the manifest 160 with the missing content object. Based on the content of the manifest 160 at time T2, the system generates a new root hash value for the manifest 160, which is the same as the root hash value of the current remote manifest. This is depicted by the root hash value of the manifest 160 at time T2: {60} -> {999}. Thus, the local and remote manifests synchronize their collections and both maintain the same root hash value of {999}.

FIG. 6C is a block diagram of an embodiment of the present invention in which a digest of a content object of the same name in a local manifest is different from a digest in a remote manifest, a remote node advertises its manifest, a local node retrieves a remote manifest, It is a table depicting the format of the two manifests during. At time T3, the local node 106 receives a hash advertisement from the remote node 102 of the manifest 140, having a root hash value of {999}. The local node 106 determines that its manifest 160 represents a collection of the same data as the remote manifest 140 and retrieves the manifest 140. [ The local node 106 determines that the local manifest 160 with the root hash value {53} is not synchronous with the remote manifest 140 with the root hash value {999}. The local node 106 then determines the set difference between its local manifest 160 and the remote manifest 140. In this example, the content object identified by the name "/ fruit / lychee / peel " having a digest of {279} in the manifest 160 is missing, and thus the local node 106 And sends the object to the remote node 102 for the object. The remote node 102 returns the requested content object. At time T4.a, the local node 106 updates the manifest 160 with the missing content object. Based on the contents of the manifest 160 at time T4.a, the system generates a new root hash value for the manifest 160. This is depicted as the root hash value of the manifest 160 at time T4.a: {53} -> {772}. However, the manifest 140 whose original root hash value is {999} is not currently synchronous with the manifest 160 whose new root hash value is {772}.

Subsequently, the remote node 102 has a new root hash value {772}. And receives a hash advertisement from the local node 106 of the manifest 160. The remote node 102 determines that its manifest 140 represents a collection of the same data as the manifest 160 and retrieves the manifest 160. The remote node 102 determines that its manifest 140 with the root hash value of {999} is not synchronous with the manifest 160 whose root hash value is {772}. The remote node 102 determines the set difference between its manifest 140 and the manifest 160. In this example, the content content object identified by the name of "/ fruit / lychee / peel" with the digest of {41} is missing in the manifest 140 and thus the remote node 102 is based on its name and digest And sends an interlace to the local node 106 for the content object. The local node 106 returns the requested content object. At time T5.a, the remote node 102 updates the manifest 140 with the missing content object. Based on the content of the manifest 140 at time T5.a, the system generates a new root hash value for the manifest 140. [ This is depicted as the root hash value of the manifest 140 at time T5.a: {999} -> {772}. Thus at T5.a, the manifest 140 at node 102 is synchronous with the manifest 160 at node 106. [ Nodes 102 and 106 synchronized their collections, and both maintain the same root hash value of {772}.

FIG. 6D is a diagram illustrating an example of a method in which a digest of a content object of the same name in a local manifest is different from a digest in a remote manifest, a local node sends an advertisement, and a remote node searches for a local node, It is a table depicting the format of both manifests. At time T3, the remote node 102 receives a hash advertisement from the local node 106 of the manifest 160, having a root hash value {53}. The remote node 102 determines that its manifest 140 represents a collection of data that is the same as the local manifest 160 and retrieves the manifest 160. The remote node 102 determines that its manifest 140 with the root hash value of {999} is not synchronous with the manifest 160 with the root hash value {53}. The remote node 102 then determines the set difference between its manifest 140 and the manifest 160. In this example, the manifest 140 is missing a content object identified by the name of "/ fruit / lychee / peel" with a digest of {41}, and thus the remote node 102 And sends the interleaves to the local node 106 for the object. The local node 106 returns the requested content object. At time T4.b, the remote node 102 updates the manifest 140 with the missing content object. Based on the content of the manifest 140 at time T4.b, the system generates a new root hash value for the manifest 140. This is depicted as the root hash value of the manifest 140 at time T4.b: {999} -> {772}. However, the manifest 160 whose original root hash value is {53} is not currently synchronous with the manifest 140 whose new root hash value is {772}.

Subsequently, the local node 106 has a new root hash value {772}. And receives a hash advertisement from the local node 102 of the manifest 140. The local node 106 determines that its manifest 160 represents the same data collection as the manifest 140 and retrieves the manifest 140. [ The local node 106 determines that its manifest 160 with the root hash value {53} is not synchronous with the manifest 140 with the root hash value {772}. The local node 106 determines the set difference between its local manifest 160 and the remote manifest 140. In this example, the content content object identified by the name of "/ fruit / lychee / peel" having a digest of {41} is missing in the manifest 160 and thus the local node 106 is based on its name and digest And transmits the interleaves to the remote node 102 for the content object. The remote node 102 returns the requested content object. At time T5.b, the local node 106 updates the manifest 160 with the missing content object. Based on the contents of the manifest 160 at time T5.b, the system generates a new root hash value for the manifest 160. This is depicted as the root hash value of the manifest 160 at time T5.b: {53} -> {772}. Thus at T5.b the manifest 140 at node 102 is synchronous with the manifest 160 at node 106. [ Nodes 102 and 106 synchronized their collections, and both maintain the same root hash value of {772}.

Figures 6c and 6d show that any node can be a remote or local node and the order of sending or receiving content objects determined to be different in association with the hash ad, manifest and manifest can be determined according to the content in the collection at a given time, May vary depending on the contents of the manifests 140 and 160 at times [T3, T4.a, T5.a] and at times [T3, T4.b, T5.b]. That is, any node can send and receive hash advertisements, transport manifests, and synchronize the content of a manifest at a node, using the method described in this disclosure, The collection is synchronized.

6E is a table depicting the format of two manifests during synchronization, where the digest of the same name content object and the modification time in the local manifest are different from the modification time in the remote manifest, in accordance with an embodiment of the present invention.

At time T6, the local node 106 receives a hash advertisement from the remote node 102 of the manifest 140, having a root hash value of {999}. The local node 106 determines that its manifest 160 represents a collection of the same data as the remote manifest 140 and retrieves the manifest 140. [ Local node 106 determines that local manifest 160 with root hash value {80} is not synchronous with remote manifest 140 with root hash value {999}. The local node 106 then determines the set difference between its local manifest 160 and the remote manifest 140. In this example, the manifest 140 and the manifest 160 indicate a modification time 134 corresponding to each content object represented in its collection. The system determines that a content object having the same name in the manifest 140 and the manifest 160 has a different modification time than the different digest. Note that the modification time includes information related to the seconds, minutes, hours, dates, months, and years when the content object was changed. For simplicity, the manifest of Figure 6E only includes the time of the day. The manifest 140 includes a digest of {1} and a content object identified by the name of "/chef/events/calendar.txt" with a modification time of 8:05 am. The manifest 160 includes a content object identified by the same name with a different modification time of 7:30 am than the different digest of {320}. The local node 106 sends an interrest to the remote node 102 for the content object based on the name and digest of the different content object. The remote node 102 returns the requested content object.

The local node determines that the content object from the remote manifest 140 with a modification time of 8:05 am is more recent than the content object from the local manifest 160 with a modification time of 7:30 am. Thus, at time T7, the local node 106 updates the manifest 160 with a different, more recent content object. Based on the contents of the manifest 160 at time T7, the system generates a new root hash value for the manifest 160. This is depicted by the root hash value of the manifest 160 at time T7: {80} -> {999}. Thus at time T7 the manifest 160 at the local node 106 is synchronous with the manifest 140 at the remote node 102. [ Nodes 102 and 106 synchronized their collections, both containing the same root hash value {999}.

In some embodiments, the system stores a previous version of the changed content object (e.g., a digest of {320} and a name with a modification time of 7:30 am "/chef/events/calendar.txt "). &Lt; / RTI &gt; In another embodiment, when the remote node 102 receives a hash advertisement from the local node 106 of the manifest 160 with the root hash of {80} and downloads the local manifest 160, Determines that the version of the received content object identified by the name "/chef/events/calendar.txt" having a digest of {320} and a modification time 7:30 am is less recent than the version in its own manifest. In this case, the manifest 140 at the remote node 102 remains asynchronous with the manifest 160 of the local node 106. The manifest will proceed with synchronization after the local node 106 has received the hash advertisement from the remote node 102 of the manifest 140 which will maintain the more recently updated content object as described above .

In some embodiments, the system facilitates devices in a content-centric network (CCN) and service discovery provided by these devices. The CCN namespace is divided into service types, for example, a printer, a file server, or a music library. Certain types of devices perform the synchronization protocol described in this disclosure within these namespaces. For example, the collection prefix for these services takes the following form:

/ parc / services / printers / ...

/ parc / services / servers / ...

/ parc / services / music / ...

In this service discovery system, a device at a node (for example, a printer named "/ parc / marvin") boots to a blank manifest. The device creates a service record for itself, which is a content object with the name "/ parc / marvin / service ". In some embodiments, the service record is a JavaScript Object Notation (JSON) format and may include one or more of the following fields: the name of the service record; Description of services; A serial number indicating the version of the service record; Time to live (TTL), measured in seconds, to expire the service record if it is not periodically resumed by the device advertising the service; And a digest for the service record, which is the hash value of the service record. Because the size of the service record is relatively small, in some embodiments, the service record may be included as a payload in the inter- est. A service record with a higher serial number also indicates a more recent service record and replaces a record with a lower serial number. Older service records are not kept in the manifest.

The device creates a manifest that contains the service record of the device and the corresponding hash value of the service record. The system generates a root hash value, which is an additional hash value based on the digest of the content object in the collection. The root hash value of the device's manifest is based on a service record initially pointed to in the manifest. The device then sends a query advertisement of the form "/ parc / services / printers / adv / query" to allow it to do the following: Manifest of other devices in the same device namespace ("parc / services / printers" &Lt; / RTI &gt; Determine a set difference; And solve set difference. In this way, a device at a node can synchronize its manifest with the manifests of other devices at other nodes.

In some embodiments, the service record is set to expire based on the time indicated in the TTL field of the service record. At some time before it expires, the device can sequentially create a new service record with a larger serial number and replace the old service record. A description of how to remove or "white-out" an item of content from a data collection is included in U.S. Patent Application No. 13 / 681,306. The system generates a new root hash value for the manifest associated with the device based on the new service record. The device then advertises the updated manifest with the new service record using the newly created root hash value, and repeats the process described above. Also, when the service record expires, for example, when the TTL expires, all devices remove expired service records from their manifests and generate new hash advertisements without expired service records.

In some embodiments, when the device is shut down, it creates a new service with a TTL set to zero and a larger serial number. The device advertises its manifest based on the updated service record and sets itself to expire immediately after sending the advertisement so that the other device receiving the advertisement will have the most recent Service records to be included.

In some embodiments, the advertised interlude may include a payload, which in its entirety includes a service record having the following format: &lt; RTI ID = 0.0 &gt;

"/ parc / services / printers / adv / <roothash> / <payload>

Figure 7 shows a network 700 that facilitates service discovery based on synchronization of manifests between devices in a content-centric network, in accordance with an embodiment of the present invention. The network may include a client device 716, a content production device 718 and a router or other device (e.g., a printer) at nodes 702, 704, 706, 708, 710, 712, 714 . Each node 702-114 may include one or more manifests. For example, the node 712 may include a manifest 720. The manifest 720 includes an ordered list of service records identified by a prefix or namespace 724 and one or more of the following: a service record name 730.1-730.n; Serial number (732.1-732.n), time to live (TTL) (734.1-734.n), and digest (736.1-736.n). Digest 736.1-736.n contains the hash value of the service record identified by the name 730.1-730.n. The digest may be a SHA-256 hash of the service record, at which time the probability of a hash collision (where the one-way hash of two different content objects causes the same value) is sufficiently low that the digest is the unique identifier for the service record. The manifest 720 also includes a root hash 722, which is an additional hash value based on the hash value (736.1- 736.n) of each record service in the collection. The root hash 722 is a unique identifier for the manifest 720 and represents the service record in the collection.

A device may reside at any node in the network, where each device carries a manifest representing a collection of service records. Both devices carry a manifest of the same collection of data, e. G., A service record for the same namespace, where the manifests can be synchronized using the method described herein. The terms "local node" and "remote node " are applicable to any node in the content-centric network (CCN) and are used for differentiation between the two nodes in the CCN in this disclosure. Similarly, the terms "local device" and "remote device" can be applied to a device at a node within a CCN and are used for illustrative purposes in this disclosure.

In some embodiments, the interrest may include as a payload a service record containing its corresponding digest. The device (e.g., device 716, device 718, and nodes 702-714) in the node or node in the CCN is an advertisement that contains both the root hash value of the manifest of the sending device and the service record corresponding to the sending device, Or the like. The node or device may also be configured to send or receive an inter-query that is a query or request for such advertisement, including, for example, both the root hash value of the manifest of the sending device and the service record of the sending device included as the payload .

8 shows a communication 800 between an apparatus 702 (remote device, "Larry") and a device 706 (a local device, "Nancy"), in accordance with an embodiment of the present invention. Apparatus 702 and apparatus 706 each contain a manifest with the same routing prefix or namespace, "/ p / prn /". Suppose that the remote device 702 has already been initialized on the network and includes at least its own service record, a manifest ("L") containing "L-SR". The local device 706 is initialized in the device_initialization procedure 820. [ The local device 706 creates a service record for itself, "N-SR", and generates a local manifest ("N") for itself that contains its own service record. The local device also generates a root hash value, "<roothash (N)>, for its manifest. The local device 706 sends the query for query 822 to the remote device 702 in the form of "/ p / prn / adv / query". Note that any device on the network may receive an interlude that includes a query for the ad. The local device 706 also advertises its own manifest and service record by sending an advertisement_request 824. This ad contains the root hash value of its own manifest "N" and contains the service record of the local device as a payload: "p / prn / adv / <roothash (N)> / <payload = SR)> ". The advertisement_transmission 824 (shown in dashed lines) may be repeatedly transmitted by the local device 706, and therefore does not occur only after initialization. A node or device may use a gossip protocol to avoid a flooding segment with many iterations. For example, a node may choose a random backoff, where the first node advertises its root hash and the second node with the same root hash also advertises its root hash. The third and subsequent nodes with the same root hash suppress transmission of its root hash.

The local device 706 may receive an ad-receiveinterface 826, which is a format similar to the interlaces 824, and includes the root hash value of the manifest of the remote device and the service record "/ p / prn / adv / <roothash (L)> / <payload = (L-SR)> "as a payload. The local device performs the manifest_update procedure 828. Local device 706 determines whether its manifest indicates the same namespace as the advertised manifest manifest, based on the same collection prefix or namespace ("/ p / prn /"). Local device 706 may be configured to insert an advertised service record included as a payload into the local manifest 826 if the included service record is more recent than the local device 702 already has Update the local manifest. Local device 706 generates a new root hash value for its local manifest. If the new root hash value is equal to the advertised root hash value from the interlace 826, then the collection of service records in the manifests of the local device 706 and remote device 702 is synchronous. Thus, because the intercept includes the service record of the remote device as a payload, the remote and local manifests are synchronized without having to transport the manifest across the network.

If the new root hash value of the local device 706 is not equal to the root hash value of the advertised interfast 826, then the local device 706 may perform the set adjustments using the method described with respect to FIGS. . Local device 706 sends a Remote_Manifest_request 842 request (of the form / p / prn / data / <roothash (L)>) Manifest search procedure 840 by receiving a remote_manifest_receive 844 (of the form (L)>). Local device 706 performs set_difference determination procedure 846 to determine which service record represented in the remote manifest is different from the service record represented in its local manifest. Local device 706 sends a set_difference_request 850 (of the form "p / prn / data / name 730.3 & ) Set_difference_receive procedure 858 by receiving the set_difference_receive_receive_receive 852.

9A is a flow diagram 900 illustrating a method for facilitating service discovery based on synchronization of manifests of two devices in a network, in accordance with an embodiment of the present invention. The local device is initialized on the network (act 902). The local device generates a service record for itself, which includes the name, serial number, time to live (TTL), and digest of the service record (act 904). The local device creates a local manifest containing the service record of the local device (act 906) and generates a root hash value for the local manifest based on the digest of the service record contained in the manifest (act 908). The local device sends a query advertisement to retrieve the root hash of the manifest of the other device in the same namespace (act 910). The local device sends an advertisement corresponding to the local manifest, which contains the root hash value of the local manifest and carries the local service record as a payload (act 912). The local device receives the advertisement corresponding to the remote manifest, and the advertisement contains the root hash value of the remote manifest and carries the remote service record as a payload (act 914).

The local device determines that the local and remote manifests correspond to the same namespace (act 916). In some embodiments, the local device determines whether the local manifest includes a service record having the same name as the advertised service record (act 918). If the local manifest does not include such a service record (act 920), the local device updates the local manifest by inserting the advertised service record from the payload into the local manifest (act 926). If the local manifest includes such a service record (act 920), then the local device determines whether the serial number of the advertised service record is greater than the serial number of the service of the same name in the local manifest (act 922). If not greater (decision 924), the method returns because the version contained in the local device is more recent.

If the serial number of the advertised service record is greater than the serial number of the service of the same name in the local manifest (decision 924), then the local device determines that the current serial number is greater than the current serial number (Operation 926). In some embodiments, this condition may persist so that if the device is rebooted and loses memory, its serial number is initialized less than the last advertised prior to the failure. The local device updates the local manifest by inserting the next updated service record into the local manifest (act 927). A description of how to remove content items from a collection of data or "white-out" is included in U.S. Patent Application No. 13 / 681,306.

FIG. 9B is a flowchart 950 that continues to illustrate the method shown in flowchart 900 of FIG. 9A. After updating its local manifest (act 926), the local device generates a new root hash value for the local manifest (act 928). The local device determines whether the new root hash value is different from the root hash value of the remote manifest contained in the advertised inter- action (act 930). If the hash value is not different (decision 932), the method returns because the remote manifest and the local manifest are synchronous. If the hash values are different (decision 932), the local device performs the set coordination and manifest transport described in connection with FIGS. 1-6. The local device sends a request based on the advertised interlude's root hash value and receives the remote manifest (act 934). The local device determines which service record represented in the remote manifest differs from the service record represented in the local manifest (act 936). In response to the difference determination, the local device transmits a set of interactions for different service records (act 938) and receives a set of requested service records (act 940).

FIG. 10A shows a table depicting the format of a service record and manifest 720 represented in the collection, according to an embodiment of the present invention. The manifest 720 includes an ordered list of service records including a prefix or namespace 724 and identified by one or more of the following: a service record name 730.1-730.n; Serial number (732.1-732.n); Time to rib (TTL) (734.1-734.n); And Digest (736.1-736.n). Digests 736.1-736.n contain hash values of the content objects each identified by name 730.1-730.n. The digest may be a SHA-256 hash of the content object, where the likelihood of a hash collision (where the one-way hash of two different content objects causes the same value) is sufficiently low that the digest is the unique identifier for the content object. The manifest 720 also includes a root hash 722, which is an additional hash value based on the hash value (736.1- 736.n) of each content object in the collection. The root hash 722 is a unique identifier for the manifest 720 and represents the service record in the collection. In the following example, the root hash values and digests are indicated as numbers in parentheses, e.g., "{222}", but the number may be much larger. In addition, the time-varying digest of the service record and the root hash values of the manifests 740, 760, 780 of Figures 10b-10d are depicted only as an equivalent representation of the additional hash value.

Figure 10B shows a table depicting the format of two manifests during service discovery using a synchronization protocol, where the local device does not need to retrieve the remote manifest, in accordance with an embodiment of the present invention. At time T1, a printer named "/ parc / larry" ("Larry") operates at node 702 and a printer named "/ parc / marvin" . Printers Larry and Marvin both belong to the namespace "/ parc / services / printer", and thus each contains a manifest that requires synchronization with all other manifests in the same namespace. A printer named Larry, or a manifest 740 associated with the device, contains a service record corresponding to the device Larry. The service record corresponding to the Larry is denoted by the name of the "L-SR", the serial number 1, and the corresponding digest of {22}. The root hash value of the manifest 170 is {222}. A printer, or a manifest 780 associated with a device named Marvin, contains a service record corresponding to the device Marvin. The service record corresponding to Marvin is denoted by the name of the "M-SR", the serial number 7, and the corresponding digest of {11}. The root hash value of the manifest 780 is {111}.

During operation, at time T1, the Larry sends an advertisement to the format "/ parc / services / printer / adv / <roothash = {222}> / <payload = (L-SR)>". Marvin receives this ad and determines in his manifest 780 that the service record "L-SR" contained as a payload in the advertisement is missing. At time T2, Marvin inserts the service record "L-SR" into his manifest 780 and, based on the hash value of the existing service record indicated in the manifest ("M-SR" and "L- Lt; RTI ID = 0.0 &gt; 780 &lt; / RTI &gt; This is described as {111} -> {33}.

At time T2, the manifest 780 with the new root hash value {33} is not synchronized with the advertised manifest 740 with the root hash value {222}. Marvin sends an ad of the form "/ parc / services / printer / adv / <roothash = {33}> / <payload = (M-SR)>". Larry receives this ad and determines in his manifest 740 that the service record "M-SR" contained as a payload in the advertisement is missing. At time T3, the Larry inserts the service record "M-SR" into its manifest 740 and adds the hash value of the existing service record indicated in the manifest 740 ("M-SR" and "L- And generates a new root hash value for the manifest 740 based on the new root hash value. This is described as {222} -> {33}. In this manner, the devices Larry and Marvin of nodes 702 and 704 synchronized their respective manifests 740 and 780 with each other without having to download the complete manifest from each other.

Figure 10C shows a table depicting the format of two manifests during service discovery using a synchronization protocol, in which a local device receives an updated service record from a remote device, in accordance with an embodiment of the present invention. At time T4, the manifests 740 and 780 are synchronous with each other, and both maintain the root hash {33}. At time T5, the Larry updates its own service record "L-SR" and assigns a serial number 2 and a new digest &lt; 72 &gt;. Larry generates a new root hash value for manifest 740 based on the hash value of the existing service record indicated in manifest 740 (updated "L-SR" and "M-SR"). This is described as {33} -> {105}. Larry sends the ad in the format "/ parc / services / printer / adv / <roothash = {105}> / <payload = (L-SR)>". Marvin receives Larry's service record updated with this ad and Digest {72}, and his manifest 780 receives a serial number ("1") smaller than the serial number (" Quot; L-SR "having " L-SR &quot; At time T6, Marvin updates the service record with the name "L-SR" and serial number 1 in the manifest 780 to the advertised service record in manifest 740, with serial number 2 and digest &lt; Thereby updating the manifest 780. Marvin generates a new root hash for the manifest (780), which is denoted by {33} -> {105}. Thus, at nodes 702 and 704, device Larry and Marvin synchronized their respective manifests with each other without having to download the entire manifest from each device.

Figure 10D shows a table depicting the format of two manifests during service discovery using a synchronization protocol, in which a local device initiates, performs service discovery, and retrieves a remote manifest, in accordance with an embodiment of the present invention.

At time T6 in FIG. 10C, a device named Larry and Marvin operates with each manifest 740, 780 at nodes 702, 704. Manifests 740 and 780 are synchronous and each has a service record of a Larry ("L-SR") with sequence number 2 and Digest {72}, Marvin ("M-SR" ") &Lt; / RTI &gt; The root hash of the manifests 740 and 780 is {105}.

At time T7, shown in FIG. 10d, the device Larry is operating on a manifest 740 at node 702, which is running on a Larry with two service records: name "L-SR", serial number 2, digest 72 Service records for; And a service record for Marvin having the name "M-SR ", serial number 7, digest &lt; 11} The root hash value of manifest 740 is {105}. At time T7, the manifest for Marvin (not shown in Figure 10D) is synchronized with Larry's manifest 740. At time T7, the printer with the name "/ parc / nancy" ("Nancy") is booted and operates at node 706. Device Nancy belongs to the same namespace "parc / services / printers" as Larry and Marvin. Nancy creates a service record for her, which is a service record with the name of "N-SR", serial number 1, and corresponding digest {65}. Nancy generates a manifest 760 containing the newly created service record and generates a root hash value {165} for the manifest. Nancy then sends an ad query of the form "/ parc / services / printers / adv / query" to the network for the namespace "parc / services / printers". Nancy receives an advertisement from Larry in the form of "/ parc / printers / adv / <roothash = {105}> / <payload = (L-SR)>". Nancy receives this ad and determines that the service record "L-SR" contained as a payload in the hash advertised in its manifest 760 is missing. At time T8, the Nancy inserts the service record "L-SR" into its manifest 760 and, based on the hash value of the existing service record indicated in the manifest ("N-SR" and "L- (760). &Lt; / RTI &gt; This is described as {165} -> {200}. Nancy decides that the root hash {200} of his manifest 190 is not the same as the advertised root hash {105} of the advertised, and so the Nancy performs a complete set adjustment using the method described below.

Based on the chunking protocol,

"parc / services / printers / data / <roothash = {105}> / S0"

"parc / services / printers / data / <roothash = {105}> / S1"

it searches the manifest with the root hash value {105} by sending a set of intercepts in the form "parc / services / printers / data / <roothash = {105}> / S2"

"parc / services / printers / data / <roothash = {105}> / S0 + payload". The Nancy then determines the different service records and sends a set of interludes to the service records determined to be different. In this example, Nancy determines that the missing service record corresponds to a Marvin named "M-SR" with a serial number 7 and a corresponding digest {11}. Nancy

 The content objects are sent in the format of "/ parc / services / printers / data / <payload = (M-SR)>" . At time T9, the Nancy inserts the service record "M-SR" into its manifest 760 and adds the existing service record indicated in the manifest (L-SR, M- And generates a new root hash value for manifest 760 based on the hash value of &lt; RTI ID = 0.0 &gt; This is described as {200} -> {420}. However, the manifest 760 with the root hash {420} of the device nancy has a manifest 740 of Larry with the root hash {105} (and possibly with the Marvin's manifest 780, depicted at time T6 in FIG. The same, different manifest). Next to Nancy

(and other devices on the network) send an advertisement of the form "/ parc / services / printers / adv / <roothash = {420}> / <payload = (N-SR)>" And updates each manifest thereof with the Nancy's service record ("N-SR") included as a payload in this advertisement. At time T10, Larry inserts Nancy's service record, N-SR, with digest {65} into manifest 740 and generates the same new root hash value {420}. This is denoted by {105} -> {420}. Note that Marvin can also insert N-SR with digest {65} into manifest 780 and also generate the same new root hash value {420}. Thus, the existing device Larry and Marvin of node 706 and the new device nancy 702, 704 of node 706 can also use the advertisement containing the service record without having to transport the manifest, By using the collection synchronization protocol based on the transfer of the manifests, their manifests were synchronized with each other.

Figure 11 shows a computer communication system that facilitates service discovery based on synchronization of manifests between devices in a content-centric network, in accordance with an embodiment of the present invention. The computer communication system 1102 includes a process 1104, a memory 1106, and a storage device 1108. Memory 1106 may include volatile memory (e.g., RAM) provided as a managed memory, and may be used to store one or more memory pools. Computer communication system 1102 may also be coupled to display device 1110, keyboard 1112, and pointing device 1114. Storage device 1108 may store operating system 1116, content-processing system 1118, and data 1132.

The content-processing system 1118, when executed by the computer communication system 1102, may include instructions that may cause the computer communication system 1102 to cause the method and / or process described in this disclosure to occur. In particular, the content-processing system 1118 may include an instruction to receive an advertisement corresponding to the remote manifest of the remote node, wherein the advertisement includes a service record corresponding to the remote device (advertisement mechanism 1122). The content-processing system 1118 may include an instruction to send an advertisement corresponding to the local manifest of the local device, wherein the advertisement includes a service record corresponding to the local device (advertisement mechanism 1122). The content-processing system 1118 may also include an instruction to send an advertisement corresponding to the updated local manifest, wherein the manifest is a service record that is deleted in response to the occurrence of a time-to-live (TTL) (Ad mechanism 1122).

The content-processing system 1118 may also include a command to update the local manifest of the local device by inserting the advertised service record of the remote manifest into the local manifest, in response to the determination that the local manifest and the remote manifest correspond to the same namespace (Manifest update mechanism 1124). The content-processing system 1118 may also be configured to send the value of the service record in the local manifest to the remote server in response to a determination that the serial number of the advertised service record from the remote device is greater than the serial number of the service record of the same name in the local manifest. With the value of the service record advertised from the device (manifest update mechanism 1124). The content-processing system 1118 may also include instructions to update the local manifest by deleting the service record from the local manifest in response to the occurrence of a time-to-live (TTL) of the service record in the local manifest Mechanism 1124).

The content-processing system 1118 may further comprise instructions to send a query for an advertisement corresponding to the remote manifest of the remote device and receive a query from the remote device for an advertisement corresponding to the local manifest, Includes a service record corresponding to the device (query mechanism 1126).

The content-processing system 1118 may also include instructions to initialize by the local device, generate a service record corresponding to the local device, and generate a manifest for the local device containing the service record ( Initialization mechanism 1128).

The content-processing system 1118 can also send a request for a remote manifest, receive a remote manifest, send a request for a content object or service record associated with a remote manifest, and send the requested content object Or a service record (communication mechanism 1120). The content-processing system 1118 includes instructions for sending a set of interleaves to retrieve a remote manifest based on a chunking protocol, such that each interleave corresponds to a numbered chunk of the manifest (Communication mechanism 1120). The content-processing system 1118 sends an advertisement corresponding to the manifest, sends the manifest to the remote node in response to receiving the request for the manifest, and sends the requested content object or service record associated with the manifest to the remote node (Communication mechanism 1120), and receiving a set of interludes based on a chunking protocol such that each of the interaves corresponds to a numbered chunk of the manifest.

The content-processing system 1118 may further include instructions to determine, based on the received remote manifest, which service record represented in the remote manifest differs from the service record represented in the local manifest (the difference determination mechanism 1130 ).

The data 1132 may include any data that is requested as input or generated as an output by the method and / or process described in this disclosure. In particular, data 1132 includes at least: a manifest representing a collection of service records; Service records; The name of the service record; Description of the service record; Serial Number; Time-to-second (TTL) in seconds; The corresponding digest of the service record; A manifest's root hash value, which is an additional hash value based on a digest of the service record represented by the manifest; The manifest's namespace or routing prefix, which identifies the manifest; An identifier for determining that the packet corresponds to an advertisement of the data; An identifier that determines that the packet corresponds to a transfer of data; And store a number corresponding to the numbered chunk of the manifest based on the chunking protocol.

The data structures and codes described in this specification are typically stored in a computer-readable storage medium, which may be an apparatus or medium capable of storing code and / or data for use by a computer system. The computer-readable storage medium may be a magnetic and optical storage device such as a volatile memory, a non-volatile memory, a disk drive, a magnetic tape, a CD (compact disk), a DVD (digital versatile disk or digital video disk) And other media capable of storing computer-readable media to be played back.

The methods and processes described in this Detailed Description section may be implemented as code and / or data and stored in a computer-readable storage medium, as described above. When a computer system reads and executes code and / or data stored in a computer-readable storage medium, the computer system is implemented as a data structure and code to perform the methods and processes stored in the computer-readable storage medium.

In addition, the methods and processes described above may be included in a hardware module or device. These modules or devices may be application specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), dedicated software modules or dedicated or shared processors that execute portions of code at specific times, and / And other programmable-logic devices to be developed. When a hardware module or device is activated, they perform the methods and processes contained within them.

Claims (7)

A computer system for detecting anomalies,
A processor;
And a storage device coupled to the processor and storing instructions that when executed by the computer cause the computer to perform the method,
Receiving, by a local device, a first advertisement corresponding to a remote manifest of the remote device, the first advertisement comprising a service record corresponding to the remote device; And
Updating the local manifest of the local device by inserting a service record of the first advertisement into the local manifest in response to a determination that the local manifest and the remote manifest correspond to the same namespace. The method of claim 1,
And sending a query for a second advertisement corresponding to the remote manifest of the remote device. The method of claim 1,
Further comprising transmitting a second advertisement corresponding to the local manifest of the local device, wherein the second advertisement includes a service record corresponding to the local device. The method according to claim 1,
The packets transmitted or received by the local device
A routable prefix identifying the manifest;
An identifier for determining that the packet corresponds to a transfer of data;
An identifier for determining that the packet corresponds to an advertisement of data;
The root hash value of the manifest;
The name of the service record in the manifest; And
Service record
/ RTI &gt; of the computer system. The method according to claim 1,
Updating the local manifest
In response to determining that the serial number of the service record of the first advertisement is greater than the serial number of the service record in the local manifest having the same name as the service record of the first advertisement, Value to the value of the service record of the first advertisement. The method of claim 1,
Initializing on a network when the local device does not include any manifests;
Generating a service record corresponding to the local device; And
Further comprising generating a manifest for the local device containing the service record. The method of claim 1,
In response to the occurrence of a time to live (TTL) of a service record in the local manifest,
Updating the local manifest by deleting the service record from the local manifest; And
And sending a second advertisement corresponding to the updated local manifest.

Images