DEAD DROP NETWORK ARCHITECTURE
`
`CROSS-REFERENCE TO RELATED APPLICATIONS
`
`[0001]
`
`This application is a continuation of US. Application No. 15/640,211, filed on June
`
`30, 2017, which is a continuation of US. Application No. 15/136,347, filed on April 22, 2016,
`
`issued as US. Patent No. 9,729,390, which claims the benefit of US. Provisional Application
`
`No. 62/151,188, filed April 22, 2015, US. Provisional Application No. 62/193,927, filed July 17,
`
`2015, US. Provisional Application No. 62/193,930, filed July 17, 2015, and US. Provisional
`
`Application No. 62/214, 124, filed September 3, 2015, all of which are incorporated by reference
`
`herein.
`
`1.
`
`FIELD OF ART
`
`BACKGROUND
`
`[0002]
`
`The present invention generally relates to the field of computer networking and data
`
`storage and in particular to a network architecture for facilitating secure data exchange over a
`
`decentralized computer network and data storage architecture.
`
`2.
`
`BACKGROUND OF THE INVENTION
`
`[0003]
`
`The Internet (including the Web) enables users of computers to quickly and easily
`
`exchange data. There is a wide range of applications that leverage this ability to exchange data to
`
`achieve powerful results for individuals and enterprises alike. Examples include email, file
`
`sharing, home automation, entertainment, data management, and more.
`
`[0004]
`
`However, the way that data is exchanged over the Internet makes the data, and those
`
`who send the data, vulnerable to malicious actors. For instance, data moving between parties or
`
`

`

`stored on a remote server typically include information associated with the sender and the
`
`recipient. Accordingly, an interceptor of the data may associate the data with the parties. If the
`
`data contain sensitive information, it may leave the parties open to identity theft or other
`
`malicious acts. As a result, many users are discouraged from sharing important information via
`
`the Internet, thereby missing out on many of the advantages that are afforded to computer users.
`
`SUMMARY OF THE INVENTION
`
`[0005]
`
`According to embodiments of the invention, a method for performing an action
`
`responsive to detecting an event in a dead drop (DD) domain is described. The method includes
`
`monitoring, by a node in the DD domain, for an occurrence of a specified event within the DD
`
`domain. The method further includes detecting the occurrence of the specified event within the
`
`DD domain. The method further includes performing a specified action in response to detecting
`
`the occurrence of the specified event within the DD domain.
`
`[0006]
`
`According to embodiments of the invention, a system for exchanging data between a
`
`sender and a recipient is described. The system includes a processor for executing computer
`
`program instructions. The system also includes a non-transitory computer-readable storage
`
`medium storing computer program instructions executable by the processor to perform steps.
`
`The steps include monitoring, by a node in the DD domain, for an occurrence of a specified
`
`event within the DD domain. The steps further include detecting the occurrence of the specified
`
`event within the DD domain. The steps further include performing a specified action in response
`
`to detecting the occurrence of the specified event within the DD domain.
`
`[0007]
`
`According to embodiments of the invention, a non-transitory computer-readable
`
`storage medium storing computer program instructions for exchanging data between a sender
`
`and a recipient. The computer program instructions are executable to perform steps. The steps
`
`

`

`include monitoring, by a node in the DD domain, for an occurrence of a specified event within
`
`the DD domain. The steps further include detecting the occurrence of the specified event within
`
`the DD domain. The steps further include performing a specified action in response to detecting
`
`the occurrence of the specified event within the DD domain.
`
`BRIEF DESCRIPTION OF DRAWINGS
`
`[0008]
`
`FIG. 1 is a high-level block diagram illustrating an example of passing data using a
`
`dead drop network architecture according to one embodiment.
`
`[0009]
`
`FIG. 2 is a high-level block diagram illustrating a detailed view of the dead drop
`
`domain of FIG. 1 according to one embodiment.
`
`[0010]
`
`FIG. 3 is a high-level block diagram illustrating an example of a dead drop storage
`
`node according to one embodiment.
`
`[0011]
`
`FIG. 4 is a flowchart illustrating steps for using a dead drop to pass data from a
`
`sender to a recipient according to one embodiment.
`
`[0012]
`
`FIG. 5 is a flowchart illustrating steps for using a DD to monitor events and perform
`
`actions if an event is detected according to one embodiment.
`
`[0013]
`
`FIG. 6 is a high-level block diagram illustrating an example of two nodes establishing
`
`a direct connection according to one embodiment.
`
`[0014]
`
`FIG. 7 is a high-level block diagram illustrating physical components of a computer
`
`used as part or all of one or more of the entities described herein in one embodiment.
`
`DETAILED DESCRIPTION
`
`[0015]
`
`The Figures (FIGS.) and the following description describe certain embodiments by
`
`way of illustration only. One skilled in the art will readily recognize from the following
`
`

