[
https://issues.apache.org/jira/browse/KAFKA-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14210065#comment-14210065
]
Gwen Shapira edited comment on KAFKA-1684 at 11/13/14 5:41 PM:
---------------------------------------------------------------
I'm trying to pull out the parts that add the multi-channel support to the
network protocol and implementation and separate them from the SSL parts. This
will go into KAFKA-1683 and hopefully unblock the Kerberos work a bit.
One of the things I'm not sure about is evolving of APIs.
It looks like we need to evolve TopicMetadataRequest and UpdateMetadataRequest.
TopicMetadataRequest will include a channel type string and return only brokers
that support this specific channel type.
UpdateMetadataRequest will include supported channels for the brokers in the
list.
[~junrao] commented:
bq. For backward compatibility, we need to bump up the version number and make
sure that the receiver can parse both versions of the request.
This means we need "readfrom" to create a Request object from buffers with both
versions *and* the handler to do something reasonable with both (say, assume a
PlainTextChannel if the information is missing).
Was that the intent? am I missing something here?
was (Author: gwenshap):
I'm trying to pull out the parts that add the multi-channel support to the
network protocol and implementation and separate them from the SSL parts. This
will go into KAFKA-1682 and hopefully unblock the Kerberos work a bit.
One of the things I'm not sure about is evolving of APIs.
It looks like we need to evolve TopicMetadataRequest and UpdateMetadataRequest.
TopicMetadataRequest will include a channel type string and return only brokers
that support this specific channel type.
UpdateMetadataRequest will include supported channels for the brokers in the
list.
[~junrao] commented:
bq. For backward compatibility, we need to bump up the version number and make
sure that the receiver can parse both versions of the request.
This means we need "readfrom" to create a Request object from buffers with both
versions *and* the handler to do something reasonable with both (say, assume a
PlainTextChannel if the information is missing).
Was that the intent? am I missing something here?
> Implement TLS/SSL authentication
> --------------------------------
>
> Key: KAFKA-1684
> URL: https://issues.apache.org/jira/browse/KAFKA-1684
> Project: Kafka
> Issue Type: Sub-task
> Components: security
> Affects Versions: 0.9.0
> Reporter: Jay Kreps
> Assignee: Ivan Lyutov
> Attachments: KAFKA-1684.patch
>
>
> Add an SSL port to the configuration and advertise this as part of the
> metadata request.
> If the SSL port is configured the socket server will need to add a second
> Acceptor thread to listen on it. Connections accepted on this port will need
> to go through the SSL handshake prior to being registered with a Processor
> for request processing.
> SSL requests and responses may need to be wrapped or unwrapped using the
> SSLEngine that was initialized by the acceptor. This wrapping and unwrapping
> is very similar to what will need to be done for SASL-based authentication
> schemes. We should have a uniform interface that covers both of these and we
> will need to store the instance in the session with the request. The socket
> server will have to use this object when reading and writing requests. We
> will need to take care with the FetchRequests as the current
> FileChannel.transferTo mechanism will be incompatible with wrap/unwrap so we
> can only use this optimization for unencrypted sockets that don't require
> userspace translation (wrapping).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
