[
https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410343#comment-13410343
]
Sylvain Lebresne commented on CASSANDRA-2478:
---------------------------------------------
Let me try to clarify my position.
The current versioning is per-frame, so widening it would be a per-frame extra
cost. Furthermore, I like that the header is just 8 bytes, because that's 1)
small and 2) easy to decode (even for debuging with tcpdump or other).
And the idea of the current implementation was to say:
# there is just one version for the whole protocol.
# two different protocol versions are incompatible, period (though we should
make the guarantee that a server is always able to understand at least the
STARTUP message of every old versions to be able to return an error with what
versions are supported).
# we will be nice and have server understand old protocol version for at least
1 or 2 major C* version after we've changed them.
As far as I can tell, this does cover what we need, i.e. clients can always
tell whether they can talk to a server or not and we have a clear compatibility
story (not the same version == not compatible). I'll note that this is how we
version our internal protocol (not trying to imply it's the exact same problem
but ...).
That being said, I would agree there is at least 2 missing pieces in the
implementation currently:
* The server should respond with an error to the STARTUP message if the version
is not understood (with a list of supported version) which is not implementated
yet.
* The OPTIONS/SUPPORTED pair of message could return the support protocol
version too. But I plan to modify the SUPPORTED message in a separate ticket to
make it more versatile anyway, so I'll do that then.
There is the argument that a 7 bits version number might not be enough. On
that, my personal belief is that we don't have a choice: we have to make it
enough if we want the protocol to be used. You can have a network protocol that
change every two weeks. If it changes all the time, it's *not* a "protocol".
And it happens that I think it's very possible to achieve a stable protocol,
because imho there is not infinitely many things that the protocol can do
(which again doesn't mean there isn't tons of stuff the current implementation
doesn't handle correctl, but that's ok, it's *not* the final version and the
goal *is* to add those missing stuff for the final version). This especially
true imho because we have CQL. New queries capabalities will not imply a change
in the protocol for instance. Typically, I don't know that libpq changes all
the time or lacks hundreds of features.
bq. async messaging
I'm warming up to the idea of allowing async query handling too actually,
especially because I think we can make it option for the client. But I'll open
a separate ticket.
bq. challenge/response auth
As said above, I'm all for having SASL and I certainly intend to have that for
version 1, I just prefer handling that in it's own ticket. Again, the committed
version is not version 1.
Now, separating the versioning into a simple frame version and another
per-connection message version is a possibily, but I'm afraid of the following
downsides:
* It complicates things. You know have to care about case like the server
handle the frame version but not the messaging one or the contrary. You also
need to document the versions separatly, so you need a versionned document for
the frame protocol and one for the message protocol. Again, feels like a single
version where different version == incompatible is simpler.
* I really do believe that having the protocol stable (as in, one version per
C* major version as a worst case) is not an option. Adding a more complex
versioning doesn't convey that intention and will make it easier for us to make
excuses to break the protocol often. I don't want that.
* I'm not sure the 3-part semantic versioning makes complete sense for a
protocol. A least the last part (the 'patch' version) does not make sense
because this info will be carried by the C* version (you don't "patch" a
protocol, you patch an implementation of that protocol). For the minor version,
it's more debatable I suppose, but I would make the argument that it doesn't
make sense either. Again because a protocol is different from it's
implementation. Any change to a protocol will break either the server or the
client so there isn't really minor changes. Again, on simple major version
seems much simpler.
bq. (a) a signal to clients of compatibility
My argument below is that this signal exists since we do have a version
bq. (b) an acknowledgement of a possibly-remote chance of failure; a safety net
We have a safety net since we have a version. With the 'only major version'
versioning I'm advocating, in the remote change we've fail at keeping things
stable, one version purpose can be to introduce finer grained versioning.
Introducing finer grained versioning right away is not a safety net, it's
saying that you expect to fail.
> Custom CQL protocol/transport
> -----------------------------
>
> Key: CASSANDRA-2478
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2478
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
> Reporter: Eric Evans
> Assignee: Sylvain Lebresne
> Priority: Minor
> Labels: cql
> Fix For: 1.2
>
> Attachments: cql_binary_protocol, cql_binary_protocol-v2
>
>
> A custom wire protocol would give us the flexibility to optimize for our
> specific use-cases, and eliminate a troublesome dependency (I'm referring to
> Thrift, but none of the others would be significantly better). Additionally,
> RPC is bad fit here, and we'd do better to move in the direction of something
> that natively supports streaming.
> I don't think this is as daunting as it might seem initially. Utilizing an
> existing server framework like Netty, combined with some copy-and-paste of
> bits from other FLOSS projects would probably get us 80% of the way there.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
