阅读说明：本技术 优先队列中本地存储数据的整数转换 (Integer conversion of locally stored data in priority queue ) 是由 徐茂栋 阿舒·斯瓦米 于 2020-02-25 设计创作，主要内容包括：一种馈送处理器(140)被配置成从数据馈送(131)接收(510)交易条目(315),交易条目(315)至少指示浮点值金额,数据馈送(131)与交易目标(321F)相关联。馈送处理器(140)通过以下方式基于交易条目(315)修改本地存储的优先级队列：基于由交易目标(321F)指示的两个基础分量之间的比率将交易条目(315)中的浮点值金额转换(520)为整数值金额；以及将整数值金额存储(530)在本地存储的优先级队列中的对应条目中。(A feed processor (140) is configured to receive (510) a transaction entry (315) from a data feed (131), the transaction entry (315) indicating at least an amount of a floating point value, the data feed (131) being associated with a transaction target (321F). The feed processor (140) modifies the locally stored priority queue based on the transaction entry (315) by: converting (520) the floating-point value amount in the transaction entry (315) to an integer value amount based on a ratio between two base components indicated by the transaction target (321F); and storing (530) the integer value amount in a corresponding entry in a locally stored priority queue.)

1. A system, comprising:

a feed processor configured to:

receiving a transaction entry from a data feed, the transaction entry indicating at least an amount of a floating point value, the data feed associated with a transaction target;

modifying a locally stored priority queue based on the transaction entry by:

converting the floating-point value amount in the transaction entry to an integer value amount based on a ratio between two base components indicated by the transaction target; and

storing the integer value amount in a corresponding entry in the locally stored priority queue.

2. The system of claim 1, wherein the data feed is received from a remote data feed server, and wherein the feed processor communicates with the remote feed server using a reduced version of the transmission control protocol/internet protocol (TCP/IP), the reduced TCP/IP protocol avoiding delays due to TCP/IP handshaking.

3. The system of claim 1 or 2, further comprising a client device connected to the feed processor via a network and configured to: presenting a graphical user interface to a user of the client device, the interface including one or more web pages that present data from the locally stored priority queue.

4. The system of claim 1, 2 or 3, wherein the locally stored priority queue is a binary search tree, BST, indexed according to the integer value of money for each entry in the binary search tree, BST.

5. The system of claim 4, further comprising a hash table having as keys transaction entry identifiers and as values references to corresponding transaction entries in the BST.

6. The system according to any of the preceding claims, wherein the ratio is a ratio between a first unit value of a first of the two basis components and a second unit value of a second of the two basis components.

7. The system according to any of the preceding claims, wherein the floating point values are converted to the integer values by:

calculating an index value based on the ratio;

shifting a decimal of the floating-point value by the exponent to generate a shifted floating-point value; and

generating the integer value from the shifted floating-point values by rounding the shifted floating-point values to integers.

8. A system according to any preceding claim, wherein the floating point value amount is a relationship between a first component and a second component, the floating point value being indicative of a requested amount to redeem the second component in units of the first component.

9. The system of claim 8, wherein the redemption is recorded on one or more blockchains once executed.

10. The system of any preceding claim, wherein the feed processor is configured to: a plurality of transaction entries are received from a plurality of different data feeds and data from the plurality of transaction entries is combined into a single locally stored priority queue.

11. A computer-implemented method, comprising:

receiving a transaction entry from a data feed, the transaction entry indicating at least an amount of a floating point value, the data feed associated with a transaction target;

modifying a locally stored priority queue based on the transaction entry by:

converting the floating-point value amount in the transaction entry to an integer value amount based on a ratio between two base components indicated by the transaction target; and

storing the integer value amount in a corresponding entry in the locally stored priority queue.

12. The method of claim 11, wherein the data feed is received from a remote data feed server, and wherein the feed processor communicates with the remote feed server using a reduced version of the transmission control protocol/internet protocol (TCP/IP), the reduced TCP/IP protocol avoiding delays due to TCP/IP handshaking.

13. The method of claim 11 or 12, further comprising a client device connected to the feed processor via a network and configured to: presenting a graphical user interface to a user of the client device, the interface including one or more web pages that present data from the locally stored priority queue.

14. The method of claim 11, 12 or 13, wherein the locally stored priority queue is a binary search tree, BST, indexed according to the integer-value amounts of each entry in the binary search tree, BST.

15. The method of claim 14, further comprising a hash table having as keys transaction entry identifiers and as values references to corresponding transaction entries in the BST.

16. The method according to any of claims 11-15, wherein the ratio is a ratio between a first unit value of a first of the two basis components and a second unit value of a second of the two basis components.

17. A method according to any of claims 11 to 16, wherein the floating point values are converted to the integer values by:

calculating an index value based on the ratio;

shifting a decimal of the floating-point value by the exponent to generate a shifted floating-point value; and

generating the integer value from the shifted floating-point value by rounding the shifted floating-point value to an integer.

18. A method according to any one of claims 11 to 17, wherein the floating point value is a relationship between a first component and a second component, the floating point value being indicative of a requested amount to redeem the second component of units of the first component.

19. The method of claim 18, wherein the redemption is recorded on one or more blockchains once performed.

20. The method of any of claims 11 to 19, further comprising: receiving a plurality of transaction entries from a plurality of different data feeds; and combining data from the plurality of transaction entries into a single locally stored priority queue.

21. Software which when executed causes the method of any one of claims 11 to 20 to be performed.

Technical Field

The present invention relates generally to data processing optimization and compression, and in particular to integer conversion for locally stored data in a priority queue.

Background

In some networked systems, a first computing device (e.g., a feed processor server) may receive a data feed from a second computing device (e.g., a remote server). The data feed may include a plurality of entries including data regarding information that is continuously updated. Upon updating the information, the data feed generates a new entry or element that is transmitted to the first computing device. Upon receiving the new data feed entry, the first computing device may process the data contained in the new data feed entry and store it locally in the local database. In addition, the first computing device may provide the information contained in the local database to various client devices for use by one or more users. In some cases, any data received from the data feed should be provided to the client device with as little delay as possible. However, this may be difficult to achieve when the amount of received data is large and the rate at which the data is received is high. Therefore, there is a lack of a method to implement more optimal data compression of data received from a data feed at a local database in order to reduce delays in the data feed update process and reduce resource usage during the process.

In this specification, the word "comprise", or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.

Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present invention as it existed before the priority date of each appended claim.

Disclosure of Invention

Embodiments relate to a system comprising a feed processor configured to receive transaction entries from a data feed. The transaction entry indicates at least an amount of the floating point value, and the data feed is associated with a transaction target. The feed processor modifies the locally stored priority queue based on the transaction entry by: the floating-point value amount in the transaction entry is converted to an integer value amount based on a ratio between the two base components indicated by the transaction target. The feed processor stores the integer values in corresponding entries in a locally stored priority queue.

