Hi Gwen, On Mon, Feb 1, 2016 at 6:06 AM, Gwen Shapira <g...@confluent.io> wrote:
> Could we support separate SASL mechanisms via separate ports? > This option was also discussed in the KIP and there are some advantages as you say. However, there are some drawbacks as well. This was the main reason we separated the ports in first place, to avoid > adding protocol negotiation protocol and allow the server to expect the > correct packets when they arrive to the correct listener. It will be nice > if new additions could use existing design and code. > Yes, but the current design and code are not actually extensible as we use an enum for `SecurityProtocol` and the creation of `ChannelBuilder` is hardcoded based on that enum. Mapping different SASL mechanisms to different ports is actually a bigger change to how the existing code works than the option Rajini favoured in his KIP. This is not to say that we should not do it, just clarifying that it's not necessarily an advantage in terms of code reuse. I would also like to point out that we do protocol negotiation in Kafka in SSL/TLS today, so it is not totally without precedent. The server and client negotiate an appropriate SSL/TLS version depending on options set by both the client and server, not unlike what Rajini has proposed. Of course, this is a more limited version as the protocols are related and the negotiation is handled by the SSL/TLS libraries. Ismael
