Collaboration among resource-constrained hosts in a network to offload application functions

Abstract

A method performed by a computing device is disclosed to offload functions of an application from a main host for the application to other hosts in a network. The method includes obtaining information regarding resource requirements of a function of the application that is to be offloaded, obtaining information regarding capabilities of one or more hosts in the network, identifying a host from the one or more hosts that is capable of executing the function based on the information regarding the resource requirements of the function and the information regarding the capabilities of the one or more hosts in the network, and causing the function to be deployed on the identified host.

Description

SPECIFICATIONCOLLABORATION AMONG RESOURCE-CONSTRAINED HOSTS IN A NETWORK TO OFFLOAD APPLICATION FUNCTIONSTECHNICAL FIELD

[0001] Embodiments of the invention relate to the field of distributed computing; and more specifically, to collaboration among resource-constrained hosts in a network to offload application functions.BACKGROUND

[0002] Computational offloading refers to the transfer of resource-intensive computational tasks from a relatively resource-constrained device (e.g., a mobile phone or an Internet of Things (loT) device) to an external platform with more resources (e.g., a cloud computing platform or at a network edge).

[0003] The resource-constrained device is often under the control of an individual or smaller organization, while the external platform is typically under the control of a service provider and can perform tasks offloaded from multiple devices. Computational offloading provides additional computing power that can be used to achieve objectives that would be difficult, if not impossible, for resource-constrained devices to achieve on their own (e.g., due to their resource and / or energy constraints) such as simultaneous localization and mapping (SLAM) or online gaming.

[0004] Edge computing is a form of computational offloading that brings computation and data storage closer to the sources of data. The edge environment may be heterogeneous in that it may include a variety of different nodes having varying resources and architectures. The heterogeneity of the edge environment makes it difficult for application developers to offload tasks to the edge environment.

[0005] Internet of Things (loT) describes an environment that includes devices with sensors, processing ability, software and other technologies that connect and exchange data with other devices and systems over the Internet or other communications networks. loT devices such as smart watches, doorbell cameras, drones, and augmented reality glasses are typically lightweight (e.g., in terms of their capabilities), even compared to a typical mobile phone. Also, loT devices may require low-power operation (e.g., due to being powered by a battery and deployed in locations where it might be difficult to replace / recharge the battery), which discourages performing unnecessary computation on the loT devices. Also, loT devices have a high level ofheterogeneity due to their diverse nature (e.g., their resources and capabilities can vary depending on the specific use cases they were designed for).

[0006] An application developer that wishes to offload application tasks to a heterogenous environment has to write separate application code for each category of device, and potentially for each version of each device. This creates code redundancy and reduces code reusability, which increases the workload of the application developer.

[0007] The heterogeneous nature of the devices means that the application developer cannot assume that any device is capable of executing an offloaded task. To be able offload application tasks, the application developer has to know in advance which devices have the requisite capability to execute the different application tasks. However, it is not always possible for the application developer to know the capabilities of the devices that will be available for offloading in advance, and this prevents the application developer from being able to take advantage of computational offloading and the benefits that come therewith.SUMMARY

[0008] An embodiment is a method performed by a computing device to offload functions of an application from a main host for the application to other hosts in a network. The method includes obtaining information regarding resource requirements of a function of the application that is to be offloaded, obtaining information regarding capabilities of one or more hosts in the network, identifying a host from the one or more hosts that is capable of executing the function based on the information regarding the resource requirements of the function and the information regarding the capabilities of the one or more hosts in the network, and causing the function to be deployed on the identified host.

[0009] An embodiment is a non-transitory machine-readable medium comprising computer program code, which when executed by a computing device, causes the computing device to carry out operations for offloading functions of an application from a main host for the application to other hosts in a network. The operations include obtaining information regarding resource requirements of a function of the application that is to be offloaded, obtaining information regarding capabilities of one or more hosts in the network, identifying a host from the one or more hosts that is capable of executing the function based on the information regarding the resource requirements of the function and the information regarding the capabilities of the one or more hosts in the network, and causing the function to be deployed on the identified host.

[0010] An embodiment is a computing device configured to offload functions of an application from a main host for the application to other hosts in a network. The computingdevice includes one or more processors and a non-transitory machine-readable storage medium that stores instructions, which when executed by the one or more processors, causes the computing device to perform operations including obtaining information regarding resource requirements of a function of the application that is to be offloaded, obtaining information regarding capabilities of one or more hosts in the network, identifying a host from the one or more hosts that is capable of executing the function based on the information regarding the resource requirements of the function and the information regarding the capabilities of the one or more hosts in the network, and causing the function to be deployed on the identified host.

[0011] An embodiment is a method performed by a computing device implementing a first host in a network to execute a function of an application that is being offloaded from a main host for the application in the network. The method includes determining capabilities of the first host, advertising information regarding the capabilities of the first host to a capability advertisement service running in the network, receiving, from an application orchestrator, an instruction to deploy the function, wherein the application orchestrator determined that the function is to be offloaded to the first host based on a determination that the first host is capable of executing the function, and wherein the application orchestrator determined that the first host is capable of executing the function based on information regarding the capabilities of the first host that the application orchestrator received from the capability advertisement service. The method further includes obtaining portable bytecode of the function responsive to receiving the instruction to deploy the function and executing the portable bytecode of the function using a runtime engine installed on the first host.

[0012] An embodiment is a non-transitory machine-readable medium comprising computer program code, which when executed by a computing device implementing a first host in a network, causes the first host to carry out operations for executing a function of an application that is being offloaded from a main host for the application in the network. The operations include determining capabilities of the first host, advertising information regarding the capabilities of the first host to a capability advertisement service running in the network, receiving, from an application orchestrator, an instruction to deploy the function, wherein the application orchestrator determined that the function is to be offloaded to the first host based on a determination that the first host is capable of executing the function, and wherein the application orchestrator determined that the first host is capable of executing the function based on information regarding the capabilities of the first host that the application orchestrator received from the capability advertisement service. The operations further include obtaining portable bytecode of the function responsive to receiving the instruction to deploy the functionand executing the portable bytecode of the function using a runtime engine installed on the first host.

[0013] An embodiment is a computing device configured to implement a first host in a network to execute a function of an application that is being offloaded from a main host for the application in the network. The computing device includes one or more processors and a non- transitory machine-readable storage medium that stores instructions, which when executed by the one or more processors, causes the first host to perform operations including determining capabilities of the first host, advertising information regarding the capabilities of the first host to a capability advertisement service running in the network, receiving, from an application orchestrator, an instruction to deploy the function, wherein the application orchestrator determined that the function is to be offloaded to the first host based on a determination that the first host is capable of executing the function, and wherein the application orchestrator determined that the first host is capable of executing the function based on information regarding the capabilities of the first host that the application orchestrator received from the capability advertisement service. The operations further include obtaining portable bytecode of the function responsive to receiving the instruction to deploy the function and executing the portable bytecode of the function using a runtime engine installed on the first host.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:

[0015] Figure l is a diagram showing a system that includes a source code processor and a portable bytecode generator, according to some embodiments.