A data feed may be received from a remote data feed server, and wherein the feed processor may communicate with the remote feed server using a reduced version of the transmission control protocol/internet protocol (TCP/IP), the reduced TCP/IP protocol avoiding delays due to TCP/IP handshaking.

The system may also include a client device connected to the feed processor via a network and configured to: a graphical user interface is presented to a user of the client device, the interface including one or more web pages that present data from the locally stored priority queue.

The locally stored priority queue may be a Binary Search Tree (BST) indexed by the integer value of money for each entry in the BST. The system may also include a hash table having as keys transaction entry identifiers and as values references to corresponding transaction entries in the BST.

The ratio may be a ratio between a first unit value of a first base component of the two base components and a second unit value of a second base component of the two base components.

Floating point values may be converted to integer values by: calculating an index value based on the ratio; shifting decimal digits of the floating-point value by an exponent to generate a shifted floating-point value; and generating an integer value from the shifted floating-point values by rounding the shifted floating-point values to integers.

The floating point value amount may be a relationship between the first component and the second component, the floating point value indicating a requested amount for redemption of the second component in units of the first component. The redemption, once performed, may be recorded on one or more blockchains.

The feed processor may be configured to receive a plurality of transaction entries from a plurality of different data feeds and combine data from the plurality of transaction entries into a single locally stored priority queue.

Another embodiment relates to a computer-implemented method. The computer-implemented method may include receiving a transaction entry from a data feed, the transaction entry indicating at least an amount of a floating point value, the data feed associated with a transaction target. The computer-implemented method may further include modifying the locally stored priority queue based on the transaction entry by: converting the floating-point value amount in the transaction entry to an integer value amount by based on a ratio between two base components indicated by the transaction target; and storing the integer value amount in a corresponding entry in a locally stored priority queue.

A data feed may be received from a remote data feed server, and wherein the feed processor may communicate with the remote feed server using a reduced version of the transmission control protocol/internet protocol (TCP/IP), the reduced TCP/IP protocol avoiding delays due to TCP/IP handshaking.

The method may further include a client device connected to the feed processor via a network and configured to: a graphical user interface is presented to a user of the client device, the interface including one or more web pages that present data from the locally stored priority queue.

The locally stored priority queue may be a Binary Search Tree (BST) indexed by the integer value of money for each entry in the BST. The method may also include a hash table having as keys transaction entry identifiers and as values references to corresponding transaction entries in the BST.

The ratio may be a ratio between a first unit value of a first base component of the two base components and a second unit value of a second base component of the two base components.

Converting floating point values to integer values by: calculating an index value based on the ratio; shifting decimal digits of the floating-point value by an exponent to generate a shifted floating-point value; and generating an integer value from the shifted floating-point values by rounding the shifted floating-point values to integers.

The floating point value may be a relationship between the first component and the second component, and the floating point value may indicate a requested amount of money for redeeming the second component in units of the first component. The redemption, once performed, may be recorded on one or more blockchains.

The method may further include receiving a plurality of transaction entries from a plurality of different data feeds; and combining data from multiple transaction entries into a single locally stored priority queue.

Another embodiment relates to software as computer readable instructions (transitory or non-transitory) that when executed cause the above method to be performed.

Drawings

Figure (fig. 1) illustrates an example system that includes a data feed and a feed processor server, according to an embodiment.

Fig. 2 is a block diagram illustrating components of the feed processor server of fig. 1, according to an embodiment.

Fig. 3 is a block diagram illustrating an example of an optimized computer data structure in which data feed entries from remote data feeds are stored, according to an embodiment.

Fig. 4 is a block diagram and flow diagram illustrating an example conversion of data received from a data feed to increase data compression, according to an embodiment.

Fig. 5 is a flow diagram illustrating an example process for data compression of data received from a remote data feed, according to an embodiment.

Fig. 6A is a block diagram illustrating a transaction chain recorded on a blockchain that may be used in the system described in fig. 1, according to an embodiment.

Fig. 6B is a block diagram illustrating the connection of multiple tiles in a chain of tiles that may be used in the system described in fig. 1, according to an embodiment.

Fig. 7 is a block diagram illustrating an example computing device, according to an embodiment.

The drawings depict and detailed description various non-limiting embodiments for purposes of illustration only.

Detailed Description

The drawings (figures) and the following description relate to preferred embodiments by way of illustration only. One skilled in the art may recognize alternative embodiments of the structures and methods disclosed herein as viable alternatives that may be employed without departing from the principles disclosed.

Reference will now be made in detail to several embodiments, examples of which are illustrated in the accompanying drawings. It should be noted that wherever practicable similar or like reference numbers may be used in the figures and may indicate similar or like functionality. The figures depict embodiments of the disclosed system (or method) for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.

Overview of the System

Fig. 1 illustrates an example system 100 including a data feed and a feed processor server, according to an embodiment. System 100 includes a network 110, one or more client devices 120 (referred to as multiple client devices 120 or one client device 120), a remote data feed server 135, one or more remote data source servers 135, and a feed processor server 140. In various embodiments, system 100 may include different, fewer, or additional components. The components in the system 100 may each correspond to a separate and independent entity or may be controlled by the same entity.

Communications between elements in system 100 may be transmitted via network 110, which may be, for example, the internet, a local area network, etc. Some elements may communicate over one network while other elements may communicate using a separate network. Each of these separate networks may be similar to network 110. In one embodiment, the network 110 uses standard communication technologies and/or protocols. Thus, the network 110 may include a network using, for example, Ethernet, 702.11, direct microwave point-to-point connection, Worldwide Interoperability for Microwave Access (WiMAX), 3G, Digital Subscriber Line (DSL), Asynchronous Transfer Mode (ATM), InfiniBand, PCI express advanced switching, or the like. Similarly, the network protocols used on network 110 may include multiprotocol label switching (MPLS), transmission control protocol/internet protocol (TCP/IP), User Datagram Protocol (UDP), hypertext transfer protocol (HTTP), Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), and the like. Data exchanged over network 110 may be represented using techniques and/or formats including hypertext markup language (HTML), extensible markup language (XML), and the like. In addition, all or some of the links may be encrypted using conventional encryption techniques, such as Secure Sockets Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), internet protocol security (IPsec), and so forth. In another embodiment, elements in system 110 may use custom and/or dedicated data communication techniques instead of or in addition to those described above. For example, network 110 may use a reduced TCP/IP protocol that avoids TCP/IP handshake penalties between elements to reduce communication delays.

