Claudenw commented on PR #2647:
URL: https://github.com/apache/cassandra/pull/2647#issuecomment-1750727124
I may be missing something here but during handshake initiation you have to
deal with 3 possible communication configurations with the new CRC.
| initiator | peer |
| --------- | --------|
| old-CRC | new-CRC |
| new-CRC | old-CRC |
| new-CRC | new-CRC |
My reading of the Handshake.java file indicates that the initial handshake
has a CRC digest attached.
If the old-CRC is initiating then the new-CRC has to validate against the
old-CRC, so it must have the old-CRC code and be ready to used it.
if the new CRC is initiating then it must use the old CRC to communicate
with the old-CRC.
So the old-CRC code still has to exist in the codebase and it has to be used
for session initiation.
Is there something in the new code that guarantees that the initiation
sequencde uses the old-CRC?
My thought is that we could use another flag in the init header the on
initiation being set means (I accept new-CRC) and the a new-CRC supporting
client could respond with a message that also has the bit set and uses the
new-CRC, so that we can jump into the new protocol faster.
--
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]
