Abstract: A Distributed Routing Table (DRT) mesh can comprise two or more nodes, each of which maintains its own routing table that represents some or all of the overall routing knowledge of the DRT mesh. Each node can be comprised of modular components that can perform various defined functions such that the features and abilities of the node can be customized by an application based on which modular components are instantiated. A routing table management module can maintain individual routing tables at each node, and can ensure that only entries that are close to the node, in a network topology sense, are maintained in the routing table. In addition, a security module can verify received messages based on an agreed-upon root certificate.

Abstract: Application programming interface (API) for starting and accessing distributed routing table (DRT) functionality. The API facilitates bootstrapping into the DRT by one or more devices of a group of devices (a mesh) seeking to collaborate over a serverless connection, establishing a node of the DRT, where each node is an instance of an application that is participating in the mesh, and node participation by allowing the application to search for keys published by other nodes in the mesh, or by becoming part of the mesh by publishing a key. The API facilitates optimization of the routing table for quickly finding a root of a specific key in the mesh by finding the key directly in a cache or by asking a root node of the key that is in the local routing table that is closest numerically to the key being searched.

Abstract: An application program interface (API) for sending and receiving endpoint registration data and peer-to-peer network cloud data has a registration call for adding endpoint data to a peer-to-peer network. The API may receive explicit data regarding address information or may be instructed to select and maintain suitable address information as the topology of the peer-to-peer network changes. Blocking and non-blocking calls are exposed for retrieving information peer-to-peer network endpoint data.

Abstract: Application programming interface (API) for starting and accessing distributed routing table (DRT) functionality. The API facilitates bootstrapping into the DRT by one or more devices of a group of devices (a mesh) seeking to collaborate over a serverless connection, establishing a node of the DRT, where each node is an instance of an application that is participating in the mesh, and node participation by allowing the application to search for keys published by other nodes in the mesh, or by becoming part of the mesh by publishing a key. The API facilitates optimization of the routing table for quickly finding a root of a specific key in the mesh by finding the key directly in a cache or by asking a root node of the key that is in the local routing table that is closest numerically to the key being searched.

Abstract: Application programming interface (API) for starting and accessing distributed routing table (DRT) functionality. The API facilitates bootstrapping into the DRT by one or more devices of a group of devices (a mesh) seeking to collaborate over a serverless connection, establishing a node of the DRT, where each node is an instance of an application that is participating in the mesh, and node participation by allowing the application to search for keys published by other nodes in the mesh, or by becoming part of the mesh by publishing a key. The API facilitates optimization of the routing table for quickly finding a root of a specific key in the mesh by finding the key directly in a cache or by asking a root node of the key that is in the local routing table that is closest numerically to the key being searched.

Abstract: A Distributed Routing Table (DRT) mesh can comprise two or more nodes, each of which maintains its own routing table that represents some or all of the overall routing knowledge of the DRT mesh. Each node can be comprised of modular components that can perform various defined functions such that the features and abilities of the node can be customized by an application based on which modular components are instantiated. A routing table management module can maintain individual routing tables at each node, and can ensure that only entries that are close to the node, in a network topology sense, are maintained in the routing table. In addition, a security module can verify received messages based on an agreed-upon root certificate.

Abstract: A Distributed Routing Table (DRT) mesh can comprise two or more nodes, each of which maintains its own routing table that represents some or all of the overall routing knowledge of the DRT mesh. Each node can be comprised of modular components that can perform various defined functions such that the features and abilities of the node can be customized by an application based on which modular components are instantiated. A routing table management module can maintain individual routing tables at each node, and can ensure that only entries that are close to the node, in a network topology sense, are maintained in the routing table. In addition, a security module can verify received messages based on an agreed-upon root certificate.

Abstract: The claimed method and system provides a method and interface for enabling an existing, single-transport P2P API to communicate with nodes of a P2P network using multiple different transport protocols.

Abstract: A system, apparatus, method, and computer-readable medium are provided for resolving a name to a network endpoint. According to one method, naming providers are registered with a computer system that are operative to resolve names to network endpoints for one or more domains. A provider can claim to be a primary provider or a secondary provider for a domain. A provider can also register as a wildcard provider. Once the providers have been registered, requests may be received to resolve an e-mail address into a network address of the corresponding computer system. In response to such a request, one or more of the registered providers are identified as being able to resolve names in the domain to network addresses. Requests are transmitted to the identified providers requesting that they resolve the e-mail address to a corresponding network address. The manner in which the requests are made depends upon whether authoritative results are required.

Abstract: Application programming interfaces and methods that provide group management in a peer-to-peer (P2P) network are provided. More specifically, new and improved P2P application programming interfaces (APIs) and methods for the creation and access of groups, the retrieval of member and group information, the addition, modification, deletion and management of records (data), the importation and exportation of group data, the direct communication between members, the addition of a security provider to a group, the setting and retrieval of presence information, the registering for event notifications, and other utility and support functions are presented. Each of these interfaces utilize various parameters that are passed in from an application program that uses these interfaces to manage and utilize groups. The interfaces return a value that indicates the success or failure of the function. For failures, the interfaces provide an indication as to the problem resulting in the failure.