One or more client devices 120 are computing devices that can be operated by a user and used by the user as a front-end device with which the user can access data at feed processor server 140. Client device 110 may be any computing device. Examples of client device 110 include a Personal Computer (PC), a desktop computer, a laptop computer, a tablet computer, a smartphone, a wearable electronic device such as a smart watch, or any other suitable electronic device.

The user devices 110 may each include an interface 125, which may be provided by computer readable instructions executed by the feed processor server 140 or by the client device 120. The user can access the data via the interface 125 or be available at the feed processor server 140. In addition, the user can also submit a transaction request via the interface 125. The interface 125 may take different forms. In one embodiment, interface 125 is a component of a software application that may be provided by feed processor server 140. For example, the software application may provide a front-end user interface that may be provided at the client device 120. The software application may be a computer-executable code package that may be acquired (e.g., downloaded) and installed or executed at the client device 120. In another embodiment, the interface 125 may be an interface provided directly via the feed processor server 140 or other server. For example, the interface 125 may be one or more web pages. The interface 125 may include a Graphical User Interface (GUI) that displays various information and graphical elements. In another embodiment, interface 125 may not include graphical elements but may communicate with feed processor server 140 via other suitable means, such as an Application Program Interface (API).

The remote data feed server 130 (referred to herein as remote data feed server 130 or remote data feed server 130) may be one or more computing systems that each individually provide one or more data feeds 131 (referred to herein as data feeds 131 or collectively as data feeds 131) to the feed processor server 140. The data feed 131 includes information about a particular data source or persistent update of a data source, such as a remote data source server 135. The data sources may contain information about some elements described in the data feed 131, such as transactions (e.g., orders in financial markets, purchase orders in retail organizations, logistics updates, shipping information), news (e.g., breaking news), forecasts (e.g., weather reports), current status (e.g., equipment status, public transportation, satellite location), and so forth. The data feed 131 may be provided using various data formats such as CSV (comma separated values), XML (extensible markup language), and the like. The data feed may be provided using a custom format, such as using an extended character set or using binary characters, and the data therein may be encrypted prior to transmission.

The data feed 131 may be transmitted in one or more updates as it is provided. Each update may occur as data is generated or may be generated periodically. For example, in the case of a transaction, an entry in the data feed 131 may be provided for each new transaction that is detected, generated, recorded, etc. Each update may have information (e.g., an identifier) about the data feed 131 itself, as well as information about the described elements. For example, in the case of a transaction, the corresponding data feed entry may include information regarding the transaction type, the amount of value, the transaction timestamp, and the like. By receiving data feed updates, a recipient computing device, such as feed processor server 140, can determine the current state of the elements described in the data feed 131. For example, where the data feed 131 includes information about transactions, receipt of the data feed 131 allows the system to determine the complete status of the transactions described by the data feed, i.e., determine the current status of the market/exchange that includes those transactions. Additional details regarding the format of the data feed 131 will be described below with reference to fig. 2-5.

A feed processor server 140 comprising one or more computing systems receives updates from the data feed 131 and generates a local version 141 of the information in the data feed 131. The feed processor server 140 can process the data feed 131 using a method that reduces the processing time required to process updates to the data feed 131 and by reducing the resource requirements for storing the local version 141. In one embodiment, to reduce processing time, the feed processor server 140 may use a reduced TCP/IP protocol, using custom network hardware, to receive the data feed 131 from the remote data feed server 130. The feed processor server 140 may also use direct memory access to store the data feed 131 after it is received.

Further, the feed processor server 140, when storing the information of the local version 141 in the data feed 131, may convert the data from the data feed 131 into the local version 141 using an optimized process using the optimal data structure of the local version 141. In one embodiment, the local version 141 may include a plurality of priority queues that store updates from the data feeds 131 in priority according to the time the update was received (or by timestamps within the data feed entries in the update), and may further store data according to some other information within each update, such as the amount of value indicated in each data feed entry of the update.

In addition, feed processor server 140 may compress data from data feed updates to reduce the size of data occupied within the memory of feed processor server 140. In particular, in some cases, the data feed 131 includes entries having floating point or decimal values that occupy a large amount of memory footprint, and the memory allocated for these values must accommodate a wide range of changes to these values. These numbers may represent the ratio between two values about which the data feed 131 entry includes information. For example, the value may indicate a ratio between total greenhouse gas emissions and global temperature changes. As another example, the value may indicate a ratio between two different currencies (i.e., a price or cost of purchasing one currency in another currency). In many of these cases, the ratio may be a very large or small number because the magnitude difference between the two values being compared is large. Continuing with the previous example, large amounts of greenhouse gases may be emitted so that small temperature variations occur. As another example, the exchange rate between two currencies may be very large, as one unit of one currency may be exchanged for a large amount of another currency. Furthermore, in some cases, these ratios may vary greatly in scale over time. For example, the exchange rate between two currencies may fluctuate dramatically due to market instability. As another example, the ratio between the device count on the network and the total network usage may vary significantly over time, depending on the peak in network usage.

Thus, to store these values, the local version 141 may have to allocate a large amount of memory space to store each of these values, because they may be very large or very small numbers, and because they may vary in size by many orders of magnitude. Such use of resources is not necessarily optimal as it may result in the memory size of the local version 141 exceeding the available memory, especially if the data feed 131 is updated very frequently.

Rather, to avoid these problems, the values may be modified to reduce the space they use while still maintaining the accuracy of the data in the values. As described in more detail below with respect to fig. 2-5, feed processor server 140 modifies (i.e., shrinks or compresses) the values by modifying the values with an index value that results from the difference between the two components that make up the ratio indicated by the value. Continuing with the previous example, the index value may be calculated based on a ratio between the two currencies used to generate the currency conversion ratio value. The index may be used to modify the currency exchange value to reduce its size while still retaining the appropriate transaction resolution in the form of a scale size.

Using a combination of optimizing resource usage and modifying received data, the load processing server 140 can reduce the latency and resources required to process updates from the data feed 131 and have those updates reflected in the local version 141. Although the description above is primarily with respect to a single data feed 131, in some cases, the feed processor server 140 may process updates of multiple data feeds 131 from multiple sources (e.g., multiple venues) and combine data feed entries from these multiple data feeds into the local version 141 to form a combined or aggregated version of all of the data feeds 131 at the local version 141. This allows users accessing the local version 141 to be able to view data from multiple data feeds 131 and make decisions, request transactions, etc., based on multiple data feeds rather than a single data feed.

