Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Sun, 9 Jun 2013 16:52:20 +0000 (UTC)
From: "Luke Lu (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12638070.1363810059559.91483.1370796740705@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: quoted-printable


    [ https://issues.apache.org/jira/browse/HADOOP-9421?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D136=
79107#comment-13679107 ]=20

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

bq. As-is, it would be possible for the client to blindly send the connecti=
on header & INITIATE and just ignore the NEGOTIATE response.

I'm concerned about the client code needed to maintain backward-compatibili=
ty. If client is enhanced to INITIATE first, client will need to always ign=
ore the first NEGOTIATE and have to handle the second NEGOTIATE, which make=
s the client logic confusing and you cannot make the first dumb NEGOTIATE (=
which is size of O(number of mechs/protocols)) go away, it'll always be par=
t of the protocol. The code is also replicated per client per language, whi=
ch is a higher cost than just maintaining it at the server side. If client =
always sends a INITIATE, which could be empty, it is IMO easier to understa=
nd and evolve: server can handle the INITIATE and there will not be any was=
ted NEGOTIATE. In the era of YARN, where NN is resource strapped to handle =
the flood of requests from containers/tasks, I think it'd be worthwhile to =
leave room for optimization to reduce the amount of extra processing at the=
 server side. The current approach will always have an extra NEGOTIATE that=
 cannot be optimized away.

Also, I noticed that you deprecated DIGEST and added TOKEN as an auth metho=
d (essentially renamed DIGEST to TOKEN) in SaslRpcServer. Though DIGEST is =
not exactly a precise word here, TOKEN is, IMO, even more nebulous. How abo=
ut CHALLENGE_RESPONSE or simply CR? I'd prefer the rename to be in separate=
 JIRA as well, as it doesn't really affect the wire protocol.=20
               =20
> 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.pa=
tch, 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 administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira