thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Mans <>
Subject Re: Using thrift protocol encoding without thrift transport
Date Sat, 11 Jun 2011 22:14:54 GMT
Hi Simon, thanks for the response.

I'm really not sure how much of an improvement UDP will give me, but I
thought I would try it.

In regards to frame ordering, I was thinking as a first pass to just always
show the most recent frame that comes in and throw away any frames which
arrive and are out of date.

I think attempting to formalize this in a question has helped me understand
it a little bit better.  I've summarized below what I think I have to do.
 Feel free to chime in if this isn't the way to go about it or if there are
some more details i'm missing.  I'm initially just sending frames from
Android to iPhone so this addresses that use case.

On the Java side:

   - Write my struct to a byte array by using the 'write' method of my
   generated struct object in conjunction with a protocol like TBinaryProtocol
   which is constructed with a TIOStreamTransport that uses a

In between:

   - Use some mechanism to get the data from the Android app to the iPhone
   app (UDP socket connection in my case).

On the Objective-C side

   - Create an instance of an object that implements the TTransport
   protocol, probably a TNSStreamTransport.
   - Create an instance of whatever TProtocol object I used on the sending
   - Create an instance of the generated thrift object which represents the
   struct I am transporting.
   - Then use the 'read' method of my struct object and pass it my protocol

On Sat, Jun 11, 2011 at 12:40 PM, Simon Heath <> wrote:

> On Sat, Jun 11, 2011 at 11:27 AM, Paul Mans <> wrote:
> > My objective is to create a separate UDP connection between the two
> devices
> > and send only the video frames over that link and use my existing TSocket
> > connection for everything else.
> Out of curiousity, are you sure that UDP will bring you enough
> improvement, and that the TCP connection overhead is the easiest
> problem to attack?  Your comments sort of imply that you need half of
> TCP for frame ordering and such anyway...  I don't know what your app
> does of course, so I'm just being a skeptic.  :-)
> The way to do it would seem to be create new Protocol and Transport
> objects, to serialize the data into a form that can be transmitted
> over UDP and do the transmission.  You would have to have some way of
> dealing with dropped packets though; either re-transmitting them (in
> which case you're re-inventing TCP) or just ignoring them and skipping
> incomplete frames at the application level (probably what you want).
> If you're not familiar with the guts I've found this to be helpful in
> explaining how all the bits fit together:
> Another choice might be to handle image data as a special case and
> transmit it separately.  Even if you manage to make Thrift work over
> UDP you'd need special rules to handle image streams anyway, so it's a
> special case already.
> --
> Simon Heath   Science, games, computers, life.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message