Avro multiplexing, availability of authentication info to services

[Sam Lawrance <sa...@illumynite.com>]

Hi all, 

I have a couple of questions - I have read through some related discussions on the list and also through the code, so this is mainly to confirm my thinking.

Is there any capability, or is anyone aware of work on the ability to multiplex protocols to avoid the use of one port per protocol (for most transports)?  An example could be an application that allows additional RPC services to be included by a plugin mechanism.  Right now it looks like the answer is no, however I did see a suggested approach here for HTTP:  

http://mail-archives.apache.org/mod_mbox/avro-dev/201006.mbox/%3cAANLkTimshKoQqKlav5Dfd5u2oZyxS3lNjGdtjb9BuC3K@mail.gmail.com%3e

Second question - is there any way for the service implementation to obtain information about the calling client, such as the hostname or some form of context from SASL?  The purpose is to verify that the client is who they say they are at each call, without having to resort to passing tokens in to every call (which is what I have seen suggested elsewhere).

Any thoughts are welcome.  I’m just starting to look at this so hopefully what I am asking makes sense.

Cheers
Sama

Re: Avro multiplexing, availability of authentication info to services

[Doug Cutting <cu...@apache.org>]

On Fri, Aug 22, 2014 at 6:34 AM, Sam Lawrance <sa...@illumynite.com> wrote:

> is there any way for the service implementation to obtain information
> about the calling client, such as the hostname or some form of context from
> SASL?


Transceiver#getRemoteName() returns the remote host name, but this is not
currently easily accessed from a service implementation.

If access from message implementation is desired, then we could add a
static Responder#getTransceiver() method that reads a ThreadLocal set
around calls to Responder#respond(Message,Object).

If access for every call to a given server is desired, then we might add an
RPCContext#getTransceiver() method that accesses a field set by Responder
that would then be visible to RPCPlugin implementations.

Doug