The system 100 may also optionally include one or more blockchains (not shown) that may be accessed by elements on the network 110 to record transactions performed on the blockchains. For example, data feed 131 may include data regarding exchange rates between various cryptocurrencies with transaction ledgers recorded on various blockchains. Due to the nature of the local version 141 and the feed processor server 140 as described above, the client device 120 may be able to view information about all data feeds 131 in real time without significant delay by accessing the local version 141 on the feed processor server 140. The user may then be able to perform transactions to redeem these various cryptocurrencies using the client device 120, e.g., via the interface 125. Upon completion of the transaction, feed processor server 140 or some other entity may submit the transaction to the corresponding blockchain to effect completion of the transaction. The blockchain may be a common blockchain. The common blockchain network may include a plurality of nodes that cooperate to validate transactions and generate new blocks (transaction information about cryptocurrency may be recorded). In some implementations of a blockchain, the generation of new blocks may also be referred to as a mining process. A blockchain may support an intelligent contract, which is a set of code instructions that are executable when one or more conditions are satisfied. When triggered, the set of code instructions may be executed by a computer, such as a virtual machine of a blockchain. Here, the computer can be a single unit of operation in the conventional sense (e.g., a single personal computer), or can be a set of distributed computing devices (e.g., virtual machines or distributed computing systems) that cooperate to execute code instructions. Examples of such common blockchain platforms include bitcon, ETHEREUM, EOS, NEO, CARDANO, STELLER, and the like.

Example feed processor Server

Fig. 2 is a block diagram illustrating components of the feed processor server 140 of fig. 1, according to an embodiment. In the embodiment shown in fig. 2, the feed processor server 140 includes a high-speed memory 210 having a remote feed cache 215, an inbound list 220, and an outbound list 225. Feed processor server 140 also includes a reduced Networking Interface Controller (NIC)230, a Direct Memory Access (DMA) module 240, a feed decryptor 245, an integer conversion engine 250, a list modifier 255, and a UI generator 260. The functionality of feed processor server 140 may be distributed among different components in a different manner than that described. Moreover, in various embodiments, feed processor server 140 may include different, fewer, and/or additional components.

The high speed memory 210 may function similar to the main memory 604 in FIG. 7 and may be selected for low latency characteristics and high bandwidth throughput. The high speed memory 210 may include a plurality of memory modules arranged in a multi-channel configuration. Further, the high speed memory 210 may include memory across multiple computing devices. The cache 210 may store a remote feed cache 215 and a local version 141 of the data feed 131, which may be represented using a plurality of separate lists, such as an inbound list 220 for inbound transactions and an outbound list 225 for outbound transactions, as shown.

The remote feed cache 215 stores a temporary copy of any updates received from the remote data feed server 130 for the data feed 131. As updates are processed by feed processor server 140, they are purged from remote feed cache 215.

The inbound list 220 stores entries from the data feed 131 indicating inbound transactions. These indicate the transactions to which a particular transaction flows, indicate who initiated the transaction, and for whom the transaction is directed. The transaction flow for inbound transactions is opposite to the transactions stored in the outbound list 225. In one embodiment, the inbound transaction is a purchase order for a security, such as an open request to purchase a cryptocurrency listed at a particular price and unit quantity in exchange for another cryptocurrency.

The outbound list 225 stores entries from the data feed 131 indicating outbound transactions. The outbound transaction has a reverse transaction flow direction as the inbound transaction, as depicted in the inbound list 220. In one embodiment, the inbound transaction is a sell order for a security, such as an open order listed at a particular price and unit quantity for selling cryptocurrency in exchange for another cryptocurrency.

As described in further detail below with respect to fig. 3 and 4, the inbound list 220 and outbound list 230 may be structured in a manner that reduces the time required to add, remove, and/or modify entries within each list, while keeping the entries in the lists ordered by various characteristics, such as timestamps. In one embodiment, the inbound list 220 and outbound list 230 may be stored as a binary search tree, as shown in FIG. 3.

Each entry of the inbound list 220 or the outbound list 230 may include an entry indicating a value of a transaction indicating a ratio or other combination (e.g., average, weighted average, difference, product) between two base components. For example, the value may indicate an exchange rate price between two currencies. Alternatively, as described above, the value may indicate two measurements or some other ratio between the values. Since the value may change drastically based on the change in the underlying component, the storage of the value may take up a large amount of space. For example, the difference between the two base components a and B may fluctuate in the range of 100 to one million times. In this case, the storage requirement for the ratio between a and B would require enough space to store a series of values to accommodate the entire range of differences between a and B, for example up to 1000 ten thousand. Since the range of values is large, the values cannot be scaled simply by deleting significant digits. For example, when the value approaches 100, deleting more than 3 significant digits from the number may result in the number being registered as zero. However, this may consume a large amount of memory space and, in the case of data feeds 131 being updated very frequently, may cause the load processing server 140 to run out of memory space. Rather, as described below, the modification procedure is applied to the dynamically altered value based on the difference between the base components used to calculate the value. This may reduce the memory requirements to store the value and, thus, reduce the memory footprint of the inbound list 220 and the outbound list 225.

Although two lists 220 and 225 are shown herein, in other embodiments, the load handling server 140 maintains additional lists based on the type of underlying data represented in the lists. For example, where the list indicates a currency exchange rate, the load processing server 140 may maintain an inbound list and an outbound list for each observed currency pair combination or data received from the data feed 131.

The reduced Networking Interface Controller (NIC)230 is a network interface controller that uses a modified networking protocol to reduce communication delays between the feed processor server 140 and the remote data feed server 130. In one embodiment, the reduced NIC230 communicates with the remote data feed service 130 using microwave or other wireless communications to reduce latency. The reduced NIC230 may be coupled to a microwave transmitter/receiver (e.g., a parabolic antenna) for transmitting and receiving microwave signals. In one embodiment, the reduced NIC230 also communicates with the remote data feed server 130 using a reduced version of the standard networking protocol. A reduced version of a standard networking protocol, such as TCP/IP, may remove certain features of the protocol, such as Acknowledgements (ACKs), handshaking protocols, etc., in order to further reduce the delay caused by the overhead created by the requirements of the standard networking protocol. Once the thin NIC230 receives updated information regarding the data feeds 131 from the remote data feed server 130, the thin NIC230 may transmit the information to a Direct Memory Access (DMA) module 240 for temporary storage in the remote feed cache 215.

The DMA module 240 provides direct access to the high speed memory 210, bypassing the memory management system of the operating system executing on the feed processor server 140 (and also bypassing the use of a Central Processing Unit (CPU) to read and write memory). Typically, an Operating System (OS) includes various memory management systems, such as virtual memory management, memory protection systems (e.g., to prevent buffer overflows), and so forth. These increase the overhead and processing time of reading and writing to memory. Rather, the DMA module 240 may be a custom component within the memory management system of the OS, a special module within the OS kernel, a device driver, or some other component that allows direct access to physical memory (e.g., the high speed memory 210).

