mxsm commented on code in PR #4702:
URL: https://github.com/apache/eventmesh/pull/4702#discussion_r1445527694
##########
eventmesh-common/src/main/java/org/apache/eventmesh/common/protocol/tcp/codec/Codec.java:
##########
@@ -116,31 +102,45 @@ public void encode(ChannelHandlerContext ctx, Package
pkg, ByteBuf out) throws E
}
}
- public static class Decoder extends ReplayingDecoder<Package> {
+ public static class Decoder extends LengthFieldBasedFrameDecoder {
+
+ public Decoder() {
+ super(FRAME_MAX_LENGTH, PREFIX_LENGTH, Integer.BYTES, -9, 0);
Review Comment:
> @mxsm I'm curious to understand the thought processes behind choosing a
hard-coded value over a dynamic value. I'm wondering about potential future
flexibility. Have we considered scenarios where the header structure might
evolve, and how a dynamic approach might handle those cases?
@harshithasudhakar For a custom protocol, once it is determined, it will not
undergo significant changes for a considerable period of time. This is because
any changes to the protocol structure may introduce compatibility issues,
potentially requiring existing users to perform a comprehensive upgrade to
resolve them. In such cases, a major version upgrade, such as upgrading to
version 2.x, may be necessary to undertake protocol modifications. Once the
protocol is modified, it will be necessary to reprocess the encoding and
decoding of the protocol. Therefore, I believe there is limited need for
dynamic handling of these issues. Dynamically setting values increases the
complexity of the code.
--
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]
