[
https://issues.apache.org/jira/browse/CASSANDRA-16360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17324221#comment-17324221
]
Alexey Zotov commented on CASSANDRA-16360:
------------------------------------------
In the meantime I've explored the existing logic and the way to support this
new functionality in the next protocol version. Could you, please, validate my
understanding and let me know if I missed smth. Here are the changes I'm going
to do (if we finally decide to move forward):
1. {{ProtocolVersion}} already has "V6" defined, no changes are required here.
However, a new spec needs to be created: "native_protocol_v6_beta.spec".
2. Add a new version of {{MessagingService}}: "VERSION_401" and set it as a
current version (or not yet?).
3. Make changes in {{InboundConnectionInitiator}} /
{{OutboundConnectionInitiator}} to use _CRC32C_ for "VERSION_401".
4. Make changes in {{HandshakeProtocol}} to use _CRC32C_ for "VERSION_401".
5. Make changes in {{PipelineConfigurator}} to use _CRC32C_ for "V6".
6. Add "VERSION_401" case to all existing switch statements ({{Mutation}} /
{{CounterMutation}} / {{Message}} classes)
7. Make changes in {{Frame Decoder/Encoder Crc/LZ4}} to support both _CRC32_
and _CRC32C_. Now they must accept {{ChecksumType}} in constructor/"create"
method. I feel creating separate classes for _CRC32C_ would be an overhead.
Also I think using {{ChecksumType}} instead of {{Crc}} with static methods
makes a "structural" advantage. Thoughts/concerns?
8. Add _CRC32C_ support to {{ChecksumType}} and remove _CRC32_ support from
{{Crc}}. Going further {{Crc}} will be used for _CRC24_ calculation only. At
the moment, there is no intrinsic implementation for _CRC24_, hence re-writing
the implementation does not make any sense.
9. Tests, tests, tests..
> CRC32 is inefficient on x86
> ---------------------------
>
> Key: CASSANDRA-16360
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16360
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
> Reporter: Avi Kivity
> Priority: Normal
> Labels: protocolv5
> Fix For: 4.0.x
>
>
> The client/server protocol specifies CRC24 and CRC32 as the checksum
> algorithm (cql_protocol_V5_framing.asc). Those however are expensive to
> compute; this affects both the client and the server.
>
> A better checksum algorithm is CRC32C, which has hardware support on x86 (as
> well as other modern architectures).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
