You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by George Porter <gm...@cs.ucsd.edu> on 2010/11/12 02:25:23 UTC

Accessing RPC context at the server

Hello everyone,

I had a sortof newbe question that I was hoping you might be able to answer.

I've implemented the server side of an RPC server in CPP, by
implementing the various methods that were autogenerated by the thrift
compiler.

>From what I can tell, those methods are "stateless", in that there is
no way to get information about which client you are executing the
method on behalf of, or what their IP address is, or that type of
thing.  Is this true?

Thanks,
George

Re: Accessing RPC context at the server

Posted by George Porter <gm...@cs.ucsd.edu>.
Thanks for your reply.  I figured it was something like this :)

-George

On Fri, Nov 12, 2010 at 1:29 AM, Matthieu Imbert
<ma...@ens-lyon.fr> wrote:
> On 11/12/2010 02:25 AM, George Porter wrote:
>>
>> Hello everyone,
>>
>> I had a sortof newbe question that I was hoping you might be able to
>> answer.
>>
>> I've implemented the server side of an RPC server in CPP, by
>> implementing the various methods that were autogenerated by the thrift
>> compiler.
>>
>>> From what I can tell, those methods are "stateless", in that there is
>>
>> no way to get information about which client you are executing the
>> method on behalf of, or what their IP address is, or that type of
>> thing.  Is this true?
>>
>> Thanks,
>> George
>>
>
> Hi George,
>
> I was also willing to access client information from the server (like, for
> example IP address / port), and associate some context with connexions.
>
> A while ago i asked similar questions on the mailing list and the answers
> from thrift developers were that:
>
> - the protocol must not be tied to a specific transport -> accessing IP
> address for example would tie the protocol to a TCP/IP transport
>
> - stateless is better than statefull
>
> Don't take me wrong, I completely agree with these arguments.
>
> But for various reasons, i had to associate state with each connexion, and
> access some connexion data. I found no way to do it using regular thrift,
> but i was able to hack my twisted python thrift server to do it (basically:
> there is in my server a thrift protocol instance for each connexion, instead
> of a global one). I guess you need to do the same kind of hacking with your
> C++ server (i don't know if its doable!).
>
> my 0.02€...
>
> --
> Matthieu
>

Re: Accessing RPC context at the server

Posted by Matthieu Imbert <ma...@ens-lyon.fr>.
On 11/12/2010 02:25 AM, George Porter wrote:
> Hello everyone,
>
> I had a sortof newbe question that I was hoping you might be able to answer.
>
> I've implemented the server side of an RPC server in CPP, by
> implementing the various methods that were autogenerated by the thrift
> compiler.
>
>> From what I can tell, those methods are "stateless", in that there is
> no way to get information about which client you are executing the
> method on behalf of, or what their IP address is, or that type of
> thing.  Is this true?
>
> Thanks,
> George
>

Hi George,

I was also willing to access client information from the server (like, for example IP address / port), and associate some context with connexions.

A while ago i asked similar questions on the mailing list and the answers from thrift developers were that:

- the protocol must not be tied to a specific transport -> accessing IP address for example would tie the protocol to a TCP/IP transport

- stateless is better than statefull

Don't take me wrong, I completely agree with these arguments.

But for various reasons, i had to associate state with each connexion, and access some connexion data. I found no way to do it using regular thrift, but i was able to hack my twisted python thrift server to do it (basically: there is in my server a thrift protocol instance for each connexion, instead of a global one). I guess you need to do the same kind of hacking with your C++ server (i don't know if its doable!).

my 0.02€...

-- 
Matthieu