Legal claims defining the scope of protection. Each claim is shown in both the original legal language and a plain English translation.
1. A method comprising: receiving, by a first server operating in a server cluster, from a client, a read request message, wherein the first server is not recognized as a leader in the server cluster; receiving, by a first P4 switch in communication with the first server, from the client, the read request message; forwarding, by the first P4 switch, the read request message to a second server that is recognized as the leader in the server cluster, wherein the second server comprises a back-end comprising a complete Raft algorithm, and wherein the back-end executes the complete Raft algorithm to perform leader election, log replication, and log commitment of a Raft consensus algorithm; and receiving, by a second P4 switch in communication with the second server, the read request message immediately without involving the second server, wherein the second P4 switch comprises a front-end comprising a partial Raft algorithm.
This invention relates to distributed systems using the Raft consensus algorithm for leader election, log replication, and log commitment. The problem addressed is improving efficiency in handling read requests in a server cluster where only the leader server processes write requests, while read requests can be handled by any server. The solution involves a system where a first server, not recognized as the leader, receives a read request from a client. A first P4 switch, in communication with the first server, forwards the read request to a second server recognized as the leader. The second server includes a back-end with a complete Raft algorithm implementation for leader election, log replication, and log commitment. Meanwhile, a second P4 switch, in communication with the second server, receives the read request directly without involving the second server. This second P4 switch includes a front-end with a partial Raft algorithm, allowing it to handle read requests efficiently without burdening the leader server. The partial Raft algorithm in the P4 switch enables fast read operations while maintaining consistency with the leader's state. This approach optimizes read performance in distributed systems by offloading read requests to specialized network switches while ensuring data consistency through the Raft consensus algorithm.
2. The method of claim 1 , wherein the front-end executes the partial Raft algorithm to perform the log replication and the log commitment of the Raft consensus algorithm.
This invention relates to distributed systems and consensus algorithms, specifically improving the efficiency of the Raft consensus protocol. The Raft algorithm is widely used for managing replicated state machines in distributed systems, ensuring consistency and fault tolerance. However, traditional Raft implementations can introduce latency and overhead due to full consensus participation across all nodes. This invention addresses these issues by optimizing log replication and commitment processes. The method involves a distributed system with multiple nodes, including a leader node and follower nodes. The leader node is responsible for managing log replication and commitment, while follower nodes participate in the consensus process. The key innovation is the use of a partial Raft algorithm executed by a front-end component. This partial algorithm handles log replication and commitment, reducing the need for full consensus participation across all nodes. By offloading these tasks to the front-end, the system achieves faster log replication and commitment while maintaining consistency and fault tolerance. The front-end component interacts with the leader node to replicate logs and commit them to the distributed system. The partial Raft algorithm ensures that log entries are replicated to a quorum of nodes before commitment, adhering to Raft's consistency guarantees. This approach minimizes latency and reduces the computational overhead on the leader node, improving overall system performance. The invention is particularly useful in high-throughput distributed systems where low-latency consensus is critical.
3. The method of claim 2 , wherein the back-end maintains a complete state on the second server for responding to requests that cannot be fulfilled by the front-end.
This invention relates to distributed computing systems where a front-end server handles user requests while a back-end server maintains a complete system state to handle requests that the front-end cannot fulfill. The front-end server processes requests independently but delegates complex or state-dependent operations to the back-end. The back-end maintains a full state representation, allowing it to respond to requests that require access to historical data, complex computations, or other operations beyond the front-end's capabilities. This architecture improves scalability and performance by offloading simple requests to the front-end while ensuring the back-end can handle more demanding tasks. The system is particularly useful in applications where real-time processing is required, and the front-end cannot maintain a complete state due to resource constraints or performance limitations. The back-end's state management ensures consistency and reliability, even when the front-end cannot fulfill a request. This approach optimizes resource usage by distributing workloads efficiently between the front-end and back-end servers.
4. The method of claim 3 , wherein the first server comprises a further back-end comprising the complete Raft algorithm.
A distributed consensus system ensures reliable coordination among multiple servers in a network, addressing challenges like node failures and network partitions. The system uses a consensus protocol to maintain consistency across servers, with a primary server managing client requests and replicating them to secondary servers. However, existing systems may struggle with scalability and fault tolerance, particularly when handling high volumes of requests or recovering from failures. This invention improves upon prior systems by implementing a hierarchical architecture. A first server, acting as a primary node, includes a back-end system that fully implements the Raft consensus algorithm. Raft is a leader-based protocol that ensures strong consistency by electing a leader node to coordinate log replication. The first server's back-end handles all consensus-related operations, including leader election, log replication, and membership changes, while delegating other tasks to front-end components. This separation enhances performance by offloading non-consensus workloads, allowing the back-end to focus on maintaining consistency. The system also supports dynamic scaling by adding or removing servers without disrupting ongoing operations. The hierarchical design improves fault tolerance by isolating failures to specific components, reducing the risk of system-wide outages. This approach is particularly useful in large-scale distributed systems requiring high availability and strong consistency guarantees.
5. The method of claim 4 , wherein the first P4 switch comprises a further front-end comprising the partial Raft algorithm.
A method for implementing a distributed network switch using a partial Raft consensus algorithm to manage configuration state across multiple switches. The method addresses the challenge of maintaining consistent configuration states in a distributed network environment where switches must coordinate updates without relying on a centralized controller. The partial Raft algorithm is integrated into a front-end component of a first P4 switch, enabling it to participate in consensus-based decision-making for configuration changes. This ensures that all switches in the network agree on the same configuration state, improving reliability and reducing the risk of misconfigurations. The partial Raft algorithm handles leader election, log replication, and membership changes, but may omit certain features of the full Raft protocol to optimize performance for network switching applications. The method allows switches to dynamically join or leave the network while maintaining consistency, and it supports fault tolerance by electing new leaders if the current leader fails. The approach is particularly useful in data center networks, software-defined networking (SDN) environments, and other distributed systems requiring high availability and consistent configuration management.
6. A method comprising: receiving, by a first server operating in a server cluster, from a client, a write request message, wherein the first server is recognized as a leader in the server cluster; receiving, by a first P4 switch in communication with the first server, from the client, the write request message; handling, by the first P4 switch, the write request message; and notifying, by the first P4 switch, without involving the first server, a second server and a third server of the server cluster of write request results resulting from the first P4 switch handling the write request message.
This invention relates to distributed systems and data consistency in server clusters. The problem addressed is ensuring efficient and consistent handling of write requests across multiple servers in a cluster without relying solely on the leader server, which can create bottlenecks and reduce performance. The method involves a server cluster with at least three servers, where one server is designated as the leader. A client sends a write request message to the leader server, which receives and processes the request. Simultaneously, a P4 switch in communication with the leader server also receives the same write request message from the client. The P4 switch independently handles the write request, performing necessary operations such as data validation, routing, or replication. After processing, the P4 switch directly notifies the other servers in the cluster (e.g., a second and third server) of the write request results without involving the leader server. This bypasses the leader, reducing latency and improving efficiency while maintaining data consistency across the cluster. The P4 switch's role in handling and distributing write request results ensures that all servers are updated in a decentralized manner, enhancing system performance and reliability.
7. The method of claim 6 , wherein the first server comprises a back-end comprising a complete Raft algorithm.
A distributed consensus system ensures reliable coordination among multiple servers in a network, addressing challenges like data consistency and fault tolerance. The system includes a first server and at least one second server, where the first server acts as a leader node responsible for managing consensus operations. The second servers operate as follower nodes, receiving and executing commands from the leader. The leader node maintains a complete implementation of the Raft consensus algorithm, which includes leader election, log replication, and membership changes. This ensures that all servers agree on the state of the system even if some nodes fail or network partitions occur. The leader node replicates its log entries to the follower nodes, and followers acknowledge receipt to confirm consistency. If the leader fails, the system automatically elects a new leader from the followers to maintain operation. The Raft algorithm's completeness in the leader node guarantees that the system can handle leader transitions, network partitions, and node failures without data loss or inconsistency. This approach improves reliability and fault tolerance in distributed systems where consistent state management is critical.
8. The method of claim 7 , wherein the back-end executes the complete Raft algorithm to perform leader election, log replication, and log commitment of a Raft consensus algorithm.
A distributed consensus system implements the Raft algorithm to ensure fault-tolerant leader election, log replication, and log commitment in a distributed computing environment. The system includes a back-end component that fully executes the Raft consensus protocol, which involves selecting a leader node from multiple candidate nodes, replicating log entries across all nodes, and committing log entries to persistent storage once a majority of nodes acknowledge receipt. The leader node handles client requests, replicates them to follower nodes, and ensures consistency across the distributed system. If the leader fails, the system automatically triggers a new leader election process to maintain availability. The back-end also manages log replication by ensuring that log entries are propagated to all follower nodes and committed only after a quorum of nodes confirms their receipt. This approach guarantees strong consistency and fault tolerance, even in the presence of node failures or network partitions. The system is designed for use in distributed databases, configuration management systems, and other applications requiring reliable consensus mechanisms.
9. The method of claim 8 , wherein the first P4 switch comprises a front-end comprising a partial Raft algorithm.
A system and method for network packet processing involves a programmable switch architecture using the P4 language to implement network functions. The system addresses the challenge of efficiently managing distributed network configurations by integrating a consensus algorithm, specifically a partial Raft algorithm, into the switch's front-end. The partial Raft algorithm enables the switch to participate in distributed consensus processes, ensuring consistent configuration across multiple switches while minimizing computational overhead. The front-end processes incoming packets, applies network policies, and coordinates with other switches to maintain synchronization. The system supports dynamic updates to network policies without disrupting ongoing traffic, improving scalability and reliability in large-scale network deployments. The partial Raft implementation optimizes performance by reducing the frequency of full consensus rounds, focusing only on critical configuration changes. This approach enhances fault tolerance and simplifies network management in environments requiring high availability and low-latency packet processing.
10. The method of claim 9 , wherein the front-end executes the partial Raft algorithm to perform the log replication and the log commitment of the Raft consensus algorithm.
A distributed consensus system ensures reliable coordination among multiple nodes in a network, addressing challenges like node failures and network partitions. The system implements a partial Raft algorithm to optimize log replication and commitment processes. The front-end component handles log replication by distributing log entries to follower nodes, ensuring consistency across the cluster. It also manages log commitment, confirming that replicated logs are durable and applied in the correct order. The partial Raft algorithm reduces computational overhead by selectively executing specific Raft consensus steps, such as leader election and log synchronization, while maintaining fault tolerance and data integrity. This approach improves efficiency in distributed systems where full Raft consensus may be unnecessary for certain operations. The system supports dynamic node membership, allowing nodes to join or leave the cluster without disrupting ongoing consensus processes. By leveraging partial Raft execution, the system balances performance and reliability, making it suitable for applications requiring high availability and consistency.
11. The method of claim 10 , wherein the second server is in communication with a second P4 switch, and the third server is in communication with a third P4 switch.
This invention relates to a distributed computing system that uses programmable P4 switches to manage network traffic between multiple servers. The system addresses the challenge of efficiently routing data in large-scale networks where servers and switches must dynamically adapt to changing traffic patterns and workloads. The invention involves a method for coordinating communication between servers and P4 switches, which are programmable network devices capable of processing packets based on custom-defined rules. In the system, a first server communicates with a first P4 switch, while a second server is connected to a second P4 switch, and a third server is connected to a third P4 switch. The P4 switches are configured to enforce traffic policies, perform packet processing, and route data between the servers. The method ensures that the switches can dynamically update their forwarding rules to optimize network performance, reduce latency, and handle varying traffic loads. The system may also include mechanisms for load balancing, failover, and traffic prioritization, ensuring reliable and efficient data transmission across the network. The use of P4 switches allows for flexible and programmable network behavior, enabling the system to adapt to different network conditions and application requirements.
12. A system comprising: a plurality of servers operating in a server cluster, wherein each server of the plurality of servers comprises a back-end that executes a complete Raft algorithm to perform leader election, log replication, and log commitment of a Raft consensus algorithm; and a plurality of P4 switches corresponding to the plurality of servers, wherein each P4 switch of the plurality of P4 switches comprises a front-end that executes a partial Raft algorithm to perform the log replication and the log commitment of the Raft consensus algorithm.
The system involves a distributed computing architecture designed to enhance the efficiency and reliability of consensus algorithms in server clusters. The problem addressed is the computational overhead and latency associated with traditional consensus algorithms, particularly the Raft algorithm, which is widely used for leader election, log replication, and log commitment in distributed systems. The system divides the Raft algorithm's responsibilities between servers and programmable network switches to optimize performance. The system includes a cluster of servers, each equipped with a back-end component that fully executes the Raft algorithm. This component handles leader election, log replication, and log commitment, ensuring consistency and fault tolerance across the cluster. Additionally, the system incorporates a set of P4 programmable switches, each associated with a server. These switches include a front-end component that executes a partial Raft algorithm, specifically focusing on log replication and log commitment. By offloading these tasks to the network switches, the system reduces the computational burden on the servers, improving overall system efficiency and reducing latency. The integration of P4 switches allows for dynamic and programmable network behavior, enabling the front-end components to assist in maintaining consensus without requiring full Raft algorithm execution. This hybrid approach leverages the strengths of both servers and network infrastructure to achieve a more scalable and responsive consensus mechanism. The system is particularly useful in environments where low-latency and high-throughput consensus operations are critical, such as distributed databases, cloud computing, and real-time data processing systems.
13. The system of claim 12 , wherein the back-end maintains a complete state for responding to requests that cannot be fulfilled by the front-end.
A distributed computing system is designed to handle requests efficiently by dividing processing between a front-end and a back-end. The front-end processes requests that can be resolved locally, reducing latency and load on the back-end. However, some requests require additional data or processing that the front-end cannot fulfill. To address this, the back-end maintains a complete state of the system, including all necessary data and logic, to handle such requests. This ensures that any request not resolvable by the front-end is seamlessly transferred to the back-end, which can fully process and respond to it. The back-end's complete state allows it to manage dependencies, data consistency, and complex operations that the front-end cannot perform independently. This architecture improves scalability and reliability by offloading simple requests to the front-end while ensuring the back-end can handle more complex or incomplete requests without failure. The system optimizes performance by minimizing unnecessary communication between the front-end and back-end while maintaining the ability to escalate requests when needed. This approach is particularly useful in distributed systems where latency and resource efficiency are critical.
14. The system of claim 13 , wherein the requests comprise a read request.
A system for managing data access in a distributed computing environment addresses the challenge of efficiently handling read operations in large-scale systems where data is distributed across multiple nodes. The system includes a request processing module that receives and processes data access requests, including read requests, from client devices. These requests are routed to the appropriate data storage locations based on a distributed data management protocol. The system ensures data consistency and availability by coordinating read operations across multiple nodes, reducing latency and improving performance. The request processing module may also prioritize or optimize read requests based on factors such as data locality, network conditions, or system load. Additionally, the system may implement caching mechanisms to further enhance read operation efficiency. By dynamically adjusting read request handling based on real-time system conditions, the system ensures reliable and high-performance data access in distributed environments.
15. The system of claim 14 , wherein the requests comprise a write request.
A system for managing data storage operations in a distributed computing environment addresses the challenge of efficiently handling write requests across multiple storage nodes. The system includes a distributed storage architecture where data is partitioned and stored across multiple nodes to improve scalability and fault tolerance. The system processes write requests by distributing the data to be written across the storage nodes based on a partitioning scheme, ensuring that the data is stored redundantly to prevent data loss in case of node failures. The system also includes mechanisms for tracking the status of write operations, such as acknowledging successful writes and retrying failed writes. The write requests may include metadata specifying the data to be written, the target storage location, and any consistency requirements. The system ensures that write operations are performed in a manner that maintains data consistency across the distributed storage nodes, even in the presence of concurrent write requests. The system may also include features for optimizing write performance, such as batching multiple write requests or prioritizing certain types of writes. The overall goal is to provide a reliable and efficient way to handle write operations in a distributed storage environment.
16. The system of claim 15 , wherein a first request of the requests can be fulfilled by the front-end.
A system for managing and processing requests in a distributed computing environment addresses the challenge of efficiently handling diverse requests with varying processing requirements. The system includes a front-end component and a back-end component, where the front-end is responsible for initial request processing and routing, while the back-end handles more complex or resource-intensive tasks. The front-end is configured to determine whether a request can be fulfilled locally or if it requires back-end intervention. This system optimizes resource utilization by minimizing unnecessary back-end processing for requests that can be resolved at the front-end, thereby improving overall system performance and reducing latency. The front-end may include logic to prioritize, filter, or preprocess requests before forwarding them to the back-end, ensuring that only necessary computations are offloaded. The back-end is designed to handle tasks that exceed the front-end's capabilities, such as heavy computations, data retrieval from external sources, or specialized processing. The system dynamically adjusts request routing based on current load, availability, and performance metrics to maintain efficiency. This architecture enhances scalability and reliability by distributing workloads appropriately between the front-end and back-end components.
17. The system of claim 16 , wherein a second request of the requests cannot be fulfilled by the front-end.
A system is described for managing requests in a distributed computing environment, particularly where a front-end component cannot fulfill certain requests. The system includes a front-end component that processes incoming requests and determines whether they can be fulfilled locally. If a request cannot be fulfilled by the front-end, it is routed to a back-end component for further processing. The back-end component may include additional resources, such as databases, servers, or specialized processing units, to handle requests that exceed the front-end's capabilities. The system ensures that requests are efficiently distributed between the front-end and back-end components, optimizing resource utilization and performance. The invention addresses the problem of front-end limitations in handling complex or resource-intensive requests by offloading such requests to a more capable back-end system. This approach improves scalability and reliability in distributed computing environments.
Unknown
November 24, 2020
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.