[0016] Figure 2 is a diagram showing a system that includes a capability advertisement service, according to some embodiments.

[0017] Figure 3 is a diagram showing a system that includes an application orchestrator, according to some embodiments.

[0018] Figure 4 is a diagram showing a system that includes a validity analysis service, according to some embodiments.

[0019] Figure 5 is a flow diagram of a method for processing metadata associated with source code of an application, according to some embodiments.

[0020] Figure 6 is a flow diagram of a method for offloading functions from a main host for the application to other hosts in a network, according to some embodiments.

[0021] Figure 7 is a flow diagram of a method for executing a function of an application that is being offloaded from a main host for the application in a network, according to some embodiments.

[0022] Figure 8 is a flow diagram of a method for implementing a validity timeframe for a sensor, according to some embodiments.

[0023] Figure 9 is a diagram showing connectivity between network devices (NDs) within an exemplary network, as well as three exemplary implementations of the NDs, according to some embodiments.DETAILED DESCRIPTION

[0024] The following description describes methods and apparatus for offloading functions of an application to hosts in a network. In the following description, numerous specific details such as logic implementations, opcodes, means to specify operands, resource partitioning / sharing / duplication implementations, types and interrelationships of system components, and logic partitioning / integration choices are set forth in order to provide a more thorough understanding of the present invention. It will be appreciated, however, by one skilled in the art that the invention may be practiced without such specific details. In other instances, control structures, gate level circuits and full software instruction sequences have not been shown in detail in order not to obscure the invention. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

[0025] References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0026] Bracketed text and blocks with dashed borders (e.g., large dashes, small dashes, dotdash, and dots) may be used herein to illustrate optional operations that add additional features to embodiments. However, such notation should not be taken to mean that these are the only options or optional operations, and / or that blocks with solid borders are not optional in certain embodiments.

[0027] In the following description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. “Coupled” is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, co-operate or interact with each other. “Connected” is used to indicate the establishment of communication between two or more elements that are coupled with each other.

[0028] An electronic device stores and transmits (internally and / or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and / or data using machine-readable media (also called computer-readable media), such as machine-readable storage media (e.g., magnetic disks, optical disks, solid state drives, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other form of propagated signals - such as carrier waves, infrared signals). Thus, an electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors (e.g., wherein a processor is a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, other electronic circuitry, a combination of one or more of the preceding) coupled to one or more machine-readable storage media to store code for execution on the set of processors and / or to store data. For instance, an electronic device may include non-volatile memory containing the code since the non-volatile memory can persist code / data even when the electronic device is turned off (when power is removed), and while the electronic device is turned on that part of the code that is to be executed by the processor(s) of that electronic device is typically copied from the slower nonvolatile memory into volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of that electronic device. Typical electronic devices also include a set of one or more physical network interface(s) (NI(s)) to establish network connections (to transmit and / or receive code and / or data using propagating signals) with other electronic devices. For example, the set of physical NIs (or the set of physical NI(s) in combination with the set of processors executing code) may perform any formatting, coding, or translating to allow the electronic device to send and receive data whether over a wired and / or a wireless connection. In some embodiments, a physical NI may comprise radio circuitry capable of receiving data from other electronic devices over a wireless connection and / or sending data out to other devices via a wireless connection. This radio circuitry may include transmitted s), received s), and / or transceiver(s) suitable for radiofrequency communication. The radio circuitry may convert digital data into a radio signal having the appropriate parameters (e.g., frequency,timing, channel, bandwidth, etc.). The radio signal may then be transmitted via antennas to the appropriate recipient(s). In some embodiments, the set of physical NI(s) may comprise network interface control ler(s) (NICs), also known as a network interface card, network adapter, or local area network (LAN) adapter. The NIC(s) may facilitate in connecting the electronic device to other electronic devices allowing them to communicate via wire through plugging in a cable to a physical port connected to a NIC. One or more parts of an embodiment may be implemented using different combinations of software, firmware, and / or hardware.

[0029] A network device (ND) is an electronic device that communicatively interconnects other electronic devices on the network (e.g., other network devices, end-user devices). Some network devices are “multiple services network devices” that provide support for multiple networking functions (e.g., routing, bridging, switching, Layer 2 aggregation, session border control, Quality of Service, and / or subscriber management), and / or provide support for multiple application services (e.g., data, voice, and video).

[0030] As mentioned above, the heterogeneous nature of the devices means that the application developer cannot assume that any device is capable of executing an offloaded task. To be able to offload application tasks, the application developer has to know in advance which devices have the requisite capability to execute the different application tasks. However, it is not always possible for the application developer to know the capabilities of the devices that will be available for offloading in advance, and this prevents the application developer from being able to take advantage of computational offloading and the benefits that come therewith.

[0031] Embodiments are described herein that can be used to offload functions of an application from a main host for the application to other hosts in a network. The main host for the application is the host that is responsible for initiating the execution of the application and controls the overall execution of the application. According to an embodiment, an application developer (or other entity) may add metadata to the source code of an application to indicate the resource requirements of various functions of the application. A source code processor may process the metadata to determine the resource requirements of the various functions of the application. The source code processor may determine the capabilities of the main host for the application and determine which of the application’s functions can be executed by the main host based on the capabilities of the main host and the resource requirements of the functions. The source code processor may determine that functions that can be executed by the main host (or a subset of these functions) are to be executed by the main host. The source code processor may determine that any functions of the application that cannot be executed by the main host (or any functions for which it is preferred that the function be executed by another host) are to be offloaded to other hosts. The source code processor may cause the one or more functions thatare to be executed by the main host to be compiled to native code that can be natively executed by the main host (e.g., executed without using a runtime engine). The source code processor may cause the one or more functions that are to be offloaded to be compiled to portable bytecode (e.g., Web Assembly bytecode) that can be executed by runtime engines installed on other hosts.

[0032] The network may include multiple heterogeneous hosts that make themselves available to execute offloaded functions. These hosts may advertise their capabilities to a capability advertisement service running in the network. As a non-limiting example, hosts may advertise that they have a camera capability, a temperature sensor capability, and / or a graphics processing unit (GPU) capability. It should be appreciated, however, that hosts can have other types of capabilities and may advertise these other types of capabilities. As will be further described herein, an application orchestrator may receive information regarding the capabilities of hosts in the network from the capability advertisement service and use this information to orchestrate the offloading of functions to hosts in the network.

[0033] An application orchestrator may obtain information regarding the resource requirements of the functions of the application that are to be offloaded from the main host to other hosts. The application orchestrator may also obtain information regarding the capabilities of the hosts in the network from the aforementioned capability advertisement service. The application orchestrator may identify hosts that are capable of executing the respective functions that are to be offloaded based on the information regarding the resource requirements of the functions and the information regarding the capabilities of the hosts in the network. The application orchestrator may then cause each of the functions to be deployed on a host that is capable of executing the function. In an embodiment, the application orchestrator may cause a function to be deployed on a host by sending portable bytecode of the function (e.g., Web Assembly bytecode) to the host. The host may execute the portable bytecode of the function using a runtime engine installed on the host.

