Skip to content

Add optional FlatBuffers RPC support - #3559

Open
AnDiXL wants to merge 4 commits into
apache:masterfrom
AnDiXL:review/flatbuffers-rpc-3558
Open

AnDiXL wants to merge 4 commits into
apache:masterfrom
AnDiXL:review/flatbuffers-rpc-3558

Conversation

@AnDiXL

@AnDiXL AnDiXL commented Sep 21, 2026 •

Copy link
Copy Markdown
Contributor

What problem does this PR solve?

This continues the RPC work in #3197 on top of #3558, which is now merged. #3558 added the FlatBuffers messages, builders, service descriptors and the brpc_flatc generator; this PR adds the optional fb_rpc transport on top of it.

The branch is rebased onto master after #3558 and contains only the four RPC commits.

What is changed and the side effects?

  • Add FlatBuffers RPC protocol support: optional fb_rpc transport, Channel/Controller/Server integration, service lifecycle handling, attachments, retries and concurrency, with 33 protocol tests.
  • Add a generated FlatBuffers RPC example: generated client/server example with a bounded loopback smoke test. This is functional validation, not a performance benchmark.
  • Add explicit FlatBuffers ON validation: an ON validation runner, its self-tests and a GitHub Actions workflow.
  • Document FlatBuffers setup and example checks: Chinese and English setup, dependency, ABI and example-verification documentation.

The transport uses explicit metadata lengths, so optional fields can be appended later while the known prefix stays readable. Existing protobuf-facing Protocol callback signatures are unchanged.

Side effects and limits:

  • FlatBuffers stays disabled by default. Enabling it changes the Channel, Controller and Server ABI, so the library and its users must be built with matching settings. Protobuf remains a dependency.
  • FRPC authentication, compression, checksums and streaming are not supported. No compatibility with earlier experimental FRPC wire formats and no performance improvement is claimed.
  • After the CMake restructuring in Refactor CMake source and target ownership into module directories #3618, the build tree no longer stages output/include. The ON runner and the docs now install the runtime into a prefix before building the example.

Validation

Run on the rebased head 48177aa2:

Environment Result
macOS, Apple Clang 15, Protobuf 3.21, CMake ON runner 22 message + 33 protocol tests, two codegen tests, one example smoke; no failures or skips
Linux x86_64 (Ubuntu 22.04 container), GCC 11, CMake ON runner same counts, no failures or skips
macOS, example linked against the shared library (LINK_SO=ON) smoke passed
macOS, FlatBuffers OFF (default) builds; no FlatBuffers sources are compiled
python3 .github/scripts/test_flatbuffers_on.py 26 tests passed

The example smoke verifies 13 replies, 2 expected schema rejections and a clean shutdown.

Not covered by these runs: Make and Bazel ON modes (left to CI), sanitizer runs and performance benchmarks.


Check List:

  • Add optional FlatBuffers messages and code generation #3558 has merged and this branch is rebased onto the updated master.
  • Protocol regressions, generated example and enablement documentation are included.
  • macOS and Linux GCC ON runs passed on the rebased head.
  • Hosted CI for this PR has completed.

@AnDiXL

AnDiXL commented Oct 23, 2026

Copy link
Copy Markdown
Contributor Author

Hi @chenBright @wwbmmm @zchuango @darion-yaphet, thanks again for all the reviews on #3558!

#3559 is the last PR in the FlatBuffers series: the optional fb_rpc transport on top of #3558.

Could you please take a look when you have time? Any feedback is welcome. Thanks!

xulei25 added 4 commits October 23, 2026 15:26
Add the optional fb_rpc transport with length-delimited metadata and
stable method IDs, and integrate it with Channel, Controller and Server
without changing the existing protobuf Protocol callback signatures.

Keep request buffers immutable across retries and concurrent calls, and
manage service ownership, asynchronous completion and concurrency
limits. Reject invalid frames and unsupported authentication,
compression, checksums and streams.

The feature stays disabled by default in CMake, Make and Bazel. Add 33
protocol tests covering the wire format, service lifecycle, malformed
input and real RPC round trips.
Add a client/server example built from a generated service, with a
bounded loopback smoke test: 13 verified replies, 2 expected schema
rejections and a clean shutdown. It is a functional check, not a
benchmark.

The example takes an installed FlatBuffers-enabled bRPC and writes the
code generated by flatc and brpc_flatc into its own build directory.
Add a runner that builds and tests the FlatBuffers-enabled
configuration with CMake, Make or Bazel and rejects empty, filtered or
skipped test runs. Add its self-tests and a GitHub Actions workflow that
runs it on Linux and macOS when FlatBuffers-related paths change.
Add Chinese and English guides covering how to enable FlatBuffers, the
dependency and ABI requirements, building the runtime, running the
example and its smoke test, the network RPC API and the FRPC wire
format. Update the generator README for the RPC example.
@AnDiXL
AnDiXL force-pushed the review/flatbuffers-rpc-3558 branch from 48177aa to 8cbb17b Compare October 23, 2026 07:33
@chenBright
chenBright requested a balanced review from Copilot October 23, 2026 08:34

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Copilot review overview