`

`description that alternative embodiments of the structures and methods illustrated herein may be
`
`employed without departing from the principles described herein. Reference will now be made
`
`to several embodiments, examples of which are illustrated in the accompanying figures.
`
`[0016]
`
`It is noted that wherever practicable similar or like reference numbers may be used in
`
`the figures and may indicate similar or like functionality. This description occasionally uses
`
`reference numbers in combination with letters to designate items illustrated in the figures.
`
`Herein, a reference number used without an accompanying letter (e.g., “150”) references any or
`
`all instances of the designated item, while a reference number used with an accompanying letter
`
`(e.g., “150A”) refers to the specific item designated with that label in the figure.
`
`[0017]
`
`FIG. 1 is a high-level block diagram illustrating an example of passing data using a
`
`dead drop network architecture according to one embodiment. FIG. 1 illustrates a recipient 110
`
`in communication with a sender 120 via a dead drop (DD) domain 130. FIG. 1 describes a
`
`unidirectional data pass between a single sender 120 and a single recipient llO. Embodiments
`
`can have multiple senders 120 and recipients llO engaged in bidirectional one-to-one and one-
`
`to-many communications.
`
`[0018]
`
`Briefly, the recipient 110 uses the DD domain 130 to establish a communication
`
`channel that can be used to pass data to the recipient. The recipient 110 provides the sender 120
`
`with a dead drop identifier (DDID) referencing a storage location within the DD domain. The
`
`sender 120, in turn, uses the DDID to pass data (e.g., send a message) to the recipient 110 via the
`
`DD domain 130. The data transmission from the sender 120 to the recipient 110 is secure in the
`
`sense that it is extremely difficult for a malicious actor or other third party to locate, intercept, or
`
`decipher the data. Thus, the DD network architecture is suited to communications where
`
`security and privacy concerns are paramount. In addition, the DD network architecture may be
`
`

`

`used to provide enhanced security for general purpose communications.
`
`[0019]
`
`In one embodiment, the recipient 110 includes software executing on a computer used
`
`by a user (e.g., a person) to perform tasks such as communicating with other users via the DD
`
`domain 130 or via other communication networks. For example, the recipient 110 may include
`
`software executing on a desktop, notebook, or tablet computer, or another electronic device with
`
`computer functionality, such as a mobile telephone, music player, television set-top-box, home
`
`automation component, industrial equipment or connected appliance. The recipient 110 may
`
`include an input device such as a keyboard or touch-sensitive display that allows for the input of
`
`data and an output device such as a display or speaker that allows for the output of data.
`
`Functionality enabling the recipient 110 to communicate via the DD domain 130 may be
`
`embedded into the hardware of the recipient 110 and/or included in software executed by the
`
`recipient l 10.
`
`[0020]
`
`Similarly, the sender 120 includes a computer used by a user to perform tasks
`
`including communicating with other users via the DD domain 130 or via other communication
`
`networks. The sender 120 may include the same components as the recipient 110. In fact, the
`
`sender 120 may act as a recipient 110 and vice versa, depending upon the direction of data flow
`
`in a given communication transaction. The users who respectively use the recipient 110 and
`
`sender 120 to communicate can be different people or the same person.
`
`[0021]
`
`The recipient 110 and sender 120 are connected to the DD domain 130 via respective
`
`communications links 150A, 150B. The communication links 150 may include network
`
`communication links using conventional computer networking technologies. For example, the
`
`communications links 150 may use wired or wireless network communications technologies
`
`such as the wired and wireless forms of Ethernet. Likewise, the communication links 150 may
`
`

