cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2478) Custom CQL protocol/transport
Date Tue, 10 Jul 2012 13:55:36 GMT

    [ 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

        

Mime
View raw message