Orders received by an electronic trading system are processed in batches based on the instrument to which an order relates. An incoming order is assigned to a queue of a queue set that makes up the batch according to a random process. Where orders are received from related trading parties, they are assigned to the same queue set according to their time of receipt. The batch has a random duration within defined minimum and maximum durations and at the end of the batch, the orders held in the queues are transferred to a matching thread of the trading system sequentially with one order being removed from each queue and a number of passes of the queues completed until orders have been removed.

In general, techniques are described for supporting bulk delivery of change of authorization data in authentication, authorization, and accounting (AAA) protocols, where delivery is performed as a change of authorization after a subscriber has successfully authenticated and initially authorized. In one example, the techniques are directed to a method including determining, by a RADIUS server for a service provider network, change of authorization data for services to which the subscriber of the service provider network has subscribed. The method further includes generating, by the RADIUS server, RADIUS messages that form a transaction between the RADIUS server and a network access server acting as a RADIUS client. The RADIUS messages provide all of the change of authorization data to the network access server prior to the network access server provisioning the services. The method further includes outputting, by the RADIUS server, the RADIUS messages to the network access server.

Provided is an intrusion detection technique configured to: obtain kernel-filter criteria indicative of which network traffic is to be deemed potentially malicious, determine that a network packet is resident in a networking stack, access at least part of the network packet, apply the kernel-filter criteria to the at least part of the network packet and, based on applying the kernel-filter criteria, determining that the network packet is potentially malicious, associate the network packet with an identifier of an application executing in userspace of the operating system and to which or from which the network packet is sent, and report the network packet in association with the identifier of the application to an intrusion-detection agent executing in userspace of the operating system of the host computing device, the intrusion-detection agent being different from the application to which or from which the network packet is sent.

A computer-implementation method includes receiving a data packet; identifying a virtual queue from a list of virtual queues to which the data packet pertains; and determining whether the identified virtual queue size exceeds a threshold maximum size. When the first size does not exceed the threshold maximum size, the identified virtual queue is increased based on a size of the data packet and the data packet is forwarded. The method further includes setting a virtual queue from the list of virtual queues as a target queue; determining a service capacity based on an update time interval and increasing a credit allowance based on the service capacity. The target queue is reduced by an amount based on the credit allowance size, and the credit allowance is reduced by the same amount.

Systems and methods for providing Chronos Channel interconnects in an ASIC are provided. Chronos Channels rely on a reduced set of timing assumptions and are robust against delay variations. Chronos Channels transmit data using delay insensitive (DI) codes and quasi-delay-insensitive (QDI) logic. Chronos Channels are insensitive to all wire and gate delay variations, but for those belonging to a few specific forking logic paths called isochronic forks. Chronos Channels use temporal compression in internal paths to reduce the overheads of QDI logic and efficiently transmit data. Chronos Channels are defined by a combination of a DI code, a temporal compression ratio and hardware.

Systems and methods for providing Chronos Channel interconnects in an ASIC are provided. Chronos Channels rely on a reduced set of timing assumptions and are robust against delay variations. Chronos Channels transmit data using delay insensitive (DI) codes and quasi-delay-insensitive (QDI) logic. Chronos Channels are insensitive to all wire and gate delay variations, but for those belonging to a few specific forking logic paths called isochronic forks. Chronos Channels use temporal compression in internal paths to reduce the overheads of QDI logic and efficiently transmit data. Chronos Channels are defined by a combination of a DI code, a temporal compression ratio and hardware.

An endpoint processing device is provided for dynamically controlling latency tolerance reporting (LTR) values. The endpoint processing device comprises memory configured to store data and a processor. The processor is configured to execute a program and send, to a root point processing device via a peripheral component interconnect express (PCIe) link, a plurality of messages each comprising a memory access request and a LTR value indicating an amount of time to service the memory access request. The processor is also configured to, for each of the plurality of messages, determine, during execution of the program, a LTR value setting and set the LTR value as the determined LTR value setting.

A system is described whereby a cloud router may allow routing as a service in a cloud-like manner. In an example, an apparatus may include a processor and a memory coupled with the processor that effectuates operations. The operations may include receiving first routing information associated with a first customer edge device; adding the first routing information to network routing information of the apparatus, wherein the network routing information comprises a network routing table with routes for a plurality of networks; and propagating the network routing information to a software defined network (SDN) controller, wherein, based on the network routing information, the SDN controller sends a forwarding information base (FIB) to a provider edge device connected with the first customer edge device.

A system is described whereby a cloud router may allow routing as a service in a cloud-like manner. In an example, an apparatus may include a processor and a memory coupled with the processor that effectuates operations. The operations may include receiving first routing information associated with a first customer edge device; adding the first routing information to network routing information of the apparatus, wherein the network routing information comprises a network routing table with routes for a plurality of networks; and propagating the network routing information to a software defined network (SDN) controller, wherein, based on the network routing information, the SDN controller sends a forwarding information base (FIB) to a provider edge device connected with the first customer edge device.

A method supports service level agreement monitoring in a software defined network. The software defined network has forwarding elements and a software defined network controller for controlling the forwarding elements. Data flows are transmitted between a first end-path forwarding element, of the forwarding elements, and a second end-path forwarding element, of the forwarding elements, via at least one intermediate forwarding element, of the forwarding elements. The software defined network controller configures the intermediate forwarding element such that a probe triggering packet is generated based on local information of the intermediate forwarding element. The software defined network controller configures at least one of the first end-path forwarding element or the second end-path forwarding element such that an end-to-end probing is triggered based on receiving the probe triggering packet. The end-to-end probing is performed in order to detect a service level agreement violation.