[ 
https://issues.apache.org/jira/browse/CASSANDRA-12838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alex Petrov updated CASSANDRA-12838:
------------------------------------
    Labels: client-impacting protocolv5  (was: client-impacting)

> Extend native protocol flags and add supported versions to the SUPPORTED 
> response
> ---------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-12838
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12838
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: CQL
>            Reporter: Stefania
>            Assignee: Stefania
>              Labels: client-impacting, protocolv5
>             Fix For: 3.10
>
>
> We already use 7 bits for the flags of the QUERY message, and since they are 
> encoded with a fixed size byte, we may be forced to change the structure of 
> the message soon, and I'd like to do this in version 5 but without wasting 
> bytes on the wire. Therefore, I propose to convert fixed flag's bytes to 
> unsigned vints, as defined in CASSANDRA-9499. The only exception would be the 
> flags in the frame, which should stay as fixed size.
> Up to 7 bits, vints are encoded the same as bytes are, so no immediate change 
> would be required in the drivers, although they should plan to support vint 
> flags if supporting version 5. Moving forward, when a new flag is required 
> for the QUERY message, and eventually when other flags reach 8 bits in other 
> messages too, the flag's bitmaps would be automatically encoded with a size 
> that is big enough to accommodate all flags, but no bigger than required. We 
> can currently support up to 8 bytes with unsigned vints.
> The downside is that drivers need to implement unsigned vint encoding for 
> version 5, but this is already required by CASSANDRA-11873, and will most 
> likely be required by CASSANDRA-11622 as well.
> I would also like to add the list of versions to the SUPPORTED message, in 
> order to simplify the handshake for drivers that prefer to send an OPTION 
> message, rather than rely on receiving an error for an unsupported version in 
> the STARTUP message. Said error should also contain the full list of 
> supported versions, not just the min and max, for clarity, and because the 
> latest version is now a beta version.
> Finally, we currently store versions as integer constants in {{Server.java}}, 
> and we still have a fair bit of hard-coded numbers in the code, especially in 
> tests. I plan to clean this up by introducing a {{ProtocolVersion}} enum.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to