zchuango opened a new pull request, #3507:
URL: https://github.com/apache/brpc/pull/3507
### What problem does this PR solve?
Issue Number: #3463
Problem Summary:
This is Phase 3 PR1 of Issue #3463.
Phase 3 is split into two parts:
- PR1 adds an explicit and backward-safe UBRing data format negotiation
mechanism.
- A follow-up PR will introduce an IPC-specific data format and optimize the
IPC data path.
UBRing currently uses the same legacy data format for both IPC and UBS, but
the handshake only negotiates `hello_ver` and `impl_ver`. Before a follow-up PR
can introduce an IPC-specific format, both peers must explicitly agree on the
same data format.
The existing base Hello is already 64 bytes. Directly appending extension
bytes is unsafe because an old peer may consume only 64 bytes and leave the
extra bytes in the TCP stream, corrupting the following ACK or application data.
This PR only establishes the format-negotiation foundation. It does not
introduce the new IPC data format or change the existing UBRing data path.
### What is changed and the side effects?
Changed:
- Bump the UBRing hello protocol version from V2 to V3 while keeping the
base Hello wire format unchanged at 64 bytes.
- Add `UBR_DATA_FORMAT_NONE` and `UBR_DATA_FORMAT_LEGACY_64`.
- Add a separate fixed-size 4-byte format extension containing a 16-bit
length and a 16-bit format identifier, both serialized in network byte order.
- Exchange the format extension only after both peers confirm V3
compatibility through the base Hello.
- Let the client propose `LEGACY_64`, and let the server select `LEGACY_64`
or `NONE`.
- Map remote shared memory only after a supported, matching, non-`NONE`
format is selected.
- Send ACK=0 and fall back to TCP when format negotiation fails.
- Do not exchange format-extension bytes between V2 and V3 peers.
- Require the base Hello `msg_len` to be exactly 64 so that unsupported
extra Hello bytes cannot remain unread in the TCP stream.
- Record and reset the negotiated data format in `UBShmEndpoint`.
- Add focused tests for serialization/deserialization, network byte order,
`NONE`, unknown format values, and negotiated-format state cleanup.
- Keep the existing UBRing message layout, 64-byte slot, 60-byte payload,
`Copy64Byte`, memory ordering, and send/receive data path unchanged.
The V3 format extension is intentionally fixed at 4 bytes. A different
extension wire size requires negotiation through a future hello version.
Tests:
```text
bazel test --config=ubring //test:brpc_ubring_unittest
```
```text
15 tests from 4 test suites passed.
```
Smoke-test results:
- V3 client + V3 server negotiated `LEGACY_64` and completed RPC requests.
- V3 client + baseline V2 server fell back to TCP and completed 10 RPC
requests.
- Baseline V2 client + V3 server fell back to TCP and completed 10 RPC
requests.
Side effects:
- Performance effects:
V3-to-V3 connections add one fixed 4-byte request, one fixed 4-byte
response, and one handshake round trip. The established UBRing data path has no
additional per-message overhead.
- Breaking backward compatibility:
No unsafe wire compatibility break is introduced. V2 and V3 peers
intentionally fall back to TCP without exchanging format-extension bytes. TCP
RPC traffic remains functional.
---
### Check List:
- Please make sure your changes are compilable.
- When providing us with a new feature, it is best to add related tests.
- Please follow [Contributor Covenant Code of
Conduct](https://github.com/apache/brpc/blob/master/CODE_OF_CONDUCT.md).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
