Techniques are described herein for distributed data stream programming and processing. The techniques include sending a request indicating one or more regions of a program code to access a stream in a stream pool and to execute on a processing node in a processing nodes pool. The techniques also include accessing the stream defined in the one or more regions of the program code to service the request. Thereafter, the processing node is selected to use for execution of the one or more regions of the program code and the processing node executes one or more instances of the one or more regions of the program code.

To provide a low latency near RT RIC, some embodiments separate the RIC's functions into several different components that operate on different machines (e.g., execute on VMs or Pods) operating on the same host computer or different host computers. Some embodiments also provide high speed interfaces between these machines. Some or all of these interfaces operate in non-blocking, lockless manner in order to ensure that critical near RT RIC operations (e.g., datapath processes) are not delayed due to multiple requests causing one or more components to stall. In addition, each of these RIC components also has an internal architecture that is designed to operate in a non-blocking manner so that no one process of a component can block the operation of another process of the component. All of these low latency features allow the near RT RIC to serve as a high speed IO between the E2 nodes and the xApps.

A task processing method, a task processing device and an electronic device are provided, which relate to the field of cloud computing technology and big data technology, in particular to the field of task processing technology. The task processing method includes: obtaining a task processing request for a to-be-processed task, the task processing request including processing time information of the to-be-processed task and a service type of the to-be-processed task; in the case that the processing time information of the to-be-processed task meets a triggering condition, writing the to-be-processed task into a corresponding message queue in accordance with the service type of the to-be-processed task, one message queue corresponding to a respective one service type; and processing the to-be-processed task in the message queue, to obtain a task processing result of the to-be-processed task.

Systems and corresponding methods employ an object-oriented (OO) memory (OOM) to effect inter-hardware-client (IHC) communication among a plurality of hardware clients included in same. A system comprises a centralized OOM and the plurality of hardware clients communicate, directly, to the centralized OOM device via OO message transactions. The centralized OOM device effects IHC communication among the plurality of hardware clients based on the OO message transactions. Another system comprises a plurality of OO memories (OOMs) capable of inter-object-oriented-memory-device communication. A hardware client communicates, directly, to a respective OOM device via OO message transactions. The inter-object-oriented-memory-device communication effects IHC communication among the plurality of hardware clients based on the OO message transactions.

Methods for updating an application programming interface (API) field of a transaction message may include receiving, with at least one processor, a payment transaction message, wherein the payment transaction message comprises data associated with a payment transaction; determining, with at least one processor, one or more API fields of the payment transaction message based on the data associated with the payment transaction; and modifying, with at least one processor, one or more API fields of the payment transaction message. Methods may also include transmitting, with at least one processor, a modified payment transaction message based on modifying the one or more API fields of the payment transaction message. Systems and computer program products are also disclosed.

In a data transmission method, a plurality of communications submodules communicate in a parallel manner. A second communications submodule in the plurality of communications submodules sends, to a hardware queue, data for a first communications submodule. The first communications submodule obtains the data from the hardware queue when a state of writing data into the hardware queue is triggered. The hardware queue may be in a first processor for running the first communications submodule or in a second processor for running the second communications submodule.

Apparatuses, systems, and techniques to collect compute performance information. In at least one embodiment, an API is performed to cause two or more portions of at least one software program to be concurrently performed a plurality of times in order to generate one or more performance metrics.

Apparatuses, systems, and techniques to indicate contextual information to be used by available logical processors. In at least one embodiment, one or more circuits are to perform an application programming interface (API) to indicate a first set of contextual information to be used by a first subset of available processors.

A computer implemented method of executing a plurality of discrete software modules each including a machine learning algorithm as an executable software component configurable to approximate a function relating a domain data set to a range data set; a data store; and a message handler as an executable software component arranged to receive input data and communicate output data for the module, wherein the message handler is adapted to determine domain parameters for the algorithm based on the input data and to generate the output data based on a result generated by the algorithm, each module having associated a metric of resource utilization by the module, the method including receiving a request for a machine learning task; and selecting a module from the plurality of modules for the task based on the metric associated with the module.

Some embodiments of the invention provide a method of implementing an intent-based intrusion detection and prevention system in a datacenter that includes at least one host computer executing multiple machines. The method receives an intent-based application programming interface (API) command that defines intent for a set of one or more context-based intrusion detection rules for detecting and preventing intrusions on the at least one host computer. The method uses multiple contextual attributes to convert the defined intent into a set of one or more intrusion detection scripts for enforcement on the at least one host computer. The method provides the set of one or more intrusion detection scripts to an intrusion detection system operating on the at least one host computer for enforcement.