[0034] Advantageously, embodiments simplify the application development process for an application developer developing a distributed application. With embodiments, instead of having to write multiple versions of source code of an application for various different types of hosts, the application developer can write a single version of the application that is tagged with metadata indicating the resource requirements of the various functions of the application. The source code processor may process the metadata to determine which of the application’s functions can be executed by the main host and which of the application’s functions should be offloaded. Functions that are to be executed by the main host are compiled to native code for the native architecture of the main host, whereas functions that are to be offloaded to a differenthost are compiled to portable bytecode. The application orchestrator may deploy the latter functions (the functions that are to be offloaded) to hosts in the network that have the requisite capabilities to execute those functions. This simplifies application development for the developer since the application developer only has to write a single version of the application source code and does not need to know the capabilities of the various hosts in the network in advance to be able to take advantage of computational offloading and the benefits that come therewith (e.g., reduced energy consumption of the main host). Also, allowing an application developer to write a single generic version of the application source code results in greater reusability of code and more testing opportunities for the code, which can increase the reliability of the code.

[0035] Also, with embodiments, discrete functionality of the application (e.g., in the form of functions) can be deployed and then redeployed on different hosts as the status and capabilities of the hosts in the network change over time (e.g., as new hosts are added, existing hosts are removed, and / or the capabilities of hosts change), without having to rewrite and recompile the application, and without the application orchestrator having to be specifically configured for each host. Embodiments achieve this by compiling functions to portable bytecode that is executable on any hosts that have a compatible runtime engine installed, publishing metadata indicating the resource requirements of the application’s functions, and advertising the capabilities of hosts in the network that are available for executing offloaded functions. An application orchestrator may identify hosts that are capable of executing functions and cause functions to be deployed on the capable hosts. The hosts may execute portable bytecode of the functions using the runtime engines installed on the hosts.

[0036] Embodiments are also described herein that provide a validity analysis service that can help resource-constrained hosts to reduce their power consumption. Since some hosts are designed to be lightweight and have limited resources (e.g., loT devices), executing a function each time the function is called may be unnecessary and inefficient depending on the specific use case. According to an embodiment, a validity timeframe is defined for a sensor of a host. The validity timeframe for the sensor indicates a timeframe during which a previously-stored result of a function that uses sensor data associated with the sensor is considered “good enough” and still valid (so there is no need to expend resources to re-execute the function). A validity analysis service running in the network may provide an indication of a validity timeframe length for the sensor to the host. The host may configure the validity timeframe for the sensor to have a length that corresponds to the validity timeframe length for the sensor. During execution of code, if the host encounters a function call to a function that uses sensor data associated with the sensor, the host may determine whether the time of the function call (the time at which thefunction is called) is within the validity timeframe for the sensor. If the time of the function call is within the validity timeframe for the sensor, the host may provide a previously-stored result for the function as an output of the function for the current function call, without re-executing the function. Otherwise, if the time of the function call is not within the validity timeframe for the sensor, the host may generate a new result based on executing the function using the most recent sensor data associated with the sensor, store the result, reset the validity timeframe for the sensor, and provide the generated result as an output of the function for the current function call. The validity analysis service may update the validity timeframe length for the sensor over time depending on various factors such as how rapidly the sensor data associated with the sensor changes, the SLA (service level agreements) for the application that uses the sensor data, and / or the ability to obtain similar sensor data from other nearby hosts. This allows the host to conserve its resources and energy, while still providing execution results that are considered acceptable for the particular use case.

[0037] Embodiments are further described herein with reference to the accompanying figures.

[0038] Figure l is a diagram showing a system that includes a source code processor and a portable bytecode generator, according to some embodiments.

[0039] As shown in the diagram, the system includes a source code processor 110 and a portable bytecode generator 120. The source code processor 110 may process source code 130 of an application (also referred to as application source code 130). The application source code 130 may define one or more functions of the application. A function may be a sequence of program instructions that performs a discrete task, packaged as a unit. The application source code 130 may have metadata 135 associated with it that indicates the resource requirements of one or more functions of the application defined in the application source code 130 (also referred to as resource requirements metadata 135). The resource requirements metadata 135 may be provided by the application developer or automatically (or semi-automatically) generated (e.g., based on static analysis of the source code or other means). The resource requirements metadata 135 may be embedded in the application source code 130 itself or provided separately from the application source code 130 (e.g., as a separate file that references the functions defined in the application source code 130). The source code processor 110 may process the application source code 130 and the resource requirements metadata 135 to separate the application source code 130 into one or more functions and their respective resource requirements. For example, in the example shown in the diagram, the source code processor 110 separates the application source code 130 into three functions (function A 140 A, function B 140B, and function C 140C) and their respective resource requirements (resource requirement 145A, resource requirement 145B, and resource requirement 145C, respectively).In the example shown in the diagram, function A 140 A does not have any particular resource requirements (besides requiring a general-purpose central processing unit (CPU)), function B 140B requires a camera, and function C 140C requires a temperature sensor and a graphics processing unit (GPU). Although the example shown in the diagram describes the resource requirements as a generic resource types (e.g., camera, temperature sensor, and GPU), in some embodiments the resource requirements provide more specific information about the resource that is required (e.g., the specifications that the resource should have (e.g., a camera that can capture images with a certain resolution or a GPU that has a certain processing speed)).

[0040] The main host is the host that is responsible for initiating the execution of the application and controlling the overall execution of the application. In an embodiment, the main host is an loT device, but it should be appreciated that the main host can be a different type of device (e.g., a mobile phone) in other embodiments. In an embodiment, the main host implements the source code processor 110 and / or the portable bytecode generator 120, but in other embodiments the source code processor 110 and / or the portable bytecode generator 120 may be implemented elsewhere (e.g., another host in the cloud or at a network edge that has access to the application source code 130). The source code processor 110 may determine whether a particular function of the application should be compiled to native code (that can be natively executed by the main host without the use of a runtime engine) or compiled to portable bytecode (that can be executed by a host using a runtime engine installed on the host) based on whether the main host is capable of executing the function. For example, the source code processor 110 may determine that a particular function should be compiled to native code if the main host has the capability to satisfy the resource requirements of the function and it is desired for the main host to execute the function. Also, the source code processor 110 may determine that a particular function should be compiled to portable bytecode if the main host has does not have the capabilities to satisfy the resource requirements of the function or if it is otherwise desired to offload the function (e.g., to conserve the energy / resources of the main host). The source code processor 110 may determine whether the main host is capable of executing a particular function based comparing the capabilities of the main host with the resource requirements of the particular function (e.g., as indicated by the resource requirements metadata 135 associated with the application source code).

[0041] In the example shown in the diagram, it is assumed that the source code processor 110 determines that function A 140A, function B 140B, and function C 140C of the application should all be offloaded (instead of being executed by the main host) because the main host does not have the requisite capabilities to satisfy the resource requirements of these functions (e.g., the main host does not have a camera, temperature sensor, or GPU) or because the main host hasthe requisite capabilities to satisfy the resource requirements of the functions but it is desired that those functions be offloaded for some other reason (e.g., to conserve energy / resources of the main host). Thus, in this example, the source code processor 110 determines that function A 140A, function B 140B, and function C 140C are to be compiled to portable bytecode.