4 open issues
What changed in this PR

This PR adds optional FlatBuffers RPC (“fb_rpc”) transport support on top of the existing FlatBuffers message/service generation work, plus an end-to-end example and a dedicated FlatBuffers-ON validation workflow.

Changes:

  • Integrates fb_rpc as a new built-in Protocol with Channel/Controller/Server support, service registration, and concurrency integration.
  • Adds comprehensive FlatBuffers protocol/unit tests and wires them into CMake/Make/Bazel test builds.
  • Adds a generated client/server example with a bounded smoke test, updated documentation (EN/CN), and a GitHub Actions “FlatBuffers ON” gate runner.
File Description
tools/​flatbuffers/​README.md Updates generator README to point to runtime enablement + fb_rpc usage and verification guidance.
test/​brpc_flatbuffers_protocol_unittest.cpp Adds dedicated protocol-level and lifecycle tests for fb_rpc.
test/​brpc_channel_unittest.cpp Avoids colliding with newly assigned built-in protocol IDs in channel tests.
test/​Makefile Ensures FlatBuffers protocol tests are excluded when FlatBuffers is OFF and builds/link rules include the new test.
test/​CMakeLists.txt Adds brpc_flatbuffers_protocol_unittest to CMake test targets when FlatBuffers is ON.
test/​BUILD.bazel Adds Bazel cc_test for brpc_flatbuffers_protocol_unittest and excludes it from generic globbed tests.
src/​brpc/​server.h Introduces FlatBuffers service registration API and internal method property plumbing (guarded by BRPC_WITH_FLATBUFFERS).
src/​brpc/​server.cpp Implements FlatBuffers service registry, versioning/stat exposure, concurrency limiter hookup, and conflict checks with protobuf services.
src/​brpc/​policy/​flatbuffers_protocol.h Declares the fb_rpc protocol hook points (parse/verify/serialize/pack/process).
src/​brpc/​policy/​flatbuffers_protocol.cpp Implements FRPC framing, request/response processing, and async completion lifecycle for FlatBuffers RPC.
src/​brpc/​options.proto Reserves built-in PROTOCOL_FLATBUFFERS_RPC = 30.
src/​brpc/​global.cpp Registers fb_rpc as a built-in protocol when FlatBuffers is enabled.
src/​brpc/​details/​server_private_accessor.h Exposes FlatBuffers method lookup to protocol code via server private accessor.
src/​brpc/​details/​controller_private_accessor.h Adds private setter for FlatBuffers method descriptor on Controller.
src/​brpc/​controller.h Adds Controller::flatbuffers_method() accessor and stores FlatBuffers method descriptor pointer.
src/​brpc/​controller.cpp Clears FlatBuffers method context in Controller::ResetPods().
src/​brpc/​channel.h Extends Channel to implement flatbuffers::RpcChannel and adds FBCallMethod.
src/​brpc/​channel.cpp Routes FlatBuffers calls via FBCallMethod, adds entry validation, and adjusts tracing method-name selection.
src/​brpc/​CMakeLists.txt Ensures flatbuffers_protocol.cpp is excluded when FlatBuffers is OFF.
example/​benchmark_fb/​smoke.py Adds bounded end-to-end smoke test orchestration for generated FB client/server.
example/​benchmark_fb/​server.cpp Adds example FlatBuffers server (protocol fb_rpc, service registration, graceful shutdown).
example/​benchmark_fb/​echo.fbs Defines example schema and stable wire ID for the RPC method.
example/​benchmark_fb/​client.cpp Adds example FlatBuffers client driving generated stub + verifies response schema/attachments.
example/​benchmark_fb/​README.md Documents building/running the example and what the smoke test validates.
example/​benchmark_fb/​CMakeLists.txt Adds standalone CMake build for the example + codegen steps and smoke CTest.
docs/​en/​flatbuffers.md Expands docs to cover fb_rpc enablement, full verification steps, and limitations.
docs/​cn/​flatbuffers.md Mirrors EN documentation updates for fb_rpc enablement and verification steps.
README_cn.md Links to the CN FlatBuffers RPC guide.
README.md Links to the EN FlatBuffers RPC guide.
Makefile Excludes flatbuffers_protocol.cpp from Make builds when FlatBuffers is OFF.
CMakeLists.txt Updates WITH_FLATBUFFERS option description to include RPC support.
BUILD.bazel Includes flatbuffers_protocol.cpp in FlatBuffers-enabled Bazel source patterns.
.gitignore Stops ignoring .github/ to keep workflows/scripts discoverable.
.github/​workflows/​flatbuffers-on.yml Adds a CI workflow that runs the FlatBuffers-ON gates across CMake/Make/Bazel on Linux/macOS.
.github/​scripts/​test_flatbuffers_on.py Adds self-tests validating the gate script’s report parsing and safety checks.
.github/​scripts/​flatbuffers-on.py Adds an “ON runner” that builds deps, runs unit/codegen/example tests, and rejects empty/skipped runs.

