hadoop-common-issues mailing list archives

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

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

Daryn Sharp commented on HADOOP-9421:
-------------------------------------

bq. I meant you'll be SOL to make the token optimization work. Your protocol requires an extra
round trip to support SCRAM.

Ok, so now how would you handle improved serverId based tokens?  Always take the REINITIATE
hit?

bq. For most common hadoop auth work load: distributed containers/tasks, you don't need to
guess, it's the delegation token with digest-md5/scram

In a mixed security env including not just within the cluster but across different clusters
with different versions, or during rolling upgrades when supported mechanisms are upgraded,
it will always be a guess.  You'll always have to do the REINITIATE?

bq. For this contrived case, the client can catch exceptions for the preferred auth when generating
the initial token, which would apply to fetching a service ticket for non-kerberos server

In mixed security envs, or rolling upgrades, or use of IP failover are a contrived use case?
 In all these cases, we'll also take the penalty of an unnecessary roundtrip to the KDC for
a non-existent service ticket?

bq. cache the server auth/mechs for later use to save a round-trip later
In this case, can't the client just blast the INITIATE before getting a NEGOTIATE?

Actually, the client receiving a NEGOTIATE will allow the client to know in advance of the
server reply whether its guess will fail and it can begin preparing the proper auth.

bq. In summary, my protocol gives that choice to real system designers. Your protocol takes
away that choice because you could not possibly think of all use cases, where auth latency
matters.

As I asked before, do you believe there will actually be a measurable performance difference?
 Will having the client ignore the inflight NEGOTIATE on a reconnect have a measurable latency?
 If so, is the extra round trip for REINITIATEs a bad thing?
                
> 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
>            Priority: Blocker
>         Attachments: HADOOP-9421.patch, HADOOP-9421.patch, HADOOP-9421.patch, HADOOP-9421.patch,
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