Patent Application
20220182334
The present application claims priority to Korean Patent Application No. 10-2020-0169195, filed Dec. 7, 2020, the entire content of which is incorporated herein for all purposes by this reference.
The present invention relates to a name-based in-network distributed computing system and particularly to an apparatus and method for returning an execution result of a function in a name-based in-network distributed computing system.
As the recent trend of Internet applications moves to the production and transfer of massive contents, the existing host-based point-to-point communication mechanism is replaced by the concept of information centric networking (ICN) focusing on data themselves. According to ICN technology, names are given to all the data, a user makes a request to a network by specifying a name of desired data, and the network searches and transfers data matching the name to the user. Representative ICN projects are content centric networking (CCN) and named data networking (NDN).
The present invention may provide a method and apparatus for effectively returning an execution result of a function in a name-based in-network distributed computing system.
The present invention may provide a method and apparatus for executing a function and returning a result by using different independent logics in a name-based in-network distributed computing system.
The present invention may provide a method and apparatus for executing a function and returning an execution result in an environment that is designed to develop an executable code without dependence on a method of returning the execution result of the function in a name-based in-network distributed computing system.
According to an embodiment of the present invention, a method for operating a client device in a name-based in-network distributed computing system may include: transmitting a first packet, which requests execution of a function, to a first node; transmitting a second packet, which requests an execution result of the function, to a second node; and receiving, after transmitting the second packet, a third packet including the execution result of the function from the second node.
Herein, the first packet may include at least one among information designating the function, information on at least one input variable for executing the function, and information for identifying an execution result of the function.
According to an embodiment of the present invention, the method may further include receiving, from the first node, a fourth packet including information on an instance that is generated for executing the function.
According to an embodiment of the present invention, the first node may include a device having a resource for in-network computing, and the second node may include a device having a storage means for storing and providing an execution result of the function.
According to an embodiment of the present invention, the method may further include determining an operation mode of the function among multiple candidate modes. The multiple candidate modes may include a first mode, which obtains the execution result from a node executing the function, and a second node that obtains the execution result from a different node from the node executing the function.
According to an embodiment of the present invention, information for identifying the execution result of the function may include a key value that is to be used in a node providing the execution result.
According to an embodiment of the present invention, information on at least one input variable for executing the function may include information for identifying an execution result of another function.
According to an embodiment of the present invention, the method may further include: generating a function call handler (FCH) for calling the function; and generating a get result handler (GRH) for obtaining an execution result of the function.
Herein, the FCH may be deleted after requesting execution of the function by using the first packet, and the GRH may be deleted after obtaining the execution result of the function by using the third packet.
According to an embodiment of the present invention, the method may further include determining, by using the FCH, a key value that matches the execution result of the function.
According to an embodiment of the present invention, the second packet may include information for identifying the execution result of the function.
According to an embodiment of the present invention, the method may further include receiving the sixth packet including information for identifying the execution result of the function.
According to an embodiment of the present invention, a method for operating an in-network computing server in a name-based in-network distributed computing system may include: receiving a first packet, which requests execution of a function, from a client device; executing the function; and transmitting, to a storage node, a second packet that requests to store an execution result of the function.
Herein, the first packet may include at least one among information designating the function, information on at least one input variable for executing the function, and information for identifying an execution result of the function.
According to an embodiment of the present invention, the method may further include transmitting, to the client device, a third packet including information on an instance that is generated for executing the function.
According to an embodiment of the present invention, the second packet may include the execution result and information for identifying the execution result of the function.
According to an embodiment of the present invention, information for identifying the execution result of the function may include a key value that is to be used in the storage node.
According to an embodiment of the present invention, the executing of the function may include: allocating a computing resource for executing the function; executing the function by using the computing resource; and returning the computing resource, when it is confirmed that the execution result is stored in the storage node.
According to an embodiment of the present invention, the executing of the function may include generating an instance for executing the function. The instance may include an operation logic of the function, a function handler executing the operation logic and a result handler processing the return of the execution result.
According to an embodiment of the present invention, information on at least one input variable for executing the function may include information for identifying an execution result of another function.
According to an embodiment of the present invention, the executing of the function may include: obtaining data, which includes an execution result of the another function, from the storage node by using information for identifying the execution result of the another function; and executing the function by using the data.
According to an embodiment of the present invention, a client device in a name-based in-network distributed computing system includes a transceiver configured to transmit and receive information and a processor configured to control the transceiver. The processor may control to transmit a first packet, which requests to execute a function, to a first node, to transmit a second packet, which requests an execution result of the function, to a second node, and to receive a third packet including the execution result of the function from the second node after transmitting the second packet. Herein, the first packet may include at least one among information designating the function, information on at least one input variable for executing the function, and information for identifying an execution result of the function.
According to an embodiment of the present invention, an in-network computing server in a name-based in-network distributed computing system includes a transceiver configured to transmit and receive information and a processor configured to control the transceiver. The processor may control to receive a first packet, which requests to execute a function, from a client device, to execute the function, and to transmit a second packet, which requests to store an execution result of the function, to a storage node. Herein, the first packet may include at least one among information designating the function, information on at least one input variable for executing the function, and information for identifying an execution result of the function.
According to the present invention, in a name-based in-network distributed computing system, usage efficiency of a computing resource for executing a function and returning a result may be increased, and the burden of developing an executable code for returning an execution result of a function may be decreased.
Effects obtained in the present disclosure are not limited to the above-mentioned effects, and other effects not mentioned above may be clearly understood by those skilled in the art from the following description.
Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings so that those of ordinary skill in the art to which the present disclosure pertains can easily implement them. However, the present disclosure may be implemented in several different forms and is not limited to the embodiments described herein.
In describing an embodiment of the present disclosure, if it is determined that a detailed description of a well-known configuration or function may obscure the gist of the present disclosure, a detailed description thereof will be omitted. And, in the drawings, parts not related to the description of the present disclosure are omitted, and similar reference numerals are attached to similar parts.
In the present disclosure, when it is said that a component is “connected”, “coupled” or “connected” to another component, it is not only a direct connection relationship, but also an indirect connection relationship in which another component exists in the middle. may also include. In addition, when it is said that a component “includes” or “has” another component, it means that another component may be further included without excluding other components unless otherwise stated.
In the present disclosure, terms such as first, second, etc. are used only for the purpose of distinguishing one component from other components, and unless otherwise specified, the order or importance of the components is not limited. Accordingly, within the scope of the present disclosure, a first component in one embodiment may be referred to as a second component in another embodiment, similarly, the second component in one embodiment may be referred to as a first component in another embodiment.
In the present disclosure, components that are distinguished from each other are for clearly explaining each characteristic, and do not necessarily mean that the components are separated. That is, a plurality of components may be integrated to form one hardware or software unit, or one component may be distributed to form a plurality of hardware or software units. Therefore, even if not separately mentioned, such integrated or distributed embodiments are also included in the scope of the present disclosure.
In the present disclosure, components described in various embodiments do not necessarily mean essential components, and some may be optional components. Accordingly, an embodiment composed of a subset of components described in an embodiment is also included in the scope of the present disclosure. In addition, embodiments including other components in addition to components described in various embodiments are also included in the scope of the present disclosure.
Advantages and features of the present invention, and a method of achieving them will become apparent with reference to the embodiments described below in detail in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments presented below, but may be implemented in a variety of different forms, only the present embodiments are provided so that the disclosure of the present invention is complete, and to completely inform those of ordinary skill in the art to which the present invention pertains to the scope of the invention.
Hereinafter, the present invention relates to an apparatus and method for returning an execution result of a function in a name-based in-network distributed computing system. Specifically, the present invention provides in-network computing (hereinafter referred to as ‘INC’) that supports distributed performance of some computing operations by using computing resources provided by network infrastructure by an application located in a user device in a name-based network environment, with respect to technology, a method and apparatus for receiving operation processing requests of a user application specified based on a name, performing distributed computing work at an appropriate location in a network, and returning the result to a user application.
Referring to
The client 110 may request and receive a content that is stored in the data source 120. A request for a content and data including a content are transferred via the network 130. Herein, the system of
When supporting NDN, at least one of the nodes 130a to 130d may be an NDN router. According to NDN, an interest packet and a data packet are used. A data consumer (e.g. the client 110) transmits an interest packet, which specifies a name of desired data, to the network 130, and an NDN router transfers the interest packet to a data publisher (e.g. the data source 120) based on a forwarding information base (FIB). When the interest packet reaches the data publisher, the data publisher transmits a data packet, which includes data specified in the interest packet, to the data consumer. The NDN router provides a function of caching the data, which is transmitted by the NDN router, in a content store (CS) for a predetermined time. While an interest packet is forwarded to a data publisher, if an NDN router is caching data that matches a name specified on the interest packet, the interest packet is not forwarded any longer, and a data packet including data, which is cached in a CS, is transmitted backwards.
When supporting INC, at least one of the nodes 130a to 130d may be an INC server or an INC cluster. INC is a technique with a concept of outsourcing even an operating function for data to a network beyond the level of requesting desired data to a network. The INC technique outsources a necessary operation work to network infrastructure even when there is no sufficient resource in a user device so that the operation work may be processed. In addition, in case the INC technique is utilized, when only an operation result for data present in a network is required, the client 110 may receive only a result of operation for data, which is executed at a location adjacent to the data, and thus network traffic may be reduced.
Referring to
In order to support in-network distributed computing in an NDN network, cross reference between a main program, which is executed in a user node, and a function instance operating in network infrastructure needs to be smoothly supported. In addition, a calculation result generated from one function instance should be available as input data of another function instance. However, since a time required for a function to be executed in a network and to return a result is variable because of the generation of an execution environment, download of an executable code and different complexities of executable codes, a synchronization method is required to exchange an execution result between a program requesting an INC function (hereinafter, referred to as ‘INC requester’) and a function instance.
An INC requester should be able to call an INC function and request and utilize a result when the result is needed. In case an INC requester requests an INC function and keeps waiting until a result is ready or, on the contrary, in case a function instance has to keep waiting because the INC requester has not confirmed a request of result even when a function is completely executed and a result is ready, the efficiency of a computing resource is degraded. This problem will become more significant when a function instance occupies a large resource.
Accordingly, a method for effectively sharing an execution result between an INC requester and a function instance is necessary. From the perspective of a main program that is executed in a user node, synchronous call and asynchronous call should be selectively used as necessary. In addition, from the perspective of a function instance, it should be dynamically determined whether to keep waiting while maintaining a calculated result or to store the calculated result using such a service as repository supported by network infrastructure, end the execution of a function and return a computing resource.
To this end, a calculation logic of a function and a method of returning a result need to be separated from each other. Thus, a function developer can focus on a calculation logic itself, and a method of transferring a calculation result may be determined independently of a main program. Accordingly, the present invention proposes an orchestration method for sharing an execution result between an INC function requester and a function instance in order to support in-network distributed computing in an NDN network. The proposed technique separates an execution logic of a function and a method of returning a result and thus has an advantage of independently selecting a method of sharing an execution result in a main program as necessary, irrespective of whether an INC function supports it or not.
In step S1, the client 310 node transmits, to a network, an INC interest packet that includes a function name (e.g. f_name) to be called from an application program in operation and information on data (e.g. d_name) to be processed. The interest packet is transferred to the INC server 332a, which is a closest INC server. Herein, the application program may specify a positioning policy for determining a function execution location, a constraint and the like in the interest packet. For example, the positioning policy may be defined as priority of proximity to data, priority of proximity to a client and the like, and a location capable of accepting a resource allocation request of CPU, GPU and memory as constraint may be defined. In this embodiment, for INC interest forwarding, an INC interest packet has a name beginning with a specific prefix of ‘/INC/”. Every INC server advertises an “/INC/” name and its own name to a network, and the information thus advertised is registered to FIB of the NDN routers 320a and 320b.
The INC server 332a of the first INC cluster 330a, which receives an INC interest packet from the client 310, selects an optimal cluster for executing a requested function by considering a user's positioning policy and constraint. In this embodiment, the second INC cluster 330b is selected. Accordingly, in the step S2, the INC server 332a transfers the INC interest packet to the INC server 332b which is in charge of the second INC cluster 330b. By designating a forwarding hint supported by NDN, the interest packet may be transferred between INC servers 322a and 322b with no change in interest name.
In the step S3, the INC server 332b, which receives the INC interest packet, is allocated a computing resource 334b within the second INC cluster 330b managed by the INC server 332b, generates an execution environment (EE) and generates a function instance by downloading and executing a function-executable code. Herein, the function instance thus generated is given a name accessible to the client 310.
In the step S4, the INC server 330b transmits a data packet to the client 310. The data packet includes a name (e.g. func_inst_name) of a function instance. That is, as a name of a function instance is included in an INC data packet, the name is transferred to an application program of the client 310. A name of a function instance is used to request an execution result of function later.
In the step S5, the client 310 and the computing resource 334b of the second INC cluster 330b perform direct communication. Thus, the client 310 is capable of obtaining a function execution result. Herein, a name (e.g. Func_inst_name) of a function instance is used. Specifically, an application program of the client 310 may request a function execution result by sending an NDN interest packet, which includes the received name of the function instance, and receive the function execution result.
Herein,
Referring to
When the INC function f1_save_result( ) is called in the client 510, a function instance is generated in an INP cluster 530. For example, like in the step S1 to step S3 of
The function f1 exemplified in
In the embodiment described with reference to
In case the KVS key is generated by the INC cluster 530, the INC cluster 530 generates the KVS key after receiving a request of function execution. Specifically, after receiving an interest packet, which requests execution of a function, from the client 510, the INC cluster 530 may generate the KVS key and include the KVS key in a data packet that is transmitted in the step S2. Accordingly, the client 510 may request an execution result of the function by using the KVS key that is obtained through the data packet.
In case the KVS key is generated by the KVS node 540, the KVS node 540 generates the KVS key after receiving a request of storing an execution result of the function. Specifically, after receiving an interest packet, which requests to store an execution result of the function, from the INC cluster 530, the KVS node 540 may generate the KVS key and include the KVS key in a data packet that is transmitted in the step S4. Next, the INC cluster 530 may transfer the KVS key to the client 510. For this, an additional packet may be transmitted or the step S2 may be implemented after the step S4.
Referring to
In the step S2, the FCH 714 transmits information necessary for a corresponding function call to a network through an INC interest packet, and the network transfers the INC interest packet to a suitable INC server 732 capable of executing a corresponding request.
In the step S3-1 and the step S3-2, the INC server 732 generates a first execution environment 736-1 and a second execution environment 736-2 and executes IFW according to a function execution mode based on a function factor that is transferred from the client 710 within the generated first execution environment 736-1 and the generated second execution environment 736-2. In this embodiment, a first IFW of the first execution environment 736-1 is executed in the standalone mode, and a second IFW of the second execution environment 736-2 is executed in the save result mode. When the IFWs are executed, a requested function is executed by a function handler, and a function execution mode is transferred to a result handler.
In the step S4-1 and the step S4-2, the result handler stores an execution result of the function. Herein, according to a function execution mode, a result handler of the first IFW temporarily stores an execution result, and a result handler of the second IFW stores an execution result in the KVS node 740.
In the step S5, the main program 712 of the client 710 determines that an INC function execution result is needed and transfers a request for an execution result to the INC GRH 716.
In the step S6-1 or the step S6-2, the GRH 716 of the client 710 transmits an interest packet requesting an execution result. Herein, a target of the request becomes different depending on which operation mode is designated in an existing INC function call. For example, in the case of the standalone mode, a result request interest is transferred to a result handler of a function instance. In the case of the save result, a result request is transferred to the KVS node 740 that is a third storage service device.
In the embodiment described above, the two modes of standalone and save_result are introduced as execution modes of functions, but the present invention is not limited to the execution modes that are exemplified, and it is possible to introduce any other type of execution modes. However, in this case, FCH and IFW should support the execution modes.
Accordingly, the present invention proposes an embodiment of calling an INC function in result save mode and thus supporting an asynchronous call of an INC function in a main program irrespective of an execution result of a previous function. When calling a function, it is determined beforehand, by operating an INC function in result save mode, which key of KVS is to be mapped with an execution result, and the key may be used as an execution result name of function f1 instance. Specifically, when calling function f2 that uses a result of function f1 as an input, a main program of a client transfers a data name of a result value, instead of transferring the actual result value of f1. Next, when an execution result value of function f1 is needed in the function f2 instance, the function f2 instance may obtain the result value by using the transferred name and apply the result value to operation.
Referring to
In the step S3, the client 810 transmits an interest packet, which requests execution of function f2, to a function f2 instance 838b. Herein, the interest packet includes, as input variables of function f2, a KVS key value (e.g. KVS Key #1), which is used to store an execution result of function f1, and a KVS key value (e.g. KVS_Key_#2) that is used to store an execution result of function f2. In addition, in the step S4, the client 810 receives a data packet, which includes a name (e.g. f2_inst_#n) of a function instance, from the function f2 instance 838b. In this embodiment, function f1 call in the step S1 and function f2 call in the step S3 may be performed almost simultaneously, and accordingly generation of an execution instance may start almost simultaneously.
In the step S5, the function f1 instance 838a executes the function f1 and transmits an interest packet, which includes an execution result (e.g. r1) of the function f1 and a corresponding KVS key value (e.g. KVS key#1), to the KVS node 840. In the step S6, the KVS node 840 stores the execution result (e.g. r1) of the function f1, which is included in the interest packet, and transmits a data packet, which includes ACK notifying success of reception, to the function f1 instance 838a.
In the step S7, the function f2 instance 838b transmits, to the KVS node 840, an interest packet, which includes a KVS key value (e.g. KVS_key#1) transferred as an input factor during the function f2 call, that is, provided by the client 810 to obtain an execution result of function f1. In the step S8, the KVS node 840 searches for an execution result (e.g. r1) of function f1 corresponding to the KVS key value (e.g. KVS_key#1) included in the interest packet and transmits a data packet including the execution result (e.g. r1) of function f1 to the function f2 instance 838b. Thus, the function f2 instance 838b may execute the function f2 by using the execution result (e.g. R1) of function 1 and obtain an execution result (e.g. r2) of function f2.
In the step S9, the function f2 instance 838b transmits, to the KVS node 840, an interest packet that includes the execution result (e.g. r2) of function 2 and a corresponding KVS key value (e.g. KVS_key#2). In the step S10, the KVS node 840 stores the execution result (e.g. r2) of the function f2, which is included in the interest packet, and transmits a data packet, which includes ACK notifying success of reception, to the function f2 instance 838b.
Next, in the step S11, the client 810 transmits an interest packet, which includes a KVS key value (e.g. KVS_key#2) used during the function f2 call, to the KVS node 840. In the step S12, the KVS node 840 searches for an execution result (e.g. r2) of function f2 corresponding to the KVS key value (e.g. KVS_key#2) included in the interest packet and transmits a data packet including the execution result (e.g. r2) of function f2 to the client 810.
In the embodiment described with reference to
Referring to
In the step S903, the client transmits a second packet that requests an execution result of the function. The second packet is transmitted to a device having a means of storing and providing the execution result of the function, for example, a KVS node.
For example, the second packet may include information for identifying the execution result of the function. Although not illustrated in
Referring to
In the step S1003, the INC server executes the function and obtains the execution result. For example, the INC server allocates a computing resource for executing the function and obtains the execution result by executing the function by means of the computing resource. Specifically, the INC server generates an instance for executing the function. The instance may include an operation logic of the function, a function handler executing the operation logic and a result handler processing the return of the execution result.
In the step S1005, the INC server transmits a second packet that requests to store the execution result of the function. The second packet is transmitted to a device having a means of storing and providing the execution result of the function, for example, a KVS node. Herein, when it is acknowledged that the execution result is stored in the KVS node, the computing resource allocated in the step S1003 is returned.
In order to implement the method according to the present disclosure, other steps may be included in addition to the illustrated steps, other steps may be included except some steps, or additional other steps may be included except some steps.
The various embodiments of the present disclosure do not list all possible combinations, but are intended to illustrate representative aspects of the present disclosure, matters described in various embodiments may be applied independently or in combination of two or more. In addition, various embodiments of the present disclosure may be implemented by hardware, firmware, software, or a combination thereof. For implementation by hardware, one or more application specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), general processor, a controller, a microcontroller, a microprocessor, and the like.
The scope of the present disclosure includes software or machine-executable instructions (eg, operating system, application, firmware, program, etc.) that cause an operation according to the method of various embodiments to be executed on a device or computer, and such software or and non-transitory computer-readable media in which instructions and the like are stored and executed on a device or computer.
| Number | Date | Country | Kind |
|---|---|---|---|
| 10-2020-0169195 | Dec 2020 | KR | national |
