Prerequisites
This tutorial builds on the LLCPP getting started tutorials.
Overview
A common aspect of using FIDL on Fuchsia is passing protocol endpoints across protocols. Many FIDL messages include either the client end or the server end of a channel, where the channel is used to communicate over a different FIDL protocol. In this case, the client end allows making requests to the specified protocol, whereas the server end must implement the specified protocol. An alternate set of terms for client end and server end are protocol and protocol request.
This tutorial covers:
- The usage of these client and server ends, both in FIDL and in the LLCPP FIDL bindings.
- The request pipelining pattern and its benefits.
The full example code for this tutorial is located at //examples/fidl/llcpp/request_pipelining.
The FIDL protocol
This tutorial implements the EchoLauncher protocol from the
fuchsia.examples library:
[Discoverable]
protocol EchoLauncher {
GetEcho(string:MAX_STRING_LENGTH echo_prefix) -> (Echo response);
GetEchoPipelined(string:MAX_STRING_LENGTH echo_prefix, request<Echo> request);
};
This is a protocol that lets clients retrieve an instance of the Echo
protocol. Clients can specify a prefix, and the resulting Echo instance
adds that prefix to every response.
There are two methods that can be used to accomplish this:
GetEcho: Takes the prefix as a request, and responds with the client end of a channel connected to an implementation of theEchoprotocol. After receiving the client end in the response, the client can start making requests on theEchoprotocol using the client end.GetEchoPipelined: Takes the server end of a channel as one of the request parameters and binds an implementation ofEchoto it. The client that made the request is assumed to already hold the client end, and will start makingEchorequests on that channel after callingGetEchoPipeliend.
As the name suggests, the latter uses a pattern called protocol request pipelining, and is the preferred approach. This tutorial implements both approaches.
Implement the server
Implement the Echo protocol
This implementation of Echo allows specifying a prefix in order to
distinguish between the different instances of Echo servers:
// Implementation of the Echo protocol that prepends a prefix to every response.
class EchoImpl final : public llcpp::fuchsia::examples::Echo::Interface {
public:
explicit EchoImpl(std::string prefix) : prefix_(prefix) {}
// This method is not used in the request pipelining example, so requests are ignored.
void SendString(fidl::StringView value, SendStringCompleter::Sync& completer) override {}
void EchoString(fidl::StringView value, EchoStringCompleter::Sync& completer) override {
std::cout << "Got echo request for prefix " << prefix_ << std::endl;
auto value_str = std::string(value.data(), value.size());
auto response = prefix_ + value_str;
completer.Reply(fidl::unowned_str(response));
}
const std::string prefix_;
};
The SendString handler is empty as the client just uses EchoString.
Implement the EchoLauncher protocol
This class responds to either method by launching an instance of an Echo server, and then stores
the EchoImpl instance in a member variable to ensure that its lifetime matches that of the
launcher. The code for running an Echo server given a specific prefix and channel is abstracted
into a helper RunEchoServer method:
// Implementation of EchoLauncher. Each method creates an instance of EchoImpl
// with the specified prefix.
class EchoLauncherImpl final : public llcpp::fuchsia::examples::EchoLauncher::Interface {
public:
explicit EchoLauncherImpl(async_dispatcher_t* dispatcher) : dispatcher_(dispatcher) {}
void GetEcho(fidl::StringView prefix, GetEchoCompleter::Sync& completer) override {
std::cout << "Got non pipelined request" << std::endl;
zx::channel server_end, client_end;
ZX_ASSERT(zx::channel::create(0, &client_end, &server_end) == ZX_OK);
RunEchoServer(std::move(prefix), std::move(server_end));
completer.Reply(std::move(client_end));
}
void GetEchoPipelined(fidl::StringView prefix, zx::channel server_end,
GetEchoPipelinedCompleter::Sync& completer) override {
std::cout << "Got pipelined request" << std::endl;
RunEchoServer(std::move(prefix), std::move(server_end));
}
void RunEchoServer(fidl::StringView prefix, zx::channel server_end) {
// The binding stays alive as long as the EchoImpl class that is bound is kept in
// scope, so store them in the class.
server_instances_.push_back(
std::make_unique<EchoImpl>(std::string(prefix.data(), prefix.size())));
fidl::BindServer(dispatcher_, std::move(server_end), server_instances_.back().get());
}
// Keep track of all running EchoImpl instances so that they share the same lifetime
// as this class.
std::vector<std::unique_ptr<EchoImpl>> server_instances_;
async_dispatcher_t* dispatcher_;
};
For GetEcho, the code first needs to instantiate both ends of the
channel. It then launches an Echo instance using the server end, and then sends a response
back with the client end. For GetEchoPipelined, the client has already done
the work of creating both ends of the channel. It keeps one end and has passed
the other to the server, so all the code needs to do is call RunEchoServer.
Serve the EchoLauncher protocol
The main loop should is the same as in the
server tutorial but serves an EchoLauncher instead of Echo.
int main(int argc, char** argv) {
zx_handle_t directory_request = zx_take_startup_handle(PA_DIRECTORY_REQUEST);
if (directory_request == ZX_HANDLE_INVALID) {
std::cerr << "error: directory_request was ZX_HANDLE_INVALID" << std::endl;
return -1;
}
async::Loop loop(&kAsyncLoopConfigAttachToCurrentThread);
async_dispatcher_t* dispatcher = loop.dispatcher();
svc_dir_t* dir = nullptr;
zx_status_t status = svc_dir_create(dispatcher, directory_request, &dir);
if (status != ZX_OK) {
std::cerr << "error: svc_dir_create returned: " << status << " ("
<< zx_status_get_string(status) << ")" << std::endl;
return status;
}
ConnectRequestContext context = {.dispatcher = dispatcher,
.server = std::make_unique<EchoLauncherImpl>(dispatcher)};
status = svc_dir_add_service(dir, "svc", "fuchsia.examples.EchoLauncher", &context, connect);
if (status != ZX_OK) {
std::cerr << "error: svc_dir_add_service returned: " << status << " ("
<< zx_status_get_string(status) << ")" << std::endl;
return status;
}
std::cout << "Running echo launcher server" << std::endl;
loop.Run();
return 0;
}
Build the server
Optionally, to check that things are correct, try building the server:
Configure your GN build to include the server:
fx set core.x64 --with //examples/fidl/llcpp/request_pipelining/serverBuild the Fuchsia image:
fx build
Implement the client
After connecting to the EchoLauncher server, the client
code connects to one instance of Echo using GetEcho and another using
GetEchoPipelined and then makes an EchoString request on each instance.
This is the non-pipelined code:
int main(int argc, const char** argv) {
async::Loop loop(&kAsyncLoopConfigAttachToCurrentThread);
async_dispatcher_t* dispatcher = loop.dispatcher();
int num_responses = 0;
auto svc = get_svc_directory();
// Connect to the EchoLauncher protocol
zx::channel server_end, client_end;
ZX_ASSERT(zx::channel::create(0, &client_end, &server_end) == ZX_OK);
ZX_ASSERT(fdio_service_connect_at(svc.get(), "fuchsia.examples.EchoLauncher",
server_end.release()) == ZX_OK);
fidl::Client<llcpp::fuchsia::examples::EchoLauncher> launcher(std::move(client_end), dispatcher);
fidl::Client<llcpp::fuchsia::examples::Echo> echo;
// Make a non-pipelined request to get an instance of Echo
auto result = launcher->GetEcho(
"non pipelined: ", [&](llcpp::fuchsia::examples::EchoLauncher::GetEchoResponse* response) {
// Take the channel to Echo in the response, bind it to the dispatcher, and
// make an EchoString request on it.
echo.Bind(std::move(response->response), dispatcher);
echo->EchoString("hello!",
[&](llcpp::fuchsia::examples::Echo::EchoStringResponse* response) {
std::string reply(response->response.data(), response->response.size());
std::cout << "Got echo response " << reply << std::endl;
if (++num_responses == 2) {
loop.Quit();
}
});
});
ZX_ASSERT(result.ok());
zx::channel se, ce;
ZX_ASSERT(zx::channel::create(0, &ce, &se) == ZX_OK);
// Make a pipelined request to get an instance of Echo
ZX_ASSERT(launcher->GetEchoPipelined("pipelined: ", std::move(se)).ok());
// A client can be initialized using the client end without waiting for a response
fidl::Client<llcpp::fuchsia::examples::Echo> echo_pipelined(std::move(ce), dispatcher);
echo_pipelined->EchoString(
"hello!", [&](llcpp::fuchsia::examples::Echo::EchoStringResponse* response) {
std::string reply(response->response.data(), response->response.size());
std::cout << "Got echo response " << reply << std::endl;
if (++num_responses == 2) {
loop.Quit();
}
});
loop.Run();
return num_responses == 2 ? 0 : 1;
}
This code has two layers of callbacks:
- The outer layer handles the launcher request.
- The inner layer handles the
EchoStringrequest.
Also, the code instantiates the fidl::Client<Echo> in the outer scope then Binds it
inside of the callback, so that the client's lifetime matches the lifetime of the
component. This client needs to be in scope when the echo response is received, which
will most likely be after the top level callback returns.
Despite having to initialize the channel first, the pipelined code is much simpler:
int main(int argc, const char** argv) {
async::Loop loop(&kAsyncLoopConfigAttachToCurrentThread);
async_dispatcher_t* dispatcher = loop.dispatcher();
int num_responses = 0;
auto svc = get_svc_directory();
// Connect to the EchoLauncher protocol
zx::channel server_end, client_end;
ZX_ASSERT(zx::channel::create(0, &client_end, &server_end) == ZX_OK);
ZX_ASSERT(fdio_service_connect_at(svc.get(), "fuchsia.examples.EchoLauncher",
server_end.release()) == ZX_OK);
fidl::Client<llcpp::fuchsia::examples::EchoLauncher> launcher(std::move(client_end), dispatcher);
fidl::Client<llcpp::fuchsia::examples::Echo> echo;
// Make a non-pipelined request to get an instance of Echo
auto result = launcher->GetEcho(
"non pipelined: ", [&](llcpp::fuchsia::examples::EchoLauncher::GetEchoResponse* response) {
// Take the channel to Echo in the response, bind it to the dispatcher, and
// make an EchoString request on it.
echo.Bind(std::move(response->response), dispatcher);
echo->EchoString("hello!",
[&](llcpp::fuchsia::examples::Echo::EchoStringResponse* response) {
std::string reply(response->response.data(), response->response.size());
std::cout << "Got echo response " << reply << std::endl;
if (++num_responses == 2) {
loop.Quit();
}
});
});
ZX_ASSERT(result.ok());
zx::channel se, ce;
ZX_ASSERT(zx::channel::create(0, &ce, &se) == ZX_OK);
// Make a pipelined request to get an instance of Echo
ZX_ASSERT(launcher->GetEchoPipelined("pipelined: ", std::move(se)).ok());
// A client can be initialized using the client end without waiting for a response
fidl::Client<llcpp::fuchsia::examples::Echo> echo_pipelined(std::move(ce), dispatcher);
echo_pipelined->EchoString(
"hello!", [&](llcpp::fuchsia::examples::Echo::EchoStringResponse* response) {
std::string reply(response->response.data(), response->response.size());
std::cout << "Got echo response " << reply << std::endl;
if (++num_responses == 2) {
loop.Quit();
}
});
loop.Run();
return num_responses == 2 ? 0 : 1;
}
Unlike in the client tutorial, the async loop is run to completion once, which runs both non-pipelined and pipelined code concurrently in order to observe the order of operations. The client keeps track of the number of responses being received, so that it can quit the loop once no more messages from the server are expected.
Build the client
Optionally, to check that things are correct, try building the client:
Configure your GN build to include the server:
fx set core.x64 --with //examples/fidl/llcpp/request_pipelining/client`Build the Fuchsia image:
fx build
Run the example code
To run the example code:
Configure your GN build as follows:
fx set core.x64 --with //examples/fidl/llcpp/request_pipelining/client --with //examples/fidl/llcpp/request_pipelining/server --with //examples/fidl/test:echo-launcherRun the example:
fx shell run fuchsia-pkg://fuchsia.com/echo-launcher#meta/launcher.cmx fuchsia-pkg://fuchsia.com/echo-launcher-llcpp-client#meta/echo-client.cmx fuchsia-pkg://fuchsia.com/echo-launcher-llcpp-server#meta/echo-server.cmx fuchsia.examples.EchoLauncher
You should see the following print output in the QEMU console (or using fx log):
[190179.987] 864900:864902> Running echo launcher server
[190180.007] 864900:864902> echo_server_llcpp: Incoming connection for fuchsia.examples.EchoLauncher
[190180.028] 864900:864902> Got non pipelined request
[190180.040] 864900:864902> Got pipelined request
[190180.040] 864900:864902> Got echo request for prefix pipelined:
[190180.049] 864900:864902> Got echo request for prefix non pipelined:
[190180.049] 864810:864812> Got echo response pipelined: hello!
[190180.049] 864810:864812> Got echo response non pipelined: hello!
Based on the print order, you can see that the pipelined case is faster. The echo response for the pipelined case arrives first, even though the non pipelined request is sent first, since request pipelining saves a roundtrip between the client and server and allows clients to enqueue messages on the protocol request channel before the server has proceeded any requests. Servers then handle the requests as soon as they are ready. Request pipelining also simplifies the code.
For further reading about protocol request pipelining, including how to handle protocol requests that may fail, see the FIDL API rubric.