`

`use other communications technologies designed to support communication with local
`
`peripherals, such as Universal Serial Bus (USB), Thunderbolt, Bluetooth, Personal Area
`
`Network (PAN), Serial ATA, infrared, heat signatures, and/or sound. The communications links
`
`150 may be encrypted using any encryption technologies such as secure sockets layer (S SL),
`
`transport layer security (TLS), HTTP Secure (HTTPS), virtual private networks (VPNs), Internet
`
`Protocol security (IPsec), etc. In another embodiment, communication uses custom and/or
`
`dedicated data communications technologies instead of, or in addition to, the ones described
`
`above.
`
`[0022]
`
`The DD domain 130 is a collection of one or more DD nodes 140 (labeled as nodes
`
`l4OA-L in FIG. 1). A DD node 140 includes functionality for acting in the DD domain 130 and
`
`a memory for storing data within the domain. A typical DD domain 130 includes many DD
`
`nodes 140. Each node 140 is connected to one or more other nodes via DD communication links
`
`160. The DD communication links 160 may use the same communication technologies as the
`
`communication links 150 used by the recipient 110 and sender 120 to connect to the DD domain
`
`130. In one embodiment, the DD nodes 140 and DD communication links 160 are arranged
`
`within the DD domain 130 such that every node is reachable by every other node. In another
`
`embodiment, the DD nodes 140 are logically or physically partitioned so that some nodes cannot
`
`reach other nodes. The path connecting two DD nodes 140 may pass through one or more
`
`intermediate nodes. In addition, the recipient 150A and sender 150B communication links
`
`respectively connect the recipient 110 and the sender 120 to at least one DD node 140 within the
`
`DD domain 130. The recipient 110 and sender 120 may also communicate with each other using
`
`other communication links that do not pass through the DD domain 130, such as a
`
`communications link 170.
`
`

`

`[0023]
`
`To receive data using the DD domain 130, the recipient llO sends a request to the DD
`
`domain 130 to create a DD on behalf of the recipient. A DD node 140 within the domain 130
`
`receives the create request and either services the request or selects another node to service the
`
`request. For example, the DD node 140 that receives the request may randomly select another
`
`node within the DD domain 130 and pass the request to the selected node. The random selection
`
`may occur in a manner such that the node that receives the request does not know which node
`
`ultimately services the request.
`
`[0024]
`
`The node 140 that services the request to create the DD establishes a DDID that
`
`uniquely identifies the created DD. In addition, the node 140 establishes a set of tokens
`
`associated with the DDID. A token describes the access rights a possessor of the token has with
`
`respect to the created DD. For example, an embodiment includes a read token giving a possessor
`
`of the token the right to read from the DD identified by the associated DDID and a write token
`
`giving the right to write to the DD identified by the associated DDID. The node 140 that
`
`services the request provides the DDID and the associated tokens to the recipient 110.
`
`[0025]
`
`The recipient llO typically stores the DDID and associated tokens in a secure
`
`manner. For example, the recipient 110 may store the DDID and tokens in an encrypted data
`
`store at the recipient. The recipient 110 provides the DDID and the write token to the sender 120
`
`via a communications link 170. This communications link 170 may be a secure or unsecure link,
`
`and may include communication over the Internet and/or dedicated communications links. For
`
`example, the recipient 110 may use encrypted or unencrypted email to send the DDID and write
`
`token to the sender 120. Alternatively, the recipient may use a different electronic
`
`communications technique, such as short-range wireless communications, or even use non-
`
`electronic techniques to exchange the information (e.g., a pen and paper). In one embodiment,
`
`