Review effort: Lite

Comment thread src/brpc/channel.cpp
return;
}
cntl->set_used_by_rpc();
const bool is_fb_protocol = (_options.protocol == PROTOCOL_FLATBUFFERS_RPC);
Comment thread src/brpc/channel.cpp
const int64_t start_send_us = butil::cpuwide_time_us();
std::string method_name;
if (_get_method_name) {
if (_get_method_name && is_fb == is_fb_protocol) {
Comment thread src/brpc/server.cpp
Comment on lines +1796 to +1798
// Keep ownership with the caller until the entire record is published.
auto record = std::make_unique<FlatBuffersServiceMap::Service>(service, sd);
std::unordered_set<std::string> method_names;
Comment thread src/brpc/server.cpp
Comment on lines +160 to +169
Method* FindMethodByFullName(const butil::StringPiece& fullname) const {
for (const auto& service : services) {
for (const auto& method : service.second->methods) {
if (method.second->property.method->full_name() == fullname) {
return method.second.get();
}
}
}
return nullptr;
}
@wwbmmm

wwbmmm commented Oct 25, 2026

Copy link
Copy Markdown
Contributor

[replied by brpc-oncall robot] Thanks for splitting the RPC increment out of #3197 and for the very thorough documentation. Because this PR adds a new built-in protocol together with public API on Channel/Server (and changes their layout when BRPC_WITH_FLATBUFFERS is on), I'd like to settle a few architecture points before going through the implementation line by line.

  1. Motivation and cost/benefit. The PR explicitly claims no performance improvement yet, and the example is functional validation only. A new wire protocol is a permanent maintenance commitment (framing, compatibility, tests, docs), and fb_rpc gives up authentication, compression, checksums, streaming, log-id/user-field propagation and RPC dump that protocols such as baidu_std already provide. Could you add a short design note (or point to the agreed design in flatbuffers support(3/3): Add flatbuffers protocol support for brpc #3197) that states the concrete use cases this transport targets and why they cannot be served today, ideally with at least a micro-benchmark of fb_rpc against a protobuf/baidu_std baseline? Without that it is hard to judge whether the benefit justifies the cost.

  2. ABI. With BRPC_WITH_FLATBUFFERS=1, Channel gains a second base class and Channel/Controller/Server change layout, so the library and every consumer must be rebuilt with the same setting. The docs are honest about it, but this effectively rules out packaged/prebuilt brpc and doubles the ABI configurations the project has to reason about. Is that acceptable long term, or could the transport live in a separate optional component/target (or avoid changing core class layouts)?

  3. Parallel service registry. Server now keeps a second registry that re-implements ownership, duplicate/conflict checks, the version string, bvar exposure, concurrency-limiter setup and string-based per-method option lookup for FlatBuffers methods, while ListServices and the status surfaces still only see protobuf services (although GetStat().user_service_count now includes FlatBuffers services). Every future per-method option must be added twice or will silently not apply to FlatBuffers services. Would it be feasible to factor this into a shared internal registry abstraction? At minimum the user_service_count vs. ListServices divergence should be resolved, and keeping a full-name index in the registry (as protobuf does with _method_map) would avoid the O(services x methods) name lookups.

  4. Wire format. Since compatibility with the old experimental FRPC variants is explicitly not promised, retaining their mixed endianness (big-endian header, little-endian metadata) and the FRPC magic adds complexity without a stated benefit. Before the format is frozen it would be cheaper to use one endianness throughout; if the legacy layout must be preserved, please state why in the docs, as readers will otherwise assume it is accidental.

Note: Copilot's three findings above look like false positives to me. AdaptiveProtocolType has operator ProtocolType(), so _options.protocol == PROTOCOL_FLATBUFFERS_RPC compiles and is the idiom already used elsewhere in channel.cpp; server.cpp already includes <unordered_set> at the top; and the is_fb == is_fb_protocol guard deliberately avoids calling a protocol's protobuf get_method_name hook with a null method descriptor (GetFlatBuffersMethodName is installed for fb_rpc).

Thanks!

const uint32_t attachment_size = Load32(meta + 8);
const bthread_id_t correlation_id = {Load64(meta + 12)};
Controller* cntl = nullptr;
const int rc = bthread_id_lock(correlation_id, reinterpret_cast<void**>(&cntl));

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bthread_id_lock() validates a process-wide correlation ID, but does not verify that the response arrived on the socket used by that request. A response carrying another in-flight RPC's valid ID can therefore modify and complete that RPC.

Please follow the existing protobuf response handlers: check that cntl is non-null and call does_response_match_request_socket() before modifying the Controller or response. Unlock and discard the message when validation fails, and add regression coverage for mismatched sockets and stale retry responses.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants