You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by H P <th...@yahoo.com> on 2009/09/04 19:07:29 UTC
question on UDP
Hi,
I am new to Thrift and it looks like a great framework!. However I have a few questions about it and I would appreciate very much if some one will answer them.
1) Does it support UDP based RPC calls ? For example server receives a request on UDP port and sends back the response to client's UDP port. The client would match request and response using a messageId field. I prefer this over TCP based RPC as I need not handle reconnecvity issues when either server or client goes down and comes back.
2) Does thrift support framing for messages? That would be a great place for me to add messageId field.
3) How does it handle endianness of different hardware/os platforms ?
Thanks,
H.P
Re: question on UDP
Posted by Rush Manbert <ru...@manbert.com>.
On Sep 4, 2009, at 10:14 AM, David Reiss wrote:
>> 1) Does it support UDP based RPC calls ? For example server
>> receives a request on UDP port and sends back the response to
>> client's UDP port. The client would match request and response
>> using a messageId field. I prefer this over TCP based RPC as I need
>> not handle reconnecvity issues when either server or client goes
>> down and comes back.
> No.
You could probably hack my Asio port to use ip::udp::* instead of
ip::tcp::*, but I can't provide any more information than that. See https://issues.apache.org/jira/browse/THRIFT-311
for more information.
- Rush
Re: question on UDP
Posted by David Reiss <dr...@facebook.com>.
Awesome! Thanks for the report.
Samir Mulder wrote:
> On Sep 4, 2009, at 10:14 AM, David Reiss wrote:
>>> 3) How does it handle endianness of different hardware/os platforms ?
>> It should work, though I doubt it has been thoroughly tested.
> I've tested combinations of Java, C++, Perl, and PHP on combinations
> of little- (Linux/Intel) and big-endian (Solaris/SPARC) machines.
> Haven't had any problems.
>
> I'm not running the latest but I haven't seen any code chances in this
> area in SVN either.
>
> Thanks.
>
> Paul
Re: question on UDP
Posted by Samir Mulder <sa...@gmail.com>.
On Sep 4, 2009, at 10:14 AM, David Reiss wrote:
>> 3) How does it handle endianness of different hardware/os platforms ?
> It should work, though I doubt it has been thoroughly tested.
I've tested combinations of Java, C++, Perl, and PHP on combinations
of little- (Linux/Intel) and big-endian (Solaris/SPARC) machines.
Haven't had any problems.
I'm not running the latest but I haven't seen any code chances in this
area in SVN either.
Thanks.
Paul
RE: question on UDP
Posted by Mark Slee <ms...@facebook.com>.
Yeah, this will take some serious hacking. Basically, the TTransport::write() interface assumes that the data can be reliably sent and that after the method returns, the data has been transferred consistently and in-order.
Basically, to get UDP working with the blocking TTransport interface, you'll probably need to push a lot of functionality down into the TTransport internals and loop around in there until you've confirmed receipt on the other end.
On the server side, you'll probably need to end up implementing most of the receiving code inside a TServerTransport. Typically, TServerTransport provides a TTransport to read() from. But with UDP this isn't so easy since the TServerTransport has no real equivalent of listen(). So basically, your TServerTransport would probably actually have to listen for the UDP packets and fully assemble/order them, then return a TMemoryBuffer or something which basically just already holds the fully-read message.
-----Original Message-----
From: David Reiss [mailto:dreiss@facebook.com]
Sent: Friday, September 04, 2009 12:20 PM
To: thrift-user@incubator.apache.org
Subject: Re: question on UDP
It should be, but it will take some hacking. Some of Thrift's core
abstractions are based on the notion of reliable, ordered, byte streams.
--David
H P wrote:
> Thanks everybody.
>
> As a follow up question, is it possible to plug in my own UDP transport implementation into thrift RPC interface? I am implementing the server side code and it is in Java.
> H.P
>
> --- On Fri, 9/4/09, Bryan Duxbury <br...@rapleaf.com> wrote:
>
>
> From: Bryan Duxbury <br...@rapleaf.com>
> Subject: Re: question on UDP
> To: thrift-user@incubator.apache.org
> Date: Friday, September 4, 2009, 6:19 PM
>
>
>>> 3) How does it handle endianness of different hardware/os platforms ?
>> It should work, though I doubt it has been thoroughly tested.
>
> It may not be explicitly stated right now, but any protocol implementation that doesn't manage endianness would be defective in my book.
>
> -Bryan
>
>
>
>
Re: question on UDP
Posted by David Reiss <dr...@facebook.com>.
It should be, but it will take some hacking. Some of Thrift's core
abstractions are based on the notion of reliable, ordered, byte streams.
--David
H P wrote:
> Thanks everybody.
>
> As a follow up question, is it possible to plug in my own UDP transport implementation into thrift RPC interface? I am implementing the server side code and it is in Java.
> H.P
>
> --- On Fri, 9/4/09, Bryan Duxbury <br...@rapleaf.com> wrote:
>
>
> From: Bryan Duxbury <br...@rapleaf.com>
> Subject: Re: question on UDP
> To: thrift-user@incubator.apache.org
> Date: Friday, September 4, 2009, 6:19 PM
>
>
>>> 3) How does it handle endianness of different hardware/os platforms ?
>> It should work, though I doubt it has been thoroughly tested.
>
> It may not be explicitly stated right now, but any protocol implementation that doesn't manage endianness would be defective in my book.
>
> -Bryan
>
>
>
>
Re: question on UDP
Posted by H P <th...@yahoo.com>.
Thanks everybody.
As a follow up question, is it possible to plug in my own UDP transport implementation into thrift RPC interface? I am implementing the server side code and it is in Java.
H.P
--- On Fri, 9/4/09, Bryan Duxbury <br...@rapleaf.com> wrote:
From: Bryan Duxbury <br...@rapleaf.com>
Subject: Re: question on UDP
To: thrift-user@incubator.apache.org
Date: Friday, September 4, 2009, 6:19 PM
>> 3) How does it handle endianness of different hardware/os platforms ?
> It should work, though I doubt it has been thoroughly tested.
It may not be explicitly stated right now, but any protocol implementation that doesn't manage endianness would be defective in my book.
-Bryan
Re: question on UDP
Posted by Bryan Duxbury <br...@rapleaf.com>.
>> 3) How does it handle endianness of different hardware/os platforms ?
> It should work, though I doubt it has been thoroughly tested.
It may not be explicitly stated right now, but any protocol
implementation that doesn't manage endianness would be defective in
my book.
-Bryan
Re: question on UDP
Posted by David Reiss <dr...@facebook.com>.
> 1) Does it support UDP based RPC calls ? For example server receives a request on UDP port and sends back the response to client's UDP port. The client would match request and response using a messageId field. I prefer this over TCP based RPC as I need not handle reconnecvity issues when either server or client goes down and comes back.
No.
> 2) Does thrift support framing for messages? That would be a great place for me to add messageId field.
Yes. There is a TFramedTransport that uses the message size as a header.
There is also a sequence number field in the call and return messages,
though it is currently not set.
> 3) How does it handle endianness of different hardware/os platforms ?
It should work, though I doubt it has been thoroughly tested.
--David