`

`the DDID and one or more tokens are combined and may be encrypted or encoded (e.g., by a
`
`hashing function) to form a single code. In this embodiment, the recipient 110 may share the
`
`code with the sender 120 instead of sharing the DDID and write token separately. The code may
`
`be decoded, for example by the sender 120 or at a DD node 140, to determine the DDID and
`
`token.
`
`[0026]
`
`In addition, the recipient 110 and sender 120 may choose to encrypt the data sent by
`
`the sender using one or more symmetric or asymmetric encryption techniques. The recipient 110
`
`and sender 120 may choose to exchange encryption keys, if necessary, at the same time the
`
`recipient 110 provides the DDID and write token to the sender 120. Alternatively, the recipient
`
`110 and sender 120 may exchange encryption keys at different times, may use encryption
`
`techniques that do not require a key exchange, or may choose not to encrypt the data. In one
`
`embodiment, the DD domain 130 itself is used to perform the key exchange needed to facilitate
`
`an encrypted communications link.
`
`[0027]
`
`The sender 120 uses the DDID and associated write token to send data to the recipient
`
`110. In one embodiment, the sender 120 sends a write request to the DD domain 130 that
`
`includes the DDID and the write token. In another embodiment, the write request includes the
`
`DDID and data representing the write token. The data representing the write token may be
`
`encrypted (e.g., by hashing, obfuscation, etc.). This request is received by an initial DD node 140
`
`in the DD domain 130. The receiving node 140 determines whether it has the DD identified by
`
`the DDID. If not, the receiving node 140 sends a message containing the DDID and the write
`
`token to the other nodes within DD domain 130. The node 140 storing the DD associated with
`
`the DDID receives the message and verifies the write token. If the token verifies, the node
`
`storing the DD creates a connection with the receiving node, which in turn has a connection with
`
`

`

`the sender 120. The sender 120 then writes the data to the node storing the DD associated with
`
`the DDID.
`
`[0028]
`
`Similarly, the recipient 110 uses the DDID and associated read token to read data
`
`from the DD. In one embodiment, the recipient llO sends a read request to the DD domain 130
`
`that includes the DDID and the read token. In another embodiment, the read request includes the
`
`DDID and data representing the read token. The data representing the read token may be
`
`encrypted (e.g., by hashing, obfuscation, etc.). This request is received by an initial DD node 140
`
`in the DD domain 130. The receiving node 140 determines whether it has the DD identified by
`
`the DDID. If not, the receiving node 140 broadcasts a message containing the DDID and the
`
`read token the other nodes within the DD domain 130. The node 140 storing the DD associated
`
`with the DDID receives the message and verifies the read token. If the token verifies, the node
`
`140 storing the DD creates a connection with the receiving node, which in turn has a connection
`
`with the recipient. The recipient 110 then reads the data from the node storing the DD associated
`
`with the DDID.
`
`[0029]
`
`Thus, the DD network architecture described above permits secure and private
`
`communications between the recipient 110 and the sender 120. The sender 120, and/or other
`
`parties possessing the DDID and write token can send data to the recipient. However, such
`
`parties cannot read the data from the DD. Moreover, a malicious actor who obtains access to one
`
`or more nodes 140 in the DD domain 130 may be able to obtain or read data stored in individual
`
`DDs. But the malicious actor cannot determine the intended recipients of the data because there
`
`is no mapping of DDIDs to recipients. For the same reason, the malicious actor cannot
`
`determine the path between a sender and a recipient. In addition, the data stored in the DDs may
`
`be encrypted.
`
`

`

`[0030]
`
`FIG. 2 is a high-level block diagram illustrating a detailed view of the DD domain
`
`130 of FIG. 1 according to one embodiment. As described above, the domain 130 typically
`
`includes multiple DD nodes 140 connected by DD communication links 160. The individual
`
`nodes 140 within the DD domain 130 may be formed of physically separate computers, such as a
`
`collection of geographically disparate computers. In addition, some or all of the nodes may be
`
`formed of virtual computers. For example, the nodes 140 of a domain 130 may be instances of
`
`virtual computers hosted in a cloud environment.
`
`[0031]
`
`Each DD node 140 has an associated set of characteristics that describe attributes of
`
`the node. The characteristics may describe the location of the node 140. The location may be
`
`specified as a geographic location. In addition, the location may be specified as a logical
`
`location (e.g., a “zone”). For example, the logical location may indicate that the node is
`
`associated with a particular enterprise (e.g., a business) or other group. The characteristics may
`
`also describe physical properties of the node, such as a node’s processing power, storage
`
`capacity, uptime, and the like.
`
`[0032]
`
`In one embodiment, the set of DD nodes 140 in a DD domain 130 may be divided
`
`into multiple subdomains, with each subdomain including a proper subset of nodes from the set
`
`of DD nodes in the DD domain. The subdomains to which a node 140 is member may be
`
`determined based on the characteristics of the node. For example, the DD domain 130 may
`
`include nodes 140 distributed over a wide geographic area (e.g., a country), and a subdomain
`
`may include nodes physically located within a smaller area (e.g., a state within the country).
`
`Similarly, the DD domain 130 may include nodes 140 associated with multiple enterprises, and a
`
`subdomain may include only nodes associated with one of the enterprises or a part of an
`
`enterprise.
`
`lO
`
`