[0042] The source code processor 110 may cause functions to be compiled to portable bytecode by providing the source code of these functions to the portable bytecode generator 120. The portable bytecode generator 120 may compile each of the functions to portable bytecode. Portable bytecode is a form of intermediate code representation that can be executed using a runtime engine installed on a host (the runtime engine installed on the host interprets or compiles the bytecode and converts it to native code that can be executed by the native architecture). Any host can execute portable bytecode as long as the host has a runtime engine installed thereon that is compatible with the portable bytecode. In an embodiment, the portable bytecode is Web Assembly code and the runtime engine is Web Assembly runtime engine, but other embodiments may use a different type of portable bytecode and runtime engine. In the example shown in the diagram, the portable bytecode generator 120 compiles function A 140 A to portable bytecode 150, compile function A 140B to portable bytecode 160, and compile function C 140C to portable bytecode 170.

[0043] As will be described in additional detail herein, the source code processor 110 may provide / publish information regarding the resource requirements of the functions to an application orchestrator to allow the application orchestrator to offload the functions to capable hosts in the network.

[0044] Figure 2 is a diagram showing a system that includes a capability advertisement service, according to some embodiments. As shown in the diagram, the system includes capability advertisement service 210 and hosts 220A, 220B, 220C, and 220D. Each host may be a distributed computing node in a network such as an loT device or a cloud computing node. In the example shown in the diagram, it is assumed that host 220A and host 220B are loT devices, while host 220C and host 220D are cloud computing nodes. It should be appreciated, however, that the hosts 220 can include other types of distributed computing nodes.

