thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Slee <>
Subject RE: question on UDP
Date Tue, 08 Sep 2009 23:22:29 GMT
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 [] 
Sent: Friday, September 04, 2009 12:20 PM
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.


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 <> wrote:
> From: Bryan Duxbury <>
> Subject: Re: question on UDP
> To:
> 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

View raw message