`

`[0033]
`
`In one embodiment, the DD nodes 140 are arranged as a mesh network. Each node
`
`140 is connected to at least one other node via a DD communication link 160. Moreover, each
`
`node 140 maintains a routing table identifying the nodes to which it is connected. A node 140
`
`can send a message to another node by forwarding the message to the nodes to which it is
`
`connected. The nodes 140 that receive the message in turn forward the message to other nodes,
`
`until the message reaches the node to which it is directed. The path followed by the message is
`
`formed of hops from node 140 to node along the DD communication links 160.
`
`[0034]
`
`Consider the communications between the sender 120 and the recipient llO described
`
`in FIG. 1 in the context of FIG. 2. As shown in FIG. 2, the recipient 110 is connected to a node
`
`140A of the domain 130 via a communication link 150A. This node 140A serves as the point of
`
`ingress to the domain 130 for the recipient. The recipient llO sends a request to the ingress node
`
`140A of the domain 130 to create a DD on behalf of the recipient. This request may include
`
`domain information specifying a particular subdomain in which the DD should be created. For
`
`example, the domain information may specify that the DD should be created in a node 140
`
`located in a particular geographic area or managed by a particular enterprise.
`
`[0035]
`
`The node 140A serving as the point of ingress for the recipient 110 receives the create
`
`request and analyzes the domain information to identify the subdomain in which the DD should
`
`be created. In one embodiment, the node 140A services the request by randomly selecting a
`
`node within the specified subdomain that will host the DD. In one embodiment, random
`
`selection is performed using a load balancing technique, which may be performed by the node
`
`140A or by a separate computing device. In one embodiment, the node 140 services the request
`
`by randomly selecting a number of node hops for which the request will be forwarded, and
`
`randomly selecting another node within the specified subdomain to which the node 140A is
`
`ll
`
`

`

`connected. The ingress node 140A then forwards the request to the randomly selected node
`
`(e.g., node 140D) and also forwards the selected value for the number of node hops. The node
`
`140D to which the request was forwarded randomly selects another node (e.g., node 140E) in the
`
`subdomain from its routing table, decrements the value for the number of node hops, and
`
`forwards the request to the selected node. This selection, decrement, and forward process
`
`repeats until the value for the number of node hops reaches zero, at which point the final node
`
`establishes and hosts the DD associated with the request from the recipient 110. In one
`
`embodiment, each node that forwards the create request includes the path from the ingress node
`
`150A to the forwarding node with the request. The final node that creates the DD uses the path
`
`to identify and contact the ingress node 140A for the recipient 110. For example, the node 140
`
`may use the path to send the DDID and associated tokens to the ingress node 140A, so that the
`
`latter node can provide this information to the recipient.
`
`[0036]
`
`For example, assume the ingress node 140A receives a create request from the
`
`recipient 110, and also assume that the request specifies a subdomain encompassing nodes 140A,
`
`140D and 140E, as well as other nodes within the domain 130. Also assume the ingress node
`
`140A randomly selects “2” as the number of hops. The ingress node randomly selects a node
`
`(e.g., node 140D) from the specified subdomain in its routing table, decrements the hop value,
`
`and forwards the request and decremented hop value (e.g., “1”) to the selected node. That node
`
`140D, in turn, randomly selects another node (e.g., node 140E), decrements the hop value, and
`
`forwards the request and decremented hop value (e.g., “0”) to the selected node. The final node
`
`140E evaluates the hop value and determines that it is “0” and, therefore, creates the DD and
`
`associated tokens. The final node 140E then returns the DDID and tokens to the ingress node
`
`140A via the reverse of the path used to reach the final node.
`
`12
`
`

`

`[0037]
`
`Variations on the techniques described above may be used in some embodiments. In
`
`one embodiment, a node forwarding a request decrements the hop value only if the node is
`
`within the specified subdomain. This variation may be used, for example, in situations in which
`
`a node receiving a create request is not within the specified subdomain and/or connected to any
`
`other nodes in the subdomain. In this situation, the nodes may randomly forward the request to
`
`other nodes until a node within the specified subdomain receives the request, at which point the
`
`node in the subdomain decrements the hop value and forwards the request anew if the hop value
`
`is greater than zero or creates the DD and associated tokens if the hop value is zero.
`
`[0038]
`
`The sender 120, in turn, is connected to a different node l4OL that serves as the point
`
`of ingress for the sender to the domain 130 via a different communication link 150B. When the
`
`sender 120 makes a write request, the sender provides the DDID and write token to the sender’s
`
`ingress node l4OL. This node l4OL forwards the request including the DDID and write token to
`
`the other nodes in its routing table, and the other nodes continue to forward the request until it
`
`reaches the node having the DD associated with the DDID (e.g., node 140E). This node 140E
`
`verifies the token and establishes a connection with the sender’s ingress node l4OL using a
`
`return path created by the forwarding nodes. Alternatively, the node 140E may establish a direct
`
`connection with the sender 120. The sender 120 provides the data to be written to the ingress
`
`node l4OL, and that node forwards the data to the node 140E having the DD via the connection.
`
`A read request made by the recipient 110 is handled in a similar fashion in one embodiment,
`
`except that the recipient reads data from, rather than writes data to, the node 140E having the
`
`DD.
`
`[0039]
`
`FIG. 3 is a high-level block diagram illustrating an example of a DD node 140
`
`according to one embodiment. The node 140 includes a routing module 305, creation module
`
`13
`
`

`

`310, write module 3 15, read module 320, time-to-live (TTL) module 325, data control module
`
`330, delete module 335, notification module 340, geo-fence module 345, and data storage 390.
`
`Other embodiments may include different or other modules in other embodiments. In addition,
`
`the behaviors of the modules may differ in other embodiments.
`
`[0040]
`
`The data storage 390 stores data used by the node 140. The data may include data
`
`being maintained in DDs managed by the node 140, DDIDs and tokens associated with the DDs,
`
`and information used by the modules within the node 140 to perform the tasks described herein.
`
`Depending upon the embodiment, the data storage 390 may include one or more types of non-
`
`transitory computer-readable persistent storage media. For example, the data storage 390 may
`
`include a hard drive, solid-state memory device, and/or other form of persistent memory.
`
`[0041]
`
`Turning now to the individual modules within the node 140, the routing module 305
`
`routes messages received by node 140. As part of this task, an embodiment of the routing
`
`module 305 maintains the routing table for the node 140. The routing module 305 periodically
`
`communicates with other nodes 140 to which it is connected to ascertain information about those
`
`nodes. This information may include, for example, network addresses of the nodes, information
`
`about the subdomains with which the nodes 140 are associated, and the like. The routing module
`
`305 stores this information about the connected nodes in the routing table. In addition, the
`
`routing module 305 responds to routing table-related communications from routing modules 305
`
`of other nodes 140.
`
`[0042]
`
`The messages handled by the routing module 305 include messages related to create
`
`requests, write requests, read requests, and other types of messages and requests described
`
`herein. For a given message, the routing module 305 analyzes the message to determine whether
`
`to process the message locally on the node 140 or to route the message to another node in the
`
`14
`
`

`

`routing table. For example, upon receiving a create request from another node, the routing
`
`module 305 examines the hop value to determine whether it is greater than zero. If the hop value
`
`is greater than zero, the routing module 305 decrements the hop value, randomly selects a
`
`connected node in the routing table (subject to any specified subdomain constraints, if
`
`applicable), and forwards the request and decremented hop value to the selected node. If the hop
`
`value is zero, the routing module 305 provides the request to the creation module 310.
`
`[0043]
`
`Similarly, upon receiving a write request, the routing module 305 determines whether
`
`the DDID is associated with a DD maintained by the node 140. If the DDID is not associated
`
`with a DD maintained by the node 140, the routing module 305 forwards the request to other
`
`nodes in its routing table.
`
`If, on the other hand, the DDID is associated with a DD maintained by
`
`the node, the routing module 305 provides the request to the write module 315. The routing
`
`module 305 handles read requests, as well as other requests described herein, in the same
`
`fashion.
`
`[0044]
`
`The creation module 310 creates DDs in response to requests received by the node
`
`140. Upon receiving a create request from the routing module 305, the creation module 310
`
`generates a DDID to represent the DD for the request. In addition, the creation module 310
`
`generates a set of tokens associated with the DDID. The creation module 310 provides the
`
`DDID and tokens to the recipient l 10 that requested the DD using the path to the recipient’s
`
`ingress node 140A as described with respect to FIGS. 1 and 2.
`
`[0045]
`
`In one embodiment, the creation module 310 generates the DDID as a globally unique
`
`identifier (GUID). The DDID is a value represented using a large number of bits (e.g., a 128-bit
`
`value). A small portion of the bits may be fixed to identify the value as a DDID or encode other
`
`information, while the other bits are randomly generated by the creation module 310. The large
`
`15
`
`

`

`number of bits makes it extremely unlikely that the same DDID would be generated for multiple
`
`DDs. Therefore, each DDID is unique for practical purposes. The DDID may be represented as
`
`sequence of hexadecimal digits.
`
`[0046]
`
`In one embodiment, the tokens generated by the creation module 310 may include a
`
`write token, a read token, and an owner token. The write and read tokens respectively provide
`
`the bearer of the token the rights to write data to, and read data from, the DD associated with the
`
`DDID as described above. The owner token provides the bearer with administrative rights to the
`
`DD, such as the right to delete data within the DD or delete the entire DD.
`
`[0047]
`
`In one embodiment, a token, like the DDID, is a value represented using a large
`
`number of bits, some of which may be fixed and others of which are randomly generated by the
`
`creation module 310. The number of bits in each token may be fewer than the number of bits in
`
`the DDID. Each token associated with a particular DDID is unique with respect to other tokens
`
`associated with that DDID.
`
`[0048]
`
`The creation module 310 allocates space in the data storage 390 for the created DD
`
`and associates this space with the DDID. The amount of space, and the time when the space is
`
`allocated may vary in different embodiments. In one embodiment the creation module 310
`
`allocates a fixed amount of storage space for the DD when creating the DD. In another
`
`embodiment, the creation module 310 allocates the storage space later, when receiving data to
`
`store in the DD. Likewise, the amount of space allocated for the DD can vary in different
`
`embodiments.
`
`[0049]
`
`The write module 3 15 writes data to DDs in response to write requests received by
`
`the node 140. Upon receiving a write request from the routing module 305, the write module
`
`3 15 initially verifies the write token included in the request. The write module 3 l5 identifies the
`
`16
`
`

`

`DDID and write token included in the request, and compares the write token to the stored write
`
`token created by the creation module 310 for the DDID. If the compared write tokens do not
`
`match, the write module 315 denies the write request. Depending upon the embodiment, the
`
`write module 315 can deny the request by acting as if the request was not received (i.e., by not
`
`sending any messages in response to the write request) or by sending a message to the sender
`
`120 indicating that the write token is invalid.
`
`[0050]
`
`If the compared write tokens match, the write module 315 uses the return path in the
`
`write request to open a network connection with the ingress node 14OL for the sender 120. The
`
`write module 315 receives data from the sender of the write request, and writes the data to the
`
`storage allocated for the DD identified by the DDID. In one embodiment, the write module 315
`
`stores the data in a DD as a series of discrete messages, such that the data for each write request
`
`to a DD is saved as a logically separate message. The stored messages for the DD are organized
`
`in a queue or another data structure.
`
`[0051]
`
`The read module 320 reads data from DDs in response to read requests received by
`
`the node 140. Upon