On Tue, May 26, 2009 at 9:07 AM, Charles Mason<[email protected]> wrote: > On Mon, May 25, 2009 at 10:45 PM, Chad Walters > <[email protected]> wrote: >> Charlie, >> >> Sounds great. -- looking forward to seeing the patch. >> >> What language are you working in? > > The first version will be in C#. If all goes according to plan I may > need to make a Java port as well. > > I don't know any of the other Thrift languages well enough to make a > port for them. It should be fairly straight forward for anyone to make > a port from the C# version. I am trying to make the code clean and > fairly well commented. I am also trying to use as many of the built in > interfacees as possible, so I am not using the Socket directly but the > TTransport interface. The user can specify which actual transport > implementation they want.
I have now got an implementation of this working in C#. I haven't as yet integrated it in to the Thrift build system, so at present its a set of strand alone Classes which use the standard Thrift library. I would like to eventually to get this into the thrift namespace and build system once its mature enough. I would also like to make a Java port. You can download a sample project and the implementation from the address below. http://www.cpsoftware.com/MultiplexedThriftTest.zip The sample project is an extension of the common time server example you see in several Thrift Tutorials. Basically the client periodically calls a method that returns the servers current tick count every second. In the mean time the server periodically calls a method on all connected clients that provides the current tick count every 5 seconds. Its not exactly exciting but you can clearly see the communication happening in both directions at the same time down a single Thrift socket. I have tried where possible to use the existing Thrift Transports and Servers, however this has caused me some problems. The current version is fairly inefficient using at least 2 extra threads per connection. The big issue with the current Thrift library is you can't tell if there's any data available to read from the socket so you have to blindly read and wait for some data. If the read was none blocking or simply provided the number of bytes currently available I could make it much more efficient. The current system allows up to 255 Virtual single direction connections to be setup inside one Thrift connection. The system assumes both ends know what each connection is uses for. So for instance the server revives RDP calls on Virtual Connection 0 and makes calls on Virtual Connection 1 and the reverse is true for the clients. In theory you could set this up however you want not just like the simple BI directional example above. The actual multiplexing is done by spliting the traffic from each Virtual Connection into frames of upto 256 bytes long. Which are interleaved between each Virtual Connection. This shares the available bandwidth between all the Virtual Connections, so one loaded connection can't block all the others. Let me know what you think. Charlie M
