[
https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13089260#comment-13089260
]
Rick Branson commented on CASSANDRA-2478:
-----------------------------------------
So I'll start throwing ideas out there.
I think we should use a simple framed binary transport with a 4-byte frame size
prefix followed by the frame. Inside the frame is the message: a 2-byte integer
indicating message type followed by the message contents, which varies based on
the type. The client sends requests, and the server responds to them.
The Cassandra protocol needs to do the following things, which I would imagine
would equate to a pair of message types (request and response):
- Handshake
- Authentication
- Health Checks (ping/pong)
- CQL Queries (... and a response that encodes rows, columns, and supercolumns)
- CQL Statement Preparation & Execution
Anything I'm missing? It would be nice to make some more complex or problematic
functionality, such as compression and streaming, optional for the client.
> Custom 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
> Priority: Minor
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