Prior to establishing the initial session to receive the data feed 131, the feed decryptor 245 may optionally be used to decrypt data received from the data feed 131 or perform initial authentication with the remote data feed server 130. Updates to the data feed 131 received by the feed processor server 140 may be encrypted to prevent unauthorized entities from accessing information in the data feed 131, as they may contain sensitive or proprietary information. The feed decryptor 245 may thus decrypt the updates using standard decryption processes such as public key cryptography. The feed decryptor 245 may decrypt the data online before it is written to the high speed memory 210 and after it is received by the thin NIC230, or the feed decryptor may decrypt the data after it is written to the high speed memory 210, for example, when it is in the remote feed cache 215.

The integer conversion engine 250 converts some of the values in the data entries received from the update of the data feed 131 from a floating point or larger memory footprint format to integer data types having a smaller memory footprint. As described above, the updates received from the data feed 131 can include values based on a rate that can change by orders of magnitude over time. This requires a larger memory area to be allocated to store these values. Therefore, data compression is required for these values. To reduce the space required to store these values, the integer conversion engine 250 may calculate an exponent value that is based on the ratio of the base components used to generate the value. In one embodiment, the index is generated using the following algorithm:

the index is min (8, max (0, 4-integer (log))₁₀(ratio (Unit value of component A Unit value of component B) … … (1)

Thus, to generate the exponent, the integer conversion engine 250 determines a unit value for generating the base component of the original value received from the data feed 131. The unit value is a value of a single unit of each base component. Where the raw value indicates an exchange rate, the base component is the currencies used to generate the exchange rate, and the unit value is the value of a single unit of each currency. These unit values may be calculated from a third currency, such as a legal currency (e.g., U.S. dollars) or other stable currency. Therefore, in this case, the "ratio" mentioned in the above equation (1) is the following value: the value of one unit of the first currency (component a) relative to the third currency divided by one unit of the second currency (component B) relative to the third currency. Alternatively, the third currency is not used and the rate may be a current market rate or a historical exchange rate between the first currency and the second currency. The market rate may be based on a last executed market order for the exchange between the first currency and the second currency. A log-base 10 operation is performed on the calculated ratio values and then converted to integers (using rounding, lower or upper limit operations). The integer conversion engine 250 further determines the difference between the result value and the value 4, and then determines the maximum value between the difference result and a zero value. Finally, the integer conversion engine 250 determines a minimum value between the value of 8 and the result from the previous minimum value determination. The maximum determined result is an index.

The exponent value is used to modify the original value by multiplying the original value by 10^ exponent (i.e., shift the decimal point of the original value by the exponent value), and further rounding the result to an integer to generate the integer conversion value. This operation reduces the size of the original value while allowing sufficient minimum resolution if the integer converted value is converted back to the original value. In the case of currency conversion, this minimum resolution is the scale size. The scale size is the minimum price variation of the currency. Since the conversion of the integer conversion value is dynamic and based on the current difference between the two base currencies, the integer conversion value will have sufficient resolution so that the scale size can always be below some threshold, e.g., 1/100 for one currency in terms of the exchange rate of the original value.

Furthermore, where the underlying components are different currencies, the exchange of the two currencies may occur in two different transaction flows (the first currency being the second, or the second currency being the first). In this case, two different ratios may be determined, one for each direction, and two different index values may be generated. After calculating the integer conversion value, the integer conversion engine 250 transmits the integer conversion value to the list modifier 255.

The integer conversion engine 250 may periodically recalculate the exponent values based on updated data (e.g., updated exchange rates) and generate integer converted values based on the new exponent values. When an update of the exponent value occurs, the integer conversion engine 250 may re-convert all existing integer conversion values in the inbound list 220 and outbound list 225 using the new exponent value, may instruct the list modifier 255 to save the new exponent value for each integer conversion value within each entry in the list, or may include a separate list or hash table of exponent values indicating a range of integer conversion values (e.g., a range indicating a duration).

The list modifier 255 stores the integer-converted values within the data feed 131 of the local version 141. In the example shown in FIG. 2, the local version 141 is represented by inbound lists 220 or outbound lists 225, where each list stores an integer conversion value of a transaction flow. However, in other cases, list modifier 255 may also store values in different lists depending on the type of data being processed. In the event that the entry in the update from the data feed entry 131 does not correspond to an existing entry within the local version 141, the list modifier 255 adds the new entry to the local version 141. However, in the event that an entry from the data feed 131 updates an existing entry, the list modifier 255 will look for the existing entry through the identifier provided in the entry from the data feed 131 and update the existing entry with new data from the data feed 131, including any new integer conversion values.

In some cases, the updated entry from the data feed 131 indicates that the existing entry in the local version 141 should be removed. In this case, the list modifier 255 removes the entry from the local version 141 based on the provided identifier. Further, where the transaction represents an order, such as a currency converted order, the updated entry from the data feed 131 may indicate that the order is partially or fully populated. In this case, the list modifier 255 may remove or modify existing transactions in the local version 141 corresponding to the filled orders according to the identifiers of the orders provided by the updates from the data feed 131.

While some of the examples above are described with respect to currency conversion, the same process may be applied to other scenarios where values received from data feeds or other data sources vary widely in magnitude and thus may be converted to smaller, more space efficient integer values, rather than larger values or floating point values, the latter requiring a larger memory footprint. In these scenarios, the "ratio" in equation (1) shown above may be the ratio between the base components of the original values measured in one unit time. Thus, for example, if the ratio is the network throughput per unique number of user sessions in the local network, then the unit values of the base component may be the network throughput per second (unit time) and the number of unique user sessions recorded per second.

The UI generator 260 generates a graphical user interface that presents the data feed 131 to a user (e.g., a user of the client device 120) using a local version of the data feed 131, such as the inbound list 220 and the outbound list 225. Although UI generator 260 is shown at feed processor server 140, in other embodiments it may instead be at client device 120. The UI generator 260 may present various levels of detail for the data present in the inbound list 220 and the outbound list 225. In one embodiment, the UI generator 260 presents a top level view showing the highest ranking values from the inbound list 220 and the outbound list 225. In other embodiments, the UI generator 260 may present additional data, such as a list of all entries present in the inbound list 220 and the outbound list 225. When presenting information from the list, the UI generator 260 may convert the integer conversion values in the list back to the original values (or approximations of the original values) using the corresponding exponent values. Thus, the user sees the original value (or an approximation thereof) rather than an integer value. Using the information presented in the user interface, the user may be able to perform transactions and perform other activities. The UI generator 260 may update the user interface in real-time as new data is updated from the data feed 131 to the inbound list 220 and the outbound list 225. These updates may include additions, deletions, and updates to the list.

Example data structures for inbound and outbound lists

Fig. 3 is a block diagram illustrating an example of an optimized computer data structure in which data feed entries from remote data feeds are stored, according to an embodiment. As shown, the optimized computer data structure is a Binary Search Tree (BST) 305. BST is a data structure that stores data entries and holds the key of each data entry in sorted order for lookup, insertion, and deletion of each entry in the BST takes on average a time proportional to the logarithm of the BST size (e.g., o (log n)). In the case of storing a data feed 131 that includes the inbound list 220 and the local version 141 of the outbound list 225, two BSTs may be used, one for each list. As described above, the entries in each list include integer-translated values, which are stored as nodes in the BST. The nodes in the BST may be keyed according to the integer conversion value of each corresponding entry. Each node may be linked to a left sub-tree and a right sub-tree, where nodes in one sub-tree have lower levels of integer-converted values than nodes' integer-converted values, and nodes in the other sub-tree have higher levels of integer-converted values. Nodes or entries may be added or removed recursively. A node or entry may be looked up or updated by comparing each node to the value to be looked up.

In one embodiment, instead of including each entry in one of the lists 220 or 225 in each node, each node of the BST 305 includes an object, such as object 310, that indicates an integer conversion value 311, optionally a total unit count 312 and a transaction array 313. Transaction array 313 stores a list of transaction entries, such as transaction entry 315 (generally referred to as transaction entry 315 or transaction entries 315). Each transaction entry 315 corresponds to an entry received from data feed 131. Each transaction entry 315 in transaction array 312 has an integer-converted value, such as integer-converted value 321D, that matches integer-converted value 311 of object 310. Thus, each object 310 includes all entries from the data feed 131 that have the same matching integer conversion value. Additionally, transaction entries 315 in transaction array 313 may be ordered by entry timestamp 321G of each transaction entry 315, with the entries having the oldest entry timestamp 321G being the highest ordered. Thus, new entries are added to the back of the array, with the oldest entry being the top ranked because of its oldest timestamp, and thus in front of the array.

In any of the above implementations, each transaction entry or node may also be associated with a unique identifier, such as an ID number 321A, which may be an integer value. This may be provided in the data feed 131. A separate hash table may be stored in each of the inbound list 220 and the outbound list 225 that hashes the unique identifier to further improve the lookup of each entry and their deletion and modification, as updates from the data feed 131 may be identified by the same identifier. Thus, if an update from the data feed 131 references an existing entry using a unique identifier, the hash table may be used to quickly locate the entry and modify or delete it.

Further, in one embodiment, the BST 305 described herein may be a Red-Black BST that further balances the nodes in the tree such that the number of nodes in the subtree of each node is approximately equal after the nodes are inserted and deleted.

Each transaction entry 315 may include other values in addition to ID number 321A, integer conversion value 321D, and entry timestamp 321G. These may include type 321B, unit count 321C, index 321E, and trading goals 321F. Type 321B indicates the transaction flow direction and may optionally be included in transaction entry 315. As described previously, the exponent 321E represents an exponent to which the integer conversion value 321D is modified. The unit count 321C indicates the number of units of the base component that the creator of the transaction wishes to trade in exchange for another base component. These components may be any unit of currency, security, or other asset. The optional transaction target 321F identifies the underlying component of the transaction. Thus, for example, if the creator of the transaction wishes to purchase 50 units of the first currency using the second currency, the transaction target 321F will identify both currencies, while the unit count 321C indicates 50 units. The sum of all unit counts 321C in all transaction entries 315 in object 310 may be stored as total unit count 312.

Additional details regarding the process of inserting, deleting, and modifying entries in the BST 305 when updates are received from the data feed 131 will be described with reference to fig. 4.

Example Process for local version updates from remote data feeds

Fig. 4 is a block diagram and flow diagram illustrating an example conversion of data received from a data feed to increase data compression, according to an embodiment.

As previously indicated, the integer conversion engine 220 converts values received from entries of the data feed 131 received from the remote data feed server 120 into integer converted values. An example of this process with exemplary values is shown in fig. 4.

Initially, an entry 410 is received from the remote data feed server 120 as an update to the data feed 131. The transaction 410 may correspond to an entry in the data feed 131. Transaction 410 may indicate an identification symbol 415A, a unit count 415B, and a timestamp 415C. These may be similar to the previously described components of transaction entry 315, i.e., ID number 321A, unit count 321C, and entry timestamp 321G, respectively.

Further, transaction 410 may include transaction type 415D, which indicates the transaction type. The transaction type may indicate whether a transaction entry is to be added, removed/cancelled, modified/fixed, or whether the request indicated in the transaction entry is satisfied (in whole or in part). Depending on the transaction type, the entry 410 received from the remote data feed server 120 may not indicate all of the elements indicated herein.

Entry 410 may also indicate value 415E and, optionally, trading target 416F. As described above, the value 415E is converted into an integer conversion value. Transaction goal 416F is similar to transaction goal 321F described above. In some embodiments, transaction goal 416F is not specified in entry 410, but is indicated by data feed 131 from which entry 410 was received. Herein, the symbols shown in transaction target 416F represent exchanges between currency a and currency B. The value 415E is 285.614 and, as mentioned above, indicates the ratio between two base components, in this example (defined according to the third currency) between two currencies a and B. Here, the value 415E is not only represented in floating point format, which uses more memory (memory) to store than smaller integers, but also 6-bit numbers, so that sufficient storage is required to store values of at least six-bit numbers.

Integer conversion engine 250 receives entry 410 and converts value 415E in entry 415E by calculating 420 the ratio between the unit values indicated by transaction target 416F. In this case, the ratio is the same as the value 415E, and is a ratio between the first currency a and the second currency B. As described above, in other cases, the ratio may represent the exchange rate of the most recently completed transaction. Using this ratio value, equation (1) is used to calculate the exponent, in this case the integer value 2. The integer conversion engine 250 uses the exponent to convert 425 the value 415E to an integer conversion value by multiplying the value 415E by 10^2 or 100. This results in an integer converted value of 28571. The integer conversion engine 250 stores 430 the value in the corresponding locally stored BST.

Example flow

Fig. 5 is a flow diagram illustrating an example process for data compression of data received from a remote data feed, according to an embodiment. In one embodiment, process 500 may be performed by feed processor server 140.

Feed processor server 140 receives 510 transaction entries from a data feed, such as data feed 131. The transaction entry indicates at least the floating point value amount. The data feed indicates a transaction goal. These may be a value 415E and a transaction goal 416F, respectively. A data feed 131 may be received from the remote data feed server 130.

Feed processor server 140 converts 520 the floating-point value amount in the transaction entry to an integer value amount based on a ratio between the two base components indicated by the transaction target. Thus, the transaction target may indicate two base components, such as two different currencies. Therefore, the ratio is calculated based on the two currencies. In one embodiment, the floating point values are converted to integer values of money by generating an exponent based on a ratio, such as in equation (1) above.

The feed processor server 140 stores 530 the integer value amount in a corresponding entry in a locally stored priority queue. This may correspond to a transaction entry in the BST, such as transaction entry 315 in BST 305. If an entry does not already exist, the entry may be created or the existing entry may be modified with a newly updated integer value of money.

Example Block chain architecture

Fig. 6A is a block diagram illustrating a transaction chain broadcasting and recording over a blockchain according to an embodiment. As described above, the basic component for generating the ratio converted into the integer conversion value may be two different cryptocurrencies. A cryptocurrency is a currency with an ledger stored in a decentralized blockchain. Thus, when a user requests to perform a transaction using, for example, feed processor server 140, and the transaction is cryptocurrency based, the resulting performance of the transaction results in a change in ownership of these cryptocurrencies in different amounts. The change in ownership may be recorded in the blockchain ledger. Blockchains record transactions that occur using cryptocurrency in one or more blockchain units stored in the blockchain, but do not require a central authority to verify that the transaction is legitimate. Rather, blockchains are generated via cooperation of multiple nodes or computing systems.

A distributed blockchain network may include a plurality of nodes. Each node is a user or server participating in the blockchain network. In a fully common blockchain, any participant can become a node of the blockchain. These nodes may collectively function as a distributed computing system, functioning as a virtual machine for the blockchain. In some embodiments, a virtual machine or distributed computing system may be referred to simply as a computer. Any user of the public blockchain can broadcast transactions for blockchain nodes to record. Each user's digital wallet is associated with an encryption private key that is used to sign transactions and to prove ownership of the blockchain unit.

Ownership of blockchain units may be tracked through a chain of transactions. In fig. 6A, the transaction chain may include a first transaction 610, a second transaction 620, and a third transaction 630, among others. Each transaction in the chain may have a very similar structure. Although each transaction is linked to the previous transaction in fig. 6A, the transactions need not be recorded on consecutive blocks on the blockchain. For example, the block in which transaction 610 is recorded and the block in which transaction 620 is recorded may be separated by hundreds or even thousands of blocks. The trace back of previous blocks is tracked by the hash value of the previous block recorded by the current block.

Referring to one of the transactions in FIG. 6A, for purposes of illustration, transaction 620 may be referred to as a current transaction. Transaction 610 may be a prior transaction and transaction 630 may be referred to as a subsequent transaction. Each transaction includes transaction data 622, recipient address 624, hash of previous transaction 626, and digital signature 628 of the owner of the current transaction. Transaction data 622 records the substance of current transaction 620. For example, transaction data 622 may specify the transfer of an amount of blockchain units (e.g., electronic coins, blockchain tokens, BCDRs, etc.). In some embodiments, the transaction data 622 may include code instructions for the smart contract.

The recipient address 624 is a version of the public key corresponding to the private key of the recipient's digital wallet. In one embodiment, recipient address 624 is the public key itself. In another embodiment, recipient address 624 is an encoded version of a public key passed through one or more functions, such as some deterministic function. For example, generating the recipient address from the public key 624 may include hashing the public key, adding a check, adding one or more prefixes or suffixes, and encoding the resulting bits. Recipient address 624 may be a unique identifier of the recipient's digital wallet on the blockchain.

The hash of previous transaction 626 is a hash of the entire transaction data of previous transaction 610. Likewise, the hash of the previous transaction 636 is a hash of the entire transaction data of transaction 620. The previous transaction 610 may be performed using a hashing algorithm such as a Secure Hash Algorithm (SHA) or a message digest algorithm (MD). In some embodiments, the owner corresponding to the current transaction 620 may also generate a hash using the owner's public key. The hash of previous transaction 626 provides a traceback of previous transaction 610 and also maintains the data integrity of previous transaction 610.

In generating the current transaction 620, the digital wallet of the current owner of the blockchain unit encrypts the combination of the transaction data 622, the recipient address 624, and the hash of the previous transaction 626 using its private key to generate the digital signature 628 of the owner. To generate current transaction 620, the current owner specifies the recipient by including recipient address 624 in digital signature 628 of current transaction 620. The subsequent owner of the blockchain unit is determined by the receiver address 624. In other words, the subsequent owner who generated digital signature 638 in subsequent block 630 is fixed by recipient address 624 specified by current transaction 620. To verify the validity of the current transaction 620, any node in the blockchain network may track back to the previous transaction 610 (by tracking a hash of the previous transaction 626) and locate the recipient address 614. The recipient address 614 corresponds to the public key of the digital signature 628. Thus, nodes in the blockchain network may use the public key to verify the digital signature 628.

The transfer of ownership of the blockchain unit may be continued by the owner of the blockchain unit. To transfer ownership, the owner may broadcast a transaction that includes the owner's digital signature and a hash of previous transactions. The correct hash values for valid transactions and previous transactions with verifiable digital signatures will be recorded in the new block of the blockchain through the mine mining process.

Fig. 6B is a block diagram illustrating the connection of multiple tiles in a tile chain according to an embodiment. Each block of the block chain may have a similar structure, except for the first block, which may be referred to as a founder block. Blocks 650, 660, and 660 may each include a hash 652 of a previous chain of blocks, a random number 654, and a plurality of transactions (e.g., a first transaction 656, a second transaction 658, etc.). Each transaction may have the structure shown in fig. 6A.

New blocks may be generated by the process of mining. For a common blockchain, any node in the blockchain system may participate in the mining process. The generation of the hash of the previous tile may be performed by a trial and error process. The entire data of the previous tile (or a version of the previous tile, such as a reduced version) may be hashed using a random number as part of the input. A blockchain may require some format in the hash of the previous block in order for the node to identify the new block as valid. For example, in one embodiment, the hash of the previous chunk needs to start with a certain number of zeros in the hash. Other hash criteria for previous blocks may also be used, depending on the implementation of the blockchain.

As an example, in generating the hash 662 of the previous chunk, the nodes participating in the mining process may randomly combine the version of the previous chunk 650 with a random number (i.e., a random value) to generate the hash. Due to the random number, the hash generated is somewhat a random number. The node compares the generated hash to the criteria of the blockchain system to check if the criteria are met (e.g., if the generated hash begins with a certain number of zeros in the hash). If the generated hash does not meet the criteria, the node may attempt to generate another hash in combination with a different random number. This process is repeated by different nodes in the blockchain network until one of the nodes finds a hash that meets the criteria. The random number used to generate a satisfactory hash is the random number 664. The node that first generates a satisfactory hash 662 may also select which transactions to broadcast to the blockchain network to include in block 660. The node may check the validity of the transaction (e.g., whether the transaction can be traced back to a previously recorded transaction and whether the transaction generator's digital signature is valid). The selection may also depend on the number of broadcast transactions to be recorded and the fees that may be specified in the transactions. For example, in some embodiments, each transaction may be associated with a fee (e.g., a mine fee) for recording the transaction. After selecting the transaction and fixing the data of block 660, the nodes in the blockchain network repeat the trial-and-error process to generate the hash 672 of the previous block by trying a different random number.

In some cases, different nodes may select different transactions for inclusion in subsequent tiles, and may compete with each other to find an appropriate random number for the set of transactions having a generated hash that satisfies the criteria. Thus, there may be situations where multiple satisfactory hashes are generated for blocks containing different transactions. This creates a bifurcation in the blockchain. Future blocks may be hashed based on data in any of the bifurcated blocks. However, in practice, to avoid adding a chunk to multiple forks, a node may agree by selecting a fork of a chunk with an earlier timestamp, or use some other criterion to select a master fork from which to hash additional chunks.

The new block may continue to be generated by the excavation process. When a broadcast transaction is recorded in a tile, the transaction of a blockchain unit (e.g., electronic coin, blockchain token, BCDR, etc.) is completed. In some embodiments, a transaction is considered settled when the transaction is multiple validated. When multiple subsequent blocks are generated and linked to the block recording the transaction, the transaction is multiple verified.

In some embodiments, some transactions 656, 658, 666, 668, 676, 678, etc. may include one or more intelligent contracts. The code instructions of the recorded smart contracts may be recorded in blocks and are generally immutable. When the condition is satisfied, a code instruction of the intelligent contract is triggered. The code instructions may cause a computer (e.g., a virtual machine of a blockchain) to perform some action, such as generating a blockchain unit and broadcasting a record generated transaction to a blockchain network for recording.

Computing machine architecture

FIG. 7 is a block diagram illustrating components of an example computing machine capable of reading instructions from a computer-readable medium and executing them in a processor (or controller). The computers described herein may include a single computing machine as shown in fig. 8, a virtual machine, a distributed computing system including multiple computing machine nodes as shown in fig. 7, or any other suitable arrangement of computing devices. The computer described herein may be used by any of the elements described in the previous figures to perform the described functions.

By way of example, fig. 7 shows a diagrammatic representation of a computing machine in the example form of a computer system 700 within which instructions 724 (e.g., software, program code, or machine code) may be executed, which instructions may be stored in a computer-readable medium for use by the machine to perform any one or more of the processes discussed herein. In some embodiments, the computing machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server machine or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment.

The architecture of the computing machine depicted in fig. 7 may correspond to any of the software, hardware, or combination of components shown in the above-described figures. While fig. 7 shows various hardware and software elements, each of the components described in fig. 1 and 2 may include additional or fewer elements.

For example, the computing machine may be a Personal Computer (PC), a tablet computer, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a smartphone, a web appliance, a network router, an internet of things (IoT) device, a switch or bridge, or any machine capable of executing instructions 724 that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute the instructions 724 to perform any one or more of the methodologies discussed herein.

The example computer system 700 includes one or more processors, generally processor 702 (e.g., a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), one or more Application Specific Integrated Circuits (ASICs), one or more Radio Frequency Integrated Circuits (RFICs), or any combinations of these), a main memory 704 and a static memory 706, which are configured to communicate with each other via a bus 707. The computer system 700 may also include a graphics display unit 710 (e.g., a Plasma Display Panel (PDP), a Liquid Crystal Display (LCD), a projector, or a Cathode Ray Tube (CRT)). The computer system 700 may also include an alphanumeric input device 712 (e.g., a keyboard), a cursor control device 714 (e.g., a mouse, a trackball, a joystick, a motion sensor, or other pointing instrument), a storage unit 716, a signal generation device 718 (e.g., a speaker), and a network interface device 720, which are also configured to communicate via the bus 708.

The storage unit 716 includes a computer-readable medium 722 on which are stored instructions 724 embodying any one or more of the methodologies or functions described herein. The instructions 724 may also reside, completely or at least partially, within the main memory 704 or within the processor 702 (e.g., within a processor's cache memory) during execution thereof by the computer system 700, the main memory 704 and the processor 702 also constituting computer-readable media. The instructions 724 may be transmitted or received over a network 726 via the network interface device 720.

While the computer-readable medium 722 is shown in an example embodiment to be a single medium, the term "computer-readable medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) that are capable of storing the instructions (e.g., the instructions 724). A computer-readable medium may include any medium that can store instructions (e.g., instructions 724) for execution by a machine and that cause the machine to perform any one or more of the methodologies disclosed herein. The computer readable medium may include, but is not limited to, a data repository in the form of solid state memory, optical media, and magnetic media. Computer-readable media does not include transitory media such as signals or carrier waves.

Other configuration considerations

Certain embodiments are described herein as comprising logic or a plurality of components, engines, modules, or mechanisms, e.g., as shown in fig. 2. The engine may constitute a software module (e.g., code embodied on a computer-readable medium) or a hardware module. A hardware engine is a tangible unit that is capable of performing certain operations and may be configured or arranged in a certain manner. In an example embodiment, one or more computer systems (e.g., a stand-alone client or server computer system) or one or more hardware engines (e.g., a processor or a set of processors) of a computer system may be configured by software (e.g., an application or application portion) as a hardware engine for performing certain operations described herein.

In various embodiments, the hardware engine may be implemented mechanically or electronically. For example, a hardware engine may comprise permanently configured special-purpose circuitry or logic (e.g., as a special-purpose processor, such as a Field Programmable Gate Array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. The hardware engine may also include programmable logic or circuitry (e.g., included within a general-purpose processor or another programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware engine mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

Various operations of the example methods described herein may be performed, at least in part, by one or more processors (e.g., processor 702) that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily configured or permanently configured, such processors may constitute processor-implemented engines that operate to perform one or more operations or functions. In some example embodiments, the engine referred to herein may comprise a processor-implemented engine.

The execution of certain operations may be distributed among one or more processors, and not only reside within a single machine, but are also deployed across multiple machines. In some example embodiments, one or more processors or processor-implemented modules may be located in a single geographic location (e.g., within a home environment, office environment, or server farm). In other example embodiments, one or more processors or processor-implemented modules may be distributed across multiple geographic locations.

Upon reading this disclosure, those skilled in the art will appreciate further alternative structural and functional designs for similar systems or processes through the principles disclosed herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes, and variations apparent to those skilled in the art may be made in the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the above-described embodiments without departing from the broad general scope of the invention. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.