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:[email protected]] Sent: Friday, September 04, 2009 12:20 PM To: [email protected] 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 <[email protected]> wrote: > > > From: Bryan Duxbury <[email protected]> > Subject: Re: question on UDP > To: [email protected] > 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 > > > >
