Charlie, Sounds great. -- looking forward to seeing the patch.
What language are you working in? Chad On 5/25/09 2:08 PM, "Charles Mason" <[email protected]> wrote: On Fri, May 8, 2009 at 10:06 PM, Eric Anderson <[email protected]> wrote: > Kevin Clark writes: > > Almost identical question: > > > http://mail-archives.apache.org/mod_mbox/incubator-thrift-user/200905.mbox/browser > > > > The "game network protocol" thread in march and april: > > > http://mail-archives.apache.org/mod_mbox/incubator-thrift-user/200904.mbox/browser > > > http://mail-archives.apache.org/mod_mbox/incubator-thrift-user/200903.mbox/browser > > > > I've been hearing about this use case a lot lately. We may want to > > consider providing support for it in the core lib . I'd personally be > > happy to see patches towards that once people have an idea of how they > > think it should work. > > We do this now by just passing marshalled structures back and forth > across the wire; it gives us asynchronous send/reply in both > directions. Somewhat simplified, the code looks like the below, it's not > clear exactly what we would include in a patch to thrift since it's built > outside and interacts with the event loop tha twe have. Thanks for the code sample. This method has been suggested a few times, the problem is it only allows async calls. For somethings this is enough for others its not. I would like the flexibility for times when a result would be useful, rather than trying to fudge it with two aysnc calls. I am currently half way through making a new Multiplexed transport. It allows you to wrap any existing Thrift transport with this one. This creates multiple Virtual transports which can be used like any other transport however they don't actually send anything directly. What happens is the Multiplexed transport picks up waiting data from each Virtual Transport and transmits them to the other end. At the other end there is another Multiplexed transport, which splits the data off in to the relevant Virtual Transports which can then be processed as normal. This can happen in both directions, so you may have a server and client connection multiplexed together to have a bidirectional RPC. All this should allow as many single direction connections as you want down the same single TCP connection. The best bit of this is you only need one open socket on the server. Theres no need for the client to be able to accept incoming connections. I will post back when I have something working to share. Charlie M