[0045] Each host 220 may include a device profiler component 230 that can be used to determine the capabilities of the host 220. For example, in the example shown in the diagram, host 220A includes a device profiler component 230. The host 220 may use the device profiler component 230 to determine its own capabilities. The host 220 may then generate information regarding the capabilities it is willing to offer for executing offloaded functions and provide this information to the capability advertisement service 210. The host 220 may thus advertise its capabilities to the capability advertisement service 210. For example, in the example shown inthe diagram, host 220 A may use device profiler component 230 to determine that it has camera capabilities and GPU capabilities. Host 220A may generate information regarding its capabilities and provide this information to the capability advertisement service 210. The capability advertisement service 210 may be implemented by a computing / network device. The host capability information may include a host identifier (ID) that identifies the host 220, a capability type that indicates the type of capability offered by the host 220, and a capability ID that identifies a specific resource of the host that can be used to provide the type of capability offered by the host (e.g., the capability ID may indicate the specific make / model / version of a resource). In the example shown in the diagram, the host capability information provided by host 220A includes a host ID of “192.168.X.X” (e.g., which may be the private IP address of host 220A, for example, in a case where the hosts belong to a private network), a capability type that indicates that host 220A has camera and GPU capabilities, and a capability ID that indicates the unique USB (Universal Serial Bus) vendor and product details of the camera (“174F:AA11”) and the PCI (Peripheral Component Interconnect) identifier of the GPU (" 10DE:20B2” - the ID encodes vendor and product details of the GPU). In an embodiment, the host capability information is formatted and transported in a JavaScript Object Notation (JSON) format or similar structured format. It should be appreciated, however, that other formats can be used to advertise host capability information.

[0046] In an embodiment, the device profiler component 230 uses “Ishw” (list hardware) or a similar tool to determine the capabilities of the host. “Ishw” is a Linux tool to extract detailed information on the hardware configuration of a machine. It can report exact memory configuration, firmware version, mainboard configuration, CPU version and speed, cache configuration, bus speed, etc.

[0047] The other hosts 220 shown in the diagram (hosts 220B, 220C, and 220D) may also include a similar device profiler component 230 (which are not shown in the diagram to avoid redundancy). The other hosts 220 may use their respective device profiler components to determine their respective capabilities and advertise the capabilities they are willing to offer for executing offloaded functions to the capability advertisement service 210 in a similar manner as described above with regard to host 220A. The hosts 220 may advertise their capabilities to the capability advertisement service 210 periodically, whenever their capabilities change, when requested, or according to another cadence.

[0048] Thus, the capability advertisement service 210 may maintain up-to-date information regarding the capabilities offered by the hosts 220. As will be described in additional detail herein, an application orchestrator may obtain information regarding the capabilities of the hosts in the network from the capability advertisement service 210. The application orchestrator mayuse this information to determine which hosts are capable of executing certain functions of an application.

[0049] Figure 3 is a diagram showing a system that includes an application orchestrator, according to some embodiments.

[0050] As shown in the diagram, the system includes an application orchestrator 310, main host 320M, host 320A, host 320B, host 320C, and a capability advertisement service 210. The application orchestrator 310 may be implemented by a computing / network device.

[0051] The main host 320M may have decided that certain functions of an application it wishes to execute should be offloaded. The main host 320M may provide information regarding the resource requirements of the functions that are to be offloaded to the application orchestrator 310. In the example shown in the diagram, it is assumed that functions A, B, and C are to be offloaded, and thus the main host 320M provides information regarding the resource requirements of functions A, B, and C to the application orchestrator 310.

[0052] The capability advertisement service 210 may provide information regarding the capabilities of various hosts 320 in the network to the application orchestrator 310. For example, the capability advertisement service 210 may advertise information regarding the capabilities of host 320A, host 320B, and host 320C to the application orchestrator 310.

[0053] The application orchestrator 310 may identify hosts that are capable of executing the functions that are to be offloaded from the main host 320M based on the information regarding the resource requirements of the functions (e.g., received from the main host 320M) and the information regarding the capabilities of the hosts in the network (e.g., received from the capability advertisement service 210). For each function that is to be offloaded, the application orchestrator 310 may decide to offload the function to one of the hosts that are capable of executing the function. The application orchestrator 310 may then cause the functions to be deployed on the capable hosts.

[0054] In the example shown in the diagram, it is assumed that the application orchestrator 310 identifies host 320A as being capable of executing function A, identifies host 320B as being capable of executing function B, and identifies host 320C as being capable of executing function C. As a result, the application orchestrator 310 decides to offload function A to host 320A, offload function B to host 320B, and offload function C to host 320C. The application orchestrator 310 may thus cause function A to be deployed on host 320A, function B to be deployed on host 320B, and function C to be deployed on host 320C. In an embodiment, the application orchestrator 310 causes a function to be deployed on a host based on sending portable bytecode of the function (e.g., obtained via the portable bytecode generator 120) to the host (and associated instructions to execute the portable bytecode). For example, the applicationorchestrator 310 may cause function A 140A to be deployed on host 320A by sending portable bytecode of function A 140A to host 320A. Similarly, the application orchestrator 310 may cause function B MOB to be deployed on host 320B by sending portable bytecode of function B 140B to host 320B. Similarly, the application orchestrator 310 may cause function C 140C to be deployed on host 320C by sending portable bytecode of function C to host 320B. The portable bytecode of a function may have been generated by a portable bytecode generator 120, as previously described. As a result of the deployment, host 320A has access to portable bytecode of function A 140A, host 320B has access to portable bytecode of function B 140B, and host 320C has access to portable bytecode of function C 140C.

[0055] In an embodiment, the application orchestrator 310 may cause multiple functions of an application to be deployed on a given host by packaging portable bytecode of the multiple functions into a single package and sending the single package to the given host. Sending a single package may reduce dependency duplication, lowering the amount of network traffic required to deploy the functions, and thus reduce the time to execution.

[0056] Each host 320 may include a set of resources and a runtime engine. The resources may include, for example, a camera, a temperature sensor, and / or a GPU. A host 320 may use its runtime engine 350 to execute portable bytecode. For example, as shown in the diagram, host 320C includes resources 360 and a runtime engine 350. Host 320C may use runtime engine 350 to execute portable bytecode of function C 140C.

[0057] A runtime engine may need suitable driver code to be able to use a particular resource of a host 320. In an embodiment, a host 320 obtains driver code for a particular resource from a driver repository 330. The driver repository 330 may be a repository / database that stores driver code for various resources of hosts 320. For example, host 320C may obtain driver code 340 for a particular resource of host 320C that is needed by function C 140C from the driver repository 330. A host 320 may determine the particular driver code that is needed based on identifying the resources that a function requires and determining the driver code corresponding to those resources. The other hosts 320 shown in the diagram (e.g., hosts 320A and 320B) may include similar components as 320C but are not shown in the diagram to avoid redundancy.

[0058] Each host 320 to which a function is offloaded may execute the offloaded function by executing the portable bytecode of the offloaded function using a runtime engine. For example, host 320C may execute function C 140C by executing portable bytecode of function C 140C using the runtime engine 350, which may also involve executing the driver code 340 to use the resources 360 of host 320C.

[0059] The main host 320M may communicate with the hosts 320 to which functions have been offloaded to gather the results of the offloaded functions and to coordinate execution withthose hosts. For example, the main host 320M may communicate with hosts 320A, 320B, and 320C to gather the execution results of function A 140A, function B 140B, and function C 140C, respectively. In an embodiment, the main host 320M may communicate with other hosts 320 using WebSockets, message passing and / or remote procedure calls (RPCs), although other ways of communicating are contemplated.

[0060] The main host 320M may execute any functions that were not offloaded to other hosts 320 (e.g., by executing native code of those functions). Thus, the main host 320M and the other hosts 320 to which functions were offloaded may collectively execute all functions of the application in a distributed fashion.

[0061] Embodiments simplify the application development process for an application developer developing a distributed application. With embodiments, instead of having to write multiple versions of source code of an application for various different types of hosts, the application developer can write a single version of the application source code that is tagged or otherwise associated with metadata indicating the resource requirements of the various functions included in the application. A capability advertisement service running in the network may collect information regarding the capabilities of various hosts in the network and provide this information to the application orchestrator. The application orchestrator 310 may determine where to offload one or more functions of the application based on information regarding the resource requirements of the one or more functions (as indicated in the metadata associated with the application source code) and the information regarding the capabilities of the hosts (received from the capability advertisement service). This simplifies application development for the developer since the application developer only has to write a single version of the application source code and does not need to know the capabilities of the various hosts in the network in advance to be able to take advantage of computational offloading and the benefits that come therewith (e.g., reduced energy consumption of the main host). Also, allowing an application developer to write a single generic version of the application source code results in greater reusability of code and more testing opportunities for the code, which can increase the reliability of the code.

[0062] Also, with embodiments, discrete functionality of the application (e.g., in the form of functions) can be deployed and then redeployed on different hosts as the status and capabilities of the hosts in the network change over time (e.g., as new hosts are added, existing hosts are removed, and / or the capabilities of hosts change), without rewriting and recompiling the application, and without the application orchestrator having to be specifically configured for each host.

[0063] Figure 4 is a diagram showing a system that includes a validity analysis service, according to some embodiments.

[0064] A sensor of a host (e.g., a camera or temperature sensor) may periodically generate sensor data (e.g., images captured by the camera or temperature readings of the temperature sensor). Depending on the granularity and complexity of the sensor data, there may be a period of time during which performing a calculation based on the most recently generated sensor data generates a result that is, for the purposes of the application, not significantly or statistically different from a previously-generated result. In such cases, it may be inefficient (in terms of resources and latency) to calculate a new result based on the most recent sensor data generated by the sensor. As will be described in additional detail below, embodiments provide a way for a host to avoid calculating a new result in such cases to conserve resources / energy.

[0065] In an embodiment, a validity timeframe is defined for a sensor. The validity timeframe for a sensor is a timeframe during which a particular result of a function that uses sensor data associated with the sensor is considered valid. As shown in the diagram, a validity analysis service 410 may provide a validity timeframe length for the sensor to the host. The validity analysis service 410 may be implemented by a computing / network device. The validity timeframe length may indicate the length of the validity timeframe (how long a result of a function that uses sensor data associated with the sensor is valid) and may be configurable / modifiable. Responsive to receiving the validity timeframe length for the sensor from the validity analysis service 410, the host may configure the validity timeframe for the sensor to have a length that corresponds to the validity timeframe length. In an embodiment, the host implements the validity analysis service 410, but the validity analysis service 410 may be implemented elsewhere (e.g., another host or a server) in other embodiments.

[0066] If, during execution of code, the host encounters a function call 430 to a particular function 420 that uses sensor data associated with the sensor, the host may determine whether the time of the function call is within a validity timeframe for the sensor (e.g., determine whether the length of time that has elapsed since the previously-stored result of the function was generated / calculated is shorter than the validity timeframe length for the sensor). If the time of the function call is within the validity timeframe for the sensor, the host may provide the previously-stored result of the function as the output of the function without re-executing the function. Otherwise, if the time of the function call is not within the validity timeframe for the sensor (e.g., meaning that the length of time that has elapsed since the previously-stored result of the function was generated / calculated is longer than the validity timeframe length for the sensor), the host may generate / calculate a new result based on executing the function using the most recent sensor data associated with the sensor, store the result (e.g., so that it can be reusedlater, within the new validity timeframe for the sensor), reset the validity timeframe for the sensor, and provide the generated / calculated result as the output of the function.

[0067] The validity analysis service 410 may determine the validity timeframe length for a sensor in various ways. For example, the validity analysis service 410 may determine how much the rate of change of the sensor data impacts the results of certain benchmark functions / calculations. If the rate of change of the sensor data significantly impacts the results (what is considered significant may depend on the use case), then the validity analysis service 410 may choose a relatively shorter validity timeframe length for the sensor. Otherwise, if the rate of change of the sensor data does not significantly impact the results, then the validity analysis service 410 may choose a relatively longer validity timeframe length for the sensor. As another example, the validity analysis service 410 may determine the validity timeframe length for a sensor based on the specifications of the sensor such as sensor resolution and / or sensor update interval. As another example, the validity analysis service 410 may determine the validity timeframe length for a sensor based on the proximity of hosts that are generating the same or similar sensor data. For example, if there are multiple hosts within an enclosed area (e.g., within a room) that have sensors that generate the same type of sensor data (e.g., temperature readings), then the validity analysis service 410 may choose a relatively longer validity timeframe length for those sensors (compared to a sensor of an isolated host). In an embodiment, the validity analysis service 410 may configure the validity timeframe lengths for multiple sensors of multiple hosts. In an embodiment, the validity analysis service 410 configures the validity timeframe lengths for the multiple sensors to spread the workload among the hosts or to improve energy efficiency for a particular subset of hosts (e.g., by increasing the validity timeframe lengths for sensors of hosts that are low on battery).

[0068] Figure 5 is a flow diagram of a method for processing metadata associated with source code of an application, according to some embodiments. In an embodiment, the method is performed by a computing device (e.g., a computing device implementing a source code processor). In an embodiment, the computing device is the main host for the application. In another embodiment, the computing device is the computing device that implements an application orchestrator.

[0069] The operations in the flow diagrams will be described with reference to the example embodiments of the other figures. However, it should be understood that the operations of the flow diagrams can be performed by embodiments other than those discussed with reference to the other figures, and embodiments discussed with reference to these other figures can perform operations different than those discussed with reference to the flow diagrams.

[0070] At operation 510, the computing device processes metadata associated with source code of the application to determine resource requirements of a plurality of functions of the application.

[0071] At operation 520, the computing device determines capabilities of the main host.

[0072] At operation 530, the computing device determines that a first one or more of the plurality of functions are to be executed on the main host responsive to a determination, based on the resource requirements of the first one or more functions and the capabilities of the main host, that the main host is capable of executing the first one or more functions.

[0073] At operation 540, the computing device determines that a second one or more of the plurality of functions are to be offloaded to one or more other hosts.

[0074] At operation 550, the computing device causes the first one or more functions to be compiled to native code, wherein the native code is natively executable by the main host.

[0075] At operation 560, the computing device causes the second one or more functions to be compiled to portable bytecode, wherein the portable bytecode is executable by runtime engines installed on the one or more other hosts.

[0076] Figure 6 is a flow diagram of a method for offloading functions from a main host for the application to other hosts in a network, according to some embodiments. In an embodiment, the method is performed by a computing device (e.g., implementing an application orchestrator).

[0077] At operation 610, the computing device obtains information regarding resource requirements of a function of the application that is to be offloaded.

[0078] At operation 620, the computing device obtains information regarding capabilities of one or more hosts in the network. In an embodiment, the information regarding the capabilities of the one or more hosts is obtained from a capability advertisement service running in the network, wherein the one or more hosts advertise their capabilities to the capability advertisement service. In an embodiment, the information regarding the capabilities of the one or more hosts includes a host identifier that identifies the host, a capability type that indicates a type of capability offered by the host, and a capability identifier that identifies a resource of the host that can provide the type of capability offered by the host. In an embodiment, the capability type indicates a camera capability, a temperature sensor capability, or a GPU capability.

[0079] At operation 630, the computing device identifies a host from the one or more hosts that is capable of executing the function based on the information regarding the resource requirements of the function and the information regarding the capabilities of the one or more hosts in the network. In an embodiment, the identified host is an loT device or a cloud computing node.

[0080] At operation 640, the computing device causes the function to be deployed on the identified host. In an embodiment, causing the function to be deployed on the identified host involves operation 650 in which the computing device sends portable bytecode of the function to the identified host. In an embodiment, causing the function to be deployed on the identified hosts involves packaging portable bytecode of the function and portable bytecode of one or more other functions of the application into a single package and sending the single package to the identified host. In an embodiment, the identified host is to obtain, from a driver repository, driver code for a resource of the identified host that is to be used by the function , wherein the resource of the identified host is used to provide a capability offered by the identified host.

[0081] Figure 7 is a flow diagram of a method for executing a function of an application that is being offloaded from a main host for the application in a network, according to some embodiments. In an embodiment, the method is performed by a host in the network (e.g., an loT device or cloud computing node) that is not the main host for the application. The host may be implemented by a computing device.

[0082] At operation 710, the host advertises information regarding the capabilities of the host to a capability advertisement service running in the network.

[0083] At operation 720, the host receives, from an application orchestrator, an instruction to deploy the function, wherein the application orchestrator determined that the function is to be offloaded to the host based on a determination that the host is capable of executing the function, wherein the application orchestrator determined that the host is capable of executing the function based on information regarding the capabilities of the host that the application orchestrator received from the capability advertisement service.

[0084] At operation 730, the host obtains portable bytecode of the function responsive to receiving the instruction to deploy the function.

[0085] In an embodiment, at operation 740, the host identifies driver code for a resource of the host that is to be used by the function.

[0086] In an embodiment, at operation 750, the host obtains the driver code for the resource from a driver repository.

[0087] At operation 760, the host executes the portable bytecode of the function using a runtime engine installed on the host (which may involve executing the driver code for the resource to use the resource).

[0088] Figure 8 is a flow diagram of a method for implementing a validity timeframe for a sensor, according to some embodiments. In an embodiment, the method is performed by a host in a network (e.g., an loT device or cloud computing node). The host may be implemented by a computing device.

[0089] In an embodiment, at operation 810, the host receives an indication of a validity timeframe length for a sensor of the host from a validity analysis service.

[0090] In an embodiment, at operation 820, the host configures a validity timeframe for the sensor to have a length that corresponds to the validity timeframe length for the sensor.

[0091] At operation 830, the host encounters, during execution of code, a function call to a function that uses sensor data associated with the sensor.

[0092] At operation 840, the host determines whether the time of the function call is within the validity timeframe for the sensor. If the host determines that the time of the function call is not within the validity timeframe for the sensor, the flow moves to operation 850.

[0093] At operation 850, the host generates a result based on executing the function using most recent sensor data associated with the sensor.

[0094] At operation 860, the host stores the result.

[0095] At operation 870, the host resets the validity timeframe for the sensor.

[0096] At operation 880, the host provides the generated result as an output of the function for the function call.

[0097] Returning to operation 840, if the host determines that the time of the function call is within the validity timeframe for the sensor, the flow moves to operation 890.

[0098] At operation 890, the host provides a previously-stored result for the function (e.g., the result stored in operation 860) as an output of the function for the function call without executing the function.

[0099] Figure 9 is a diagram showing connectivity between network devices (NDs) within an exemplary network, as well as three exemplary implementations of the NDs, according to some embodiments. Figure 9 shows NDs 900A-H, and their connectivity by way of lines between 900A-900B, 900B-900C, 900C-900D, 900D-900E, 900E-900F, 900F-900G, and 900A- 900G, as well as between 900H and each of 900A, 900C, 900D, and 900G. These NDs are physical devices, and the connectivity between these NDs can be wireless or wired (often referred to as a link). An additional line extending from NDs 900A, 900E, and 900F illustrates that these NDs act as ingress and egress points for the network (and thus, these NDs are sometimes referred to as edge NDs; while the other NDs may be called core NDs).

[0100] Two of the exemplary ND implementations in Figure 9 are: 1) a special-purpose network device 902 that uses custom application-specific integrated-circuits (ASICs) and a special-purpose operating system (OS); and 2) a general purpose network device 904 that uses common off-the-shelf (COTS) processors and a standard OS.

