[
https://issues.apache.org/jira/browse/HADOOP-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545650
]
Doug Cutting commented on HADOOP-2184:
--------------------------------------
> you are primarily talking about this patch making RPC#Invocation non-private
> and Client manipulating it, right?
No. RPC should depend on Client, not vice-versa.
Thinking more on it, I'm not yet convinced it is worth it to make this
optimization. How big do we expect tickets to be? We already transmit the
method name, fully-qualified class names of each parameter, etc. with each
request. Invocation serialization is not an RPC bottleneck. For the lifetime
of this implementation, tickets will probably just be username and (perhaps)
password. By the time we have larger tickets, we'll have replaced this
implementation with something socketfactory-based that does a proper, encrypted
handshake. I don't think it's worth adding complexity for something temporary
that won't impact performance significantly. If we subsequently end up sending
big tickets, let's optimize it then, but for now transmitting the ticket per
request is easy and gets us started.
> RPC Support for user permissions and authentication.
> ----------------------------------------------------
>
> Key: HADOOP-2184
> URL: https://issues.apache.org/jira/browse/HADOOP-2184
> Project: Hadoop
> Issue Type: New Feature
> Components: ipc
> Affects Versions: 0.15.0
> Reporter: Tsz Wo (Nicholas), SZE
> Assignee: Raghu Angadi
> Fix For: 0.16.0
>
> Attachments: HADOOP-2184-demo.patch, HADOOP-2184-demo.patch,
> HADOOP-2184-demo.patch
>
>
> Update 11/13/2007: What is proposed for 0.16.0 :
> The client can set a user ticket (as defined in HADOOP-1701) for each
> connection and that ticket is made available to RPC calls at the server. The
> client can replace the ticket at any time. The main advantage is that rest of
> the the client RPCs don't need to be aware of the user tickets.
> What RPC would ideally support in future :
> In the current version of RPC, there is no authentication or data protection.
> We propose to change the RPC framework, so that secure communication is
> possible.
> The new RPC should:
> - Compatible with current RPC
> - Allow a pluggable security implementations (see HADOOP-1701)
> - Support both secure and non-secure modes.
> Here is a rough idea:
> - Store security information (e.g. username, keys) in a ticket
> - Use the ticket to establish a RPC connection
> - Create secure sockets by the (subclass of) SocketFactory corresponding to
> the selected security implementations
> - Send the data and RPC parameters with the secure sockets
> When authentication is supported, the RPC callee should also initialize
> caller information during RPC setup and execute the RPC on the caller's
> behalf.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
