hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luke Lu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9421) Convert SASL to use ProtoBuf and add lengths for non-blocking processing
Date Wed, 12 Jun 2013 19:56:21 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13681564#comment-13681564
] 

Luke Lu commented on HADOOP-9421:
---------------------------------

bq. At the moment, I'm only trying to make the minimal changes to the base wire protocol to
allow future extensibility.

The current mechanism is a major change that introduce an extra round-trip of server processing
(more chances of timeouts) that can potentially break a busy cluster. I'm only suggest that
we simply send a length + RpcSaslProto after the connection header (analogous to the current
authmethod byte but more extensible), which open up many opportunities to reduce auth round-trips
in the future without future client baggage.

bq. All SASL mechanisms are challenge/response, not just tokens...

PLAIN is not...

bq. I think you are predicating the optimization on the assumption the client can always pre-determine
the AuthMethod to use.

Not always but 99% of the time for most common workload, where container/tasks access HDFS
with delegation tokens, which is not gonna change no matter how many mechs we'll support in
the future, which are mostly to bootstrap a delegation token or equivalent.

bq. we're holding up the base SASL RPCv9 changes to discuss a pre-mature optimization to avoid
sending <100 bytes, compared to token negotiation requiring at least 5X more bytes, and
kerberos requiring at least 20X more bytes.

The mandatory negotiate response is way more than 100 bytes and will grow as the number of
mechs/protocols grows. The most important thing here is not bytes (as long as it fits into
one packet) but an extra round trip for the most common challenge response mechanism that
currently requires only one extra round trip (over simple).

I guess that I don't understand what's so hard to include the extra (length + RpcSaslProto)
in the protocol. You don't even need to change your existing logic: always send a negotiate
for RPC v9. But that little extra proto makes future evolution of auth so much easier.










                
> Convert SASL to use ProtoBuf and add lengths for non-blocking processing
> ------------------------------------------------------------------------
>
>                 Key: HADOOP-9421
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9421
>             Project: Hadoop Common
>          Issue Type: Sub-task
>    Affects Versions: 2.0.3-alpha
>            Reporter: Sanjay Radia
>            Assignee: Daryn Sharp
>         Attachments: HADOOP-9421.patch, HADOOP-9421.patch, HADOOP-9421.patch, HADOOP-9421.patch,
HADOOP-9421-v2-demo.patch
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message