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 00:09:21 GMT

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

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

bq. The abstract name appears in the stringified UGI, so it's not applicable to call it CHALLENGE_RESPONSE.

It's still really a mechanism name (vs KERBEROS, PLAIN etc.) and I don't think ID_TOKEN or
SSO_TOKEN being appropriate in SaslRpcServer.AuthMethod. But I'm not insisting.

bq.  If we upgrade the digest mechanism for tokens, that new mechanism may also have an initial
response

Challenge response is the main performance use case that's worth optimizing for. Digest-MD5
doesn't have initial response. The main (only?) potential replacement SCRAM doesn't use server
name at all (ie, no digest-uri issue in HA cases). The code can be generic sasl exchange,
we just take advantage of the fact the token based auth is automatically optimized if you
send the client initiation with connection header. The server can simply return a negotiate
response with server name if the server name from the initial response doesn't match for non-token
mechanisms.

bq. Initial response is true for other mechanisms like GSSAPI and PLAIN, which means kerberos
has just been penalized

No. For normal situation (where the client's assumed server name matches server's), I save
a negotiation round trip. For fail over situation, server can simply return a negotiation
with server name, so the client can reinitialize the saslclient with the correct servername
and send the correct "initial" response, which is the same number of round trip as your normal
case.

bq. Backing up, I thought we agreed earlier to defer reconnect optimizations to a future jira?

I can definitely compromise for clear trade-offs. But I'd like to make sure we both fully
understand the implications/alternatives before moving on.
                
> 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