[0101] The special -purpose network device 902 includes networking hardware 910 comprising a set of one or more processor(s) 912, forwarding resource(s) 914 (which typicallyinclude one or more ASICs and / or network processors), and physical network interfaces (NIs) 916 (through which network connections are made, such as those shown by the connectivity between NDs 900A-H), as well as non-transitory machine readable storage media 918 having stored therein networking software 920. During operation, the networking software 920 may be executed by the networking hardware 910 to instantiate a set of one or more networking software instance(s) 922. Each of the networking software instance(s) 922, and that part of the networking hardware 910 that executes that network software instance (be it hardware dedicated to that networking software instance and / or time slices of hardware temporally shared by that networking software instance with others of the networking software instance(s) 922), form a separate virtual network element 930A-R. Each of the virtual network element(s) (VNEs) 930A-R includes a control communication and configuration module 932A- R (sometimes referred to as a local control module or control communication module) and forwarding table(s) 934A-R, such that a given virtual network element (e.g., 930A) includes the control communication and configuration module (e.g., 932A), a set of one or more forwarding table(s) (e.g., 934A), and that portion of the networking hardware 910 that executes the virtual network element (e.g., 930A).

[0102] The special-purpose network device 902 is often physically and / or logically considered to include: 1) a ND control plane 924 (sometimes referred to as a control plane) comprising the processor(s) 912 that execute the control communication and configuration module(s) 932A-R; and 2) a ND forwarding plane 926 (sometimes referred to as a forwarding plane, a data plane, or a media plane) comprising the forwarding resource(s) 914 that utilize the forwarding table(s) 934A-R and the physical NIs 916. By way of example, where the ND is a router (or is implementing routing functionality), the ND control plane 924 (the processor(s) 912 executing the control communication and configuration module(s) 932A-R) is typically responsible for participating in controlling how data (e.g., packets) is to be routed (e.g., the next hop for the data and the outgoing physical NI for that data) and storing that routing information in the forwarding table(s) 934A-R, and the ND forwarding plane 926 is responsible for receiving that data on the physical NIs 916 and forwarding that data out the appropriate ones of the physical NIs 916 based on the forwarding table(s) 934A-R.

[0103] In an embodiment, software 920 includes code such as function offloading component 923, which when executed by networking hardware 910, causes the special-purpose network device 902 to perform operations of one or more embodiments disclosed herein as part of networking software instances 922 (e.g., operations to offload functions to hosts in the network).

[0104] The general purpose network device 904 includes hardware 940 comprising a set of one or more processor(s) 942 (which are often COTS processors) and physical NIs 946, as well as non-transitory machine readable storage media 948 having stored therein software 950. During operation, the processor(s) 942 execute the software 950 to instantiate one or more sets of one or more applications 964A-R. While one embodiment does not implement virtualization, alternative embodiments may use different forms of virtualization. For example, in one such alternative embodiment the virtualization layer 954 represents the kernel of an operating system (or a shim executing on a base operating system) that allows for the creation of multiple instances 962A-R called software containers that may each be used to execute one (or more) of the sets of applications 964A-R; where the multiple software containers (also called virtualization engines, virtual private servers, or jails) are user spaces (typically a virtual memory space) that are separate from each other and separate from the kernel space in which the operating system is run; and where the set of applications running in a given user space, unless explicitly allowed, cannot access the memory of the other processes. In another such alternative embodiment the virtualization layer 954 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on top of a host operating system, and each of the sets of applications 964A-R is run on top of a guest operating system within an instance 962A-R called a virtual machine (which may in some cases be considered a tightly isolated form of software container) that is run on top of the hypervisor - the guest operating system and application may not know they are running on a virtual machine as opposed to running on a “bare metal” host electronic device, or through para-virtualization the operating system and / or application may be aware of the presence of virtualization for optimization purposes. In yet other alternative embodiments, one, some or all of the applications are implemented as unikernel(s), which can be generated by compiling directly with an application only a limited set of libraries (e.g., from a library operating system (LibOS) including drivers / libraries of OS services) that provide the particular OS sendees needed by the application. As a unikernel can be implemented to run directly on hardware 940, directly on a hypervisor (in which case the unikernel is sometimes described as running within a LibOS virtual machine), or in a software container, embodiments can be implemented fully with unikemels running directly on a hypervisor represented by virtualization layer 954, unikemels running within software containers represented by instances 962A-R, or as a combination of unikemels and the above-described techniques (e.g., unikemels and virtual machines both run directly on a hypervisor, unikemels and sets of applications that are run in different software containers).

[0105] The instantiation of the one or more sets of one or more applications 964A-R, as well as virtualization if implemented, are collectively referred to as software instance(s) 952. Each set of applications 964 A-R, corresponding virtualization construct (e.g., instance 962 A-R) if implemented, and that part of the hardware 940 that executes them (be it hardware dedicated to that execution and / or time slices of hardware temporally shared), forms a separate virtual network element(s) 960A-R.

[0106] The virtual network element(s) 960A-R perform similar functionality to the virtual network element(s) 930 A-R - e.g., similar to the control communication and configuration module(s) 932A and forwarding table(s) 934A (this virtualization of the hardware 940 is sometimes referred to as network function virtualization (NFV)). Thus, NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which could be located in Data centers, NDs, and customer premise equipment (CPE). While embodiments are illustrated with each instance 962A-R corresponding to one VNE 960A-R, alternative embodiments may implement this correspondence at a finer level granularity (e.g., line card virtual machines virtualize line cards, control card virtual machine virtualize control cards, etc.); it should be understood that the techniques described herein with reference to a correspondence of instances 962A-R to VNEs also apply to embodiments where such a finer level of granularity and / or unikemels are used.

[0107] In certain embodiments, the virtualization layer 954 includes a virtual switch that provides similar forwarding services as a physical Ethernet switch. Specifically, this virtual switch forwards traffic between instances 962A-R and the physical NI(s) 946, as well as optionally between the instances 962A-R; in addition, this virtual switch may enforce network isolation between the VNEs 960A-R that by policy are not permitted to communicate with each other (e.g., by honoring virtual local area networks (VLANs)).

[0108] In an embodiment, software 950 includes code such as function offloading component 963, which when executed by processor(s) 942, causes the general purpose network device 904 to perform operations of one or more embodiments described herein as part of software instances 962A-R (e.g., operations to offload functions to hosts in a network).

[0109] The third exemplary ND implementation in Figure 9 is a hybrid network device 906, which includes both custom ASICs / special-purpose OS and COTS processors / standard OS in a single ND or a single card within an ND. In certain embodiments of such a hybrid network device, a platform VM (i.e., a VM that that implements the functionality of the special-purpose network device 902) could provide for para-virtualization to the networking hardware present in the hybrid network device 906.

