Remote procedure call | EPFL Graph Search

In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space (commonly on another computer on a shared network), which is written as if it were a normal (local) procedure call, without the programmer explicitly writing the details for the remote interaction. That is, the programmer writes essentially the same code whether the subroutine is local to the executing program, or remote. This is a form of client–server interaction (caller is client, executor is server), typically implemented via a request–response message-passing system. In the object-oriented programming paradigm, RPCs are represented by remote method invocation (RMI). The RPC model implies a level of location transparency, namely that calling procedures are largely the same whether they are local or remote, but usually, they are not identical, so local calls can be distinguished from remote calls. Remote calls are usually orders

The LEAF Platform: Incremental Enhancements for the J2EE

Christian Gasser, Rachid Guerraoui

LEAF, the Lean and Extensible Architectural Framework, is an enhancement wrapper for J2EE implementations. Basically, LEAF fixes some identified J2EE issues and extends, as well as simplifies, the use of the J2EE by providing several incremental improvements. These improvements are seamlessly integrated, include an additional component type, allow the same interfaces for local and remote service implementations, offer better J2EE implementation compatibility and ORB interceptors, and encompass several new technical services. This paper explains the need for LEAF through a diagnosis of the J2EE, presents the fundamental concepts underlying LEAF, overviews its implementation, reports on field experiences from using it in a number of commercial projects, and points out some interesting tradeoffs in using the J2EE with and without LEAF.

2002

Hardware and Software Support for RPC-Centric Server Architecture

Mark Johnathon Sutherland

Online services have become ubiquitous in technological society, the global demand for which has driven enterprises to construct gigantic datacenters that run their software. Such facilities have also recently become a substrate for third-party organizations due to the advantages of moving infrastructure to the cloud. The task of developing, releasing, and maintaining software at datacenter scale has given rise to a software architecture employing many independent microservices, each accomplishing a single role and communicating using an enforced API, the most common of which is Remote Procedure Calls (RPCs). As microservices have become standard practice for datacenter-scale software, the datacenter's underlying components must support them efficiently. The increasing adoption of microservice architectures implies a drastic growth in network communication, because each microservice receives and creates many RPCs that often execute for only a few microseconds (us). Therefore, delivering users an interactive, low latency service becomes more challenging, because each request involves more interactions with the components implementing the communication stack. It is particularly difficult to ensure the latency of the slowest responses, called the "tail latency", is acceptable to the service's users. Datacenter system design is therefore undergoing a rapid shift to enable programmers to reap the benefits of microservices without their performance quandaries. Handling RPCs from us-scale software at the line rates of today's NICs -- delivering up to 400Gbps -- is an open challenge, which will require designing all layers of the communication stack to natively offer support for RPC semantics. Although the performance of the network and protocol layers has drastically improved by prioritizing RPCs as a primary design objective, server hardware has not yet done so. Therefore, we posit that now is the time for an RPC centric server architecture to emerge to allow server endpoints to match the performance of their surrounding system components.To that end, this thesis introduces hardware and software support for RPC-centric server architecture. We first make the case that today's hardware-terminated network transport protocols grossly over-provision buffering because they are agnostic to the latency constraints inherent in each RPC, and simply exposing such RPC-level information to hardware allows 1.25-2.2x better performance. Motivated by prior work demonstrating the RPC stack's burdensome cost, we then show how a previously proposed RPC stack accelerator can be integrated with the implementation of our aforementioned NIC protocol. Finally, we propose new NIC driven load balancing policies that boost microservice throughput via improved locality, while simultaneously maintaining tail latency guarantees. Our proposals improve 99th% tail latency in data stores by 2-5.5x, and reduce instruction cache misses in stateless microservices by 1.1x-1.8x. In summary, we present evidence that designing and implementing a server's NIC hardware to natively support RPC semantics removes protocol scalability bottlenecks and enables microservices to enjoy further performance benefits.

EPFL2022

Operating System and Network Co-Design for Latency-Critical Datacenter Applications

Evangelos Marios Kogias

Datacenters are the heart of our digital lives. Online applications, such as social-networking and e-commerce, run inside datacenters under strict Service Level Objectives for their tail latency. Tight latency SLOs are necessary for such services to remain interactive and keep users engaged. At the same time, datacenters operate under a single administrative domain which enables the deployment of customized network and hardware solutions based on specific application requirements. Customization enables the design of datacenter-tailored and SLO-aware mechanisms that are more efficient and have better performance. In this thesis we focus on three main datacenter challenges. First, latency-critical, in-memory datacenter applications have ÎŒs-scale services times and run on top of hardware infrastructure which is also capable of ÎŒs-scale inter-node round-trip times. Existing operating systems, though, were designed under completely different assumptions and are not ready for ÎŒs-scale computing. Second, the base of datacenter communications is Remote Procedure Calls (RPCs) that depend on a message-oriented paradigm, while TCP still remains widely-used for intra datacenter communications. The mismatch between TCPâs bytestream-oriented abstraction and RPCs causes several inefficiencies and deteriorates tail latency. Finally, datacenter applications follow a scale-out paradigm based on large fan-out communication schemes. In such a scenario, tail latency becomes a critical metric due to the tail at scale problem. The two main factors that affect tail latency is interference and scheduling/load balancing decisions. To deal with the above challenges we advocate for a co-design of network and operating system mechanisms targeting ÎŒs-scale tail optimisations for latency-critical datacenter applications. Our approach investigates the potential of pushing functionality to the network leveraging emerging in-network programmability features. Whenever existing abstractions fail to meet the ÎŒs-scale requirements or restrict our design space, we propose new ones given the design and deployment freedom the datacenter offers. This thesis contributions can be split in three main parts. We, first, design and build tools and methodologies for ÎŒs-scale latency measurements and system evaluation. Our approach depends on a robust theoretical background in statistics and queueing theory. We, then, revisit existing operating system and networking mechanisms for TCP-based datacenter applications. We design an OS scheduler for ÎŒs-scale tasks, while we modify TCP to improve L4 load balancing, and provide an SLO-aware flow control mechanism. Finally, after identifying the problems related to TCP-based RPC services, we introduce a new transport protocol for datacenter RPCs and in-network policy enforcement that enables us to push functionality to the network. We showcase how the new protocol improves the performance and simplifies the implementation of in-network RPC load balancing, SLO-aware RPC flow control, and application-agnostic fault-tolerant RPCs.

EPFL2020