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: Secure marshaling of data via one or more intermediate processes is provided. A source process may create a named shared memory section resulting in a first handle to the shared memory section. The source process may populate the shared memory section with information. An access control list may secure the shared memory section by preventing the one or more intermediate processes from accessing content of the shared memory section, while allowing a target process to access the content. The first handle and a name of the shared memory section may be marshaled to a first intermediate process resulting in a respective new handle to the shared memory section. A last intermediate process may marshal the name to a target process, which may use the name to obtain access to the content of the shared memory section.

Abstract: Secure marshaling of data via one or more intermediate processes is provided. A source process may create a named shared memory section resulting in a first handle to the shared memory section. The source process may populate the shared memory section with information. An access control list may secure the shared memory section by preventing the one or more intermediate processes from accessing content of the shared memory section, while allowing a target process to access the content. The first handle and a name of the shared memory section may be marshaled to a first intermediate process resulting in a respective new handle to the shared memory section. A last intermediate process may marshal the name to a target process, which may use the name to obtain access to the content of the shared memory section.

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: 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: The invention relates to a method, system, network node and computer program for processing packet data in a communication network, which comprises at least a first network node. In the method a first packet is received at the first network node. In the first network node is assigned for the first packet a chain comprising at least two logical service entities based on at least one service determination rule. A data unit comprising at least part of the first packet is formed. The data unit is processed in at least one logical service entity in the chain and a second packet is transmitted from the first network node comprising data sent by at least one logical service entity in the chain. The benefits of the invention relate to improved flexibility in introducing new value-added service for packet data and improved performance in the first network node.