[
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
