Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Fri, 21 Jun 2013 12:54:20 +0000 (UTC)
From: "Daryn Sharp (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12638070.1363810059559.154693.1371819260733@arcas>
In-Reply-To: <JIRA.12638070.1363810059559@arcas>
References: <JIRA.12638070.1363810059559@arcas>
Subject: [jira] [Commented] (HADOOP-9421) Convert SASL to use ProtoBuf and
 add lengths for non-blocking processing
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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