Hi Randy, Thank you very much for sharing very important information.
On Fri, Mar 14, 2014 at 12:17 AM, Randy Abernethy <randy.aberne...@gmail.com > wrote: > 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. > > > -- *Chamila Dilshan Wijayarathna,* SMIEEE, SMIESL, Undergraduate, Department of Computer Science and Engineering, University of Moratuwa.