[0110] A network interface (NI) may be physical or virtual; and in the context of IP, an interface address is an IP address assigned to a NI, be it a physical NI or virtual NI. A virtual NI may be associated with a physical NI, with another virtual interface, or stand on its own (e.g., a loopback interface, a point-to-point protocol interface). A NI (physical or virtual) may be numbered (a NI with an IP address) or unnumbered (a NI without an IP address). A loopback interface (and its loopback address) is a specific type of virtual NI (and IP address) of a NE / VNE (physical or virtual) often used for management purposes; where such an IP address is referred to as the nodal loopback address. The IP address(es) assigned to the NI(s) of a ND are referred to as IP addresses of that ND; at a more granular level, the IP address(es) assigned to NI(s) assigned to a NE / VNE implemented on a ND can be referred to as IP addresses of that NE / VNE.

[0111] Some portions of the preceding detailed descriptions have been presented in terms of algorithms and symbolic representations of transactions on data bits within a computer memory. These algorithmic descriptions and representations are the ways used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consi stent sequence of transactions leading to a desired result. The transactions are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0112] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

[0113] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method transactions. The required structure for avariety of these systems will appear from the description above. In addition, embodiments are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of embodiments as described herein.

[0114] An embodiment may be an article of manufacture in which a non-transitory machine- readable storage medium (such as microelectronic memory) has stored thereon instructions (e.g., computer code) which program one or more data processing components (generically referred to here as a “processor”) to perform the operations described above. In other embodiments, some of these operations might be performed by specific hardware components that contain hardwired logic (e.g., dedicated digital filter blocks and state machines). Those operations might alternatively be performed by any combination of programmed data processing components and fixed hardwired circuit components.

[0115] Throughout the description, embodiments have been presented through flow diagrams. It will be appreciated that the order of transactions and transactions described in these flow diagrams are only intended for illustrative purposes and not intended to be limiting. One having ordinary skill in the art would recognize that variations can be made to the flow diagrams.

Claims

CLAIMSWhat is claimed is:

1. A method performed by a computing device to offload functions of an application from a main host for the application to other hosts in a network, comprising: obtaining (610) information regarding resource requirements of a function of the application that is to be offloaded; obtaining (620) information regarding capabilities of one or more hosts in the network; identifying (630) a host from the one or more hosts that is capable of executing the function based on the information regarding the resource requirements of the function and the information regarding the capabilities of the one or more hosts in the network; and causing (640) the function to be deployed on the identified host.

2. The method of claim 1, wherein causing the function to be deployed on the identified host comprises: sending (650) portable bytecode of the function to the identified host.

3. The method of claim 1, wherein causing the function to be deployed on the identified host comprises: packaging portable bytecode of the function and portable bytecode of one or more other functions of the application into a single package; and sending the single package to the identified host.

4. The method of claim 1, wherein the information regarding the capabilities of the one or more hosts is obtained from a capability advertisement service running in the network, wherein the one or more hosts advertise their capabilities to the capability advertisement service.

5. The method of claim 1, wherein the information regarding the capabilities of the one or more hosts includes a host identifier that identifies the host, a capability type that indicates a type of capability offered by the host, and a capability identifier that identifies a resource of the host that can provide the type of capability offered by the host.

6. The method of claim 5, wherein the capability type indicates a camera capability, a temperature sensor capability, or a graphics processing unit (GPU) capability.

7. The method of claim 1, wherein the identified host is to obtain, from a driver repository, driver code for a resource of the identified host that is to be used by the function , wherein the resource of the identified host is used to provide a capability offered by the identified host.

8. The method of claim 1, further comprising: processing (510) metadata associated with source code of the application to determine resource requirements of a plurality of functions of the application; determining (520) capabilities of the main host; determining (530) that a first one or more of the plurality of functions are to be executed on the main host responsive to a determination, based on the resource requirements of the first one or more functions and the capabilities of the main host, that the main host is capable of executing the first one or more functions; determining (540) that a second one or more of the plurality of functions are to be offloaded to one or more other hosts; causing (550) the first one or more functions to be compiled to native code, wherein the native code is natively executable by the main host; and causing (560) the second one or more functions to be compiled to portable bytecode, wherein the portable bytecode is executable by runtime engines installed on the one or more other hosts.

9. The method of claim 1, wherein the identified host is an Internet of Things (loT) device.

10. The method of claim 1, wherein the identified host is a cloud computing node.

11. A method performed by a computing device implementing a first host in a network to execute a function of an application that is being offloaded from a main host for the application in the network, the method comprising: determining capabilities of the first host; advertising (710) information regarding the capabilities of the first host to a capability advertisement service running in the network; receiving (720), from an application orchestrator, an instruction to deploy the function, wherein the application orchestrator determined that the function is to be offloaded to the first host based on a determination that the first host is capable of executing the function, wherein the application orchestrator determined that the first host is capable of executing the function based on information regarding the capabilities of the first host that the application orchestrator received from the capability advertisement service;obtaining (730) portable bytecode of the function responsive to receiving the instruction to deploy the function; and executing (760) the portable bytecode of the function using a runtime engine installed on the first host.

12. The method of claim 11, further comprising: identifying (740) driver code for a resource of the first host that is to be used by the function; and obtaining (750) the driver code for the resource from a driver repository.

13. The method of claim 11, further comprising: encountering (830), during execution of code, a first function call to a function that uses sensor data associated with a sensor of the first host; responsive to encountering the first function call, determining (840) whether a time of the first function call is within a validity timeframe for the sensor; and responsive to a determination that the time of the first function call is within the validity timeframe for the sensor, providing (890) a previously-stored result for the function as an output of the function for the first function call without executing the function.

14. The method of claim 13, further comprising: encountering (830), during execution of code, a second function call to the function; responsive to encountering the second function call, determining (840) whether a time of the second function call is within the validity timeframe for the sensor; and responsive to a determination that the time of the second function call is not within the validity timeframe for the sensor, generating (850) a result based on executing the function using most recent sensor data associated with the sensor, storing (860) the result, resetting (870) the validity timeframe for the sensor, and providing (880) the generated result as an output of the function for the second function call.

15. The method of claim 14, further comprising: receiving (810) an indication of a validity timeframe length for the sensor from a validity analysis service; and configuring (820) the validity timeframe for the sensor to have a length that corresponds to the validity timeframe length for the sensor.

16. A machine-readable medium comprising computer program code which when executed by a computing device carries out the method steps of any of claims 1-10.

17. A computing device (904) configured to offload functions of an application from a main host for the application to other hosts in a network, the computing device comprising: one or more processors (942); and a non-transitory machine-readable storage medium (948) that stores instructions, which when executed by the one or more processors, causes the computing device to perform the method steps of any one of claims 1-10.

18. A machine-readable medium comprising computer program code which when executed by a computing device carries out the method steps of any of claims 11-15.

19. A computing device (904) configured to implement a first host in a network to execute a function of an application that is being offloaded from a main host for the application in the network, the computing device comprising: one or more processors (942); and a non-transitory machine-readable storage medium (948) that stores instructions, which when executed by the one or more processors, causes the computing device to perform the method steps of any one of claims 11-15.

Images