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 ByteArrayOutputStream. 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 end. - 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 object. On Sat, Jun 11, 2011 at 12:40 PM, Simon Heath <[email protected]> wrote: > On Sat, Jun 11, 2011 at 11:27 AM, Paul Mans <[email protected]> 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: > http://diwakergupta.github.com/thrift-missing-guide/#_generated_code > > 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 http://alopex.li/ Science, games, computers, life. >
