Hello Chamila, Great write up and a wonderful project to take on. This will be a great contribution to Apache Thrift and the community. I have some transport notes put together that I thought might help with your work on the tests in some way.
Best regards, Randy *TTransport* There is a TTransport interface in Apache Thrift, it is a practical interface in some languages and abstract in others. This interface contains essentially the following methods: open/read/write/close/flush. Protocols use this interface to send serialized data to its destination. *Layered Transports* Some transports expose the TTransport interface on one side and consume it on the other. This allows transports to be layered. For example a TCipherTransport can be layered on top of a TFramedTransport. TBinaryProtocol >>> TTransport TCipherTransport >>> TTransport TFramedTransport >>> TTransport TSocket Because layers expose and consume TTransport they can be placed in any order. This means that you can also layer the TFramedTransport on top of the TCipherTransport. This is a very simple and flexible arrangement. For example you could create a TTeeTransport to duplicate the data stream to a socket and a file. *Mutating Transports* Some transports mutate the data stream. The TFramedTransport for example prefixes RPC messages with their size. Other transports do not mutate the data stream. For example the TBufferedTransport simply buffers protocol writes until flush is called to avoid many small writes to the end point. This is important in testing scenarios because non-mutating transports are invisible as far as the data stream goes. For example a server cannot tell if a client is using TBufferedTransport or not because it has no impact on the data stream. It is certainly worth testing non-mutating transport layers but it is useful to think of them as one sided (requiring no peer layer on the other side of the network). *End Point Transports* End Point Transports expose the TTransport interface but do not consume it. Rather they write to a device or some foreign (to Apache Thrift) API. End point transports are available for network, file and memory destinations (e.g. TSimpleFileTransport, TMemoryBuffer and TSocket). From an Apache Thrift I/O stack stand point there must always be precisely one protocol at the top and at least one end point transport at the bottom. There may be, however, many layered transports and branches in between. *Client Server Transports* Client server transports are special case end point transports wherein a server side listens for connections from a client side which connects. TSimpleFileTransport and TMemoryBuffer are not client server transports, though they can be used to communicate over external systems, such as messaging. Client server transports often have a special transport on the server side to perform the listening task. The TServerTransport interface provides an abstraction for this, implementation examples include TServerSocket and TPipeServer. Some end points collapse upper layer behavior into a single transport for convenience using language inheritance rather than transport layering. This is the case with TSSLSocket, an SSL layer over TSocket. *TFramedTransport* The TFramedTransport is probably the most important transport to test. Some of the more scalable servers in various languages (C++ and Java in particular) require frames. This is the only transport I know of that is compulsory, that is to say, clients must support this to communicate with certain servers. *Practical Considerations* Apache Thrift is used the world over in a wide variety of public and private systems. It is hard to know what the landscape looks like from an I/O stack stand point. I would venture to guess that the large majority of I/O stacks are as simple as TSocket with either TBufferedTransport or TFramedTransport as a layer. Some languages have no TBufferedTransport, however. For example Java implements TSocket using the Java OutputStream class which is internally buffered. On Thu, Mar 13, 2014 at 9:47 AM, Chamila Wijayarathna < cdwijayarat...@gmail.com> wrote: > Hi, > My draft project proposal is at > > https://docs.google.com/document/d/1y-fsDGkKsGubLKaN6ilYqwl69eWkORi1aEWOUIraLJE/edit# > . > Please give me your comments on this and if there is anything else to be > added to the project scope. > > Thank You. > > -- > *Chamila Dilshan Wijayarathna,* > SMIEEE, SMIESL, > Undergraduate, > Department of Computer Science and Engineering, > University of Moratuwa. >
