Hi Community,
I want to start an SIP about "support multi-version protocol control"
> 1 Motivation • Issue 1: The structure of the communication protocol message
> in Seata underwent significant changes in version 0.7.1, without backward
> compatibility for the previous protocol. As a result, users of older versions
> of the server must upgrade both the server and the client simultaneously when
> upgrading, which required a complete shutdown for the upgrade. • Issue 2: The
> protocol has extensibility issues. Expanding fields or types leads to
> incompatibility with previous protocols (inconsistent extension methods and
> scattered adaptation logic across layers, causing confusion and unmanageable
> scenarios). • Previous Discussions: Seata PR #4569 , SEATA old and new
> communication protocol structure analysis
> 2 Overview of DesignThe primary goal is for the new version of the Seata
> server to communicate with clients of the older version (the logic for new
> clients communicating with old servers is similar). The tasks include: • The
> new server recognizes the old protocol. • The new server parses the old
> protocol. • The new server marks the counterpart as an old version
> application and binds it to a channel. • The new server initiates
> communication using the old protocol.The second goal is to optimize protocol
> extensibility: • Cross-version adaptation is centralized in the codec (the
> codec is separated by version number). • The server handles business logic
> using the latest version of the message.3 Protocol Structure Compatibility
> Design3.1 Compatibility Design • The new server recognizes the old protocol:
> • ; • As shown above, and detailed in the analysis, the third byte can
> identify the protocol version since versions below 0.6.1 have a different
> value for this byte compared to version 1 and later. • The new server parses
> the old protocol: • Once identified as an old version, the server interprets
> it accordingly. Missing fields are given default values compatible with the
> old version. • The new server marks the counterpart as an old version
> application and binds it to a channel: • When TM/RM registers with TC, TC
> records the channel and saves the protocol version for future messaging. •
> The new server initiates communication using the old protocol: • When the
> TM/RM is identified as an old version client, communication is
> encoded/decoded using the old protocol.3.2 Optimization of Extensibility •
> Codec is separated by version, clearly distinguishing each version. • When
> the server receives a message object (decode): it decodes using the latest
> version codec. • When the server creates a message object (encode): it
> selects the codec based on the version before sending. • Version recognition
> (parsed from the header):
byte b0 = in.readByte();
byte b1 = in.readByte();
// v1/v2/v3 : b2 = version
// v0 : b2=0, 1st byte in FLAG(2byte:0x10/0x20/0x40/0x80)
byte b2 = in.readByte();
> 4 Comparison of Before and After Changing (Server Receiving) • Flowchart: •
> Version separated : The serializer and decoder need to be separated
> (different version numbers correspond to different serializers and decoders).
> • The version number must be clear in the process; The MutiProtocolDecoder
> will identify the version number to determine the corresponding version of
> the channel, ensuring that communication with the client always uses the same
> version format. • For message serialization: v1 and subsequent versions (v2,
> v3, etc.) will be consistent, only v0 differs.5 Comparison of Before and
> After Changing (Server Sending) • Flowchart: • • The changing points match
> those for receiving. • Encoder version: the version number of the header is
> parsed during the first communication (usually register) to determine the
> version number of the encoder. • Message serializer: it depends on the
> encoder.