Abstract: A computer implemented method and system enable users to share files in a server-less shared space. By providing access to such spaces via a visual presentation, the system renders content available for access by other group members. Access is sometimes provided through propagation of metadata or other uniquely identifying indicia associated with the shared space to all group members.

Abstract: Communication functionality is described for conducting communication among a plurality of participants in peer-to-peer fashion. The communication functionality comprises peer-to-peer overlay functionality configured to establish a peer-to-peer overlay network that includes a plurality of participants. The peer-to-peer overlay functionality relies on endpoint provider functionality for physically exchanging information among the plurality of participants in the peer-to-peer overlay network. The endpoint provider functionality exchanges information using a transport mechanism. The transport mechanism accommodates multiple different transport protocols for exchanging information among the plurality of participants, allowing different pairs of participants to communicate with each other using different respective transport protocols.

Abstract: A Distributed Routing Table (DRT) mesh can comprise two or more nodes, each of which maintains its own routing table that represents some or all of the overall routing knowledge of the DRT mesh. Each node can be comprised of modular components that can perform various defined functions such that the features and abilities of the node can be customized by an application based on which modular components are instantiated. A routing table management module can maintain individual routing tables at each node, and can ensure that only entries that are close to the node, in a network topology sense, are maintained in the routing table. In addition, a security module can verify received messages based on an agreed-upon root certificate.

Abstract: Application programming interfaces and methods that provide graph management in a peer-to-peer (P2P) network are provided. More specifically, new and improved P2P application programming interfaces (APIs) and methods for the creation and access of graphs, the retrieval of node and graph information, the addition, modification, deletion and management of records (data), the importation and exportation of graph data, the direct communication between graph nodes, the addition of a security provider to a graph, the setting and retrieval of presence information, the registering for event notifications, and other utility and support functions are presented. Each of these interfaces utilize various parameters that are passed in from an application program that uses these interfaces to manage and utilize graphs. The interfaces return a value that indicates the success or failure of the function. For failures, the interfaces provide an indication as to the problem resulting in the failure.

Abstract: Application programming interface (API) for starting and accessing distributed routing table (DRT) functionality. The API facilitates bootstrapping into the DRT by one or more devices of a group of devices (a mesh) seeking to collaborate over a serverless connection, establishing a node of the DRT, where each node is an instance of an application that is participating in the mesh, and node participation by allowing the application to search for keys published by other nodes in the mesh, or by becoming part of the mesh by publishing a key. The API facilitates optimization of the routing table for quickly finding a root of a specific key in the mesh by finding the key directly in a cache or by asking a root node of the key that is in the local routing table that is closest numerically to the key being searched.

Abstract: A system, apparatus, method, and computer-readable medium are provided for resolving a name to a network endpoint. According to one method, naming providers are registered with a computer system that are operative to resolve names to network endpoints for one or more domains. A provider can claim to be a primary provider or a secondary provider for a domain. A provider can also register as a wildcard provider. Once the providers have been registered, requests may be received to resolve an e-mail address into a network address of the corresponding computer system. In response to such a request, one or more of the registered providers are identified as being able to resolve names in the domain to network addresses. Requests are transmitted to the identified providers requesting that they resolve the e-mail address to a corresponding network address. The manner in which the requests are made depends upon whether authoritative results are required.

Abstract: An application program interface (API) for sending and receiving endpoint registration data and peer-to-peer network cloud data has a registration call for adding endpoint data to a peer-to-peer network. The API may receive explicit data regarding address information or may be instructed to select and maintain suitable address information as the topology of the peer-to-peer network changes. Blocking and non-blocking calls are exposed for retrieving information peer-to-peer network endpoint data.

Abstract: A simple record query language (SRQL) is a generic record meta-data query solution that can natively describe the information contained in a record and search each against it to find records whose meta-data matches a particular set of criteria. SRQL includes both a record data structure that includes searchable SRQL attributes that describe the record, and queries that are able to search the attributes. The attributes are an XML node that exists in the record header itself. There are two types of queries, to wit local to find records in the local data store, and distributed to find records that may be stored in a neighbor's data store. As such, SRQL finds particular applicability to peer-to-peer networks.

Abstract: Communication functionality is described for conducting communication among a plurality of participants in peer-to-peer fashion. The communication functionality comprises peer-to-peer overlay functionality configured to establish a peer-to-peer overlay network that includes a plurality of participants. The peer-to-peer overlay functionality relies on endpoint provider functionality for physically exchanging information among the plurality of participants in the peer-to-peer overlay network. The endpoint provider functionality exchanges information using a transport mechanism. The transport mechanism accommodates multiple different transport protocols for exchanging information among the plurality of participants, allowing different pairs of participants to communicate with each other using different respective transport protocols.

Abstract: The claimed method and system provides a method and interface for enabling an existing, single-transport P2P API to communicate with nodes of a P2P network using multiple different transport protocols.