[jira] Updated: (THRIFT-66) Allow multiplexing multiple services over a single TCP connection

["James E. King, III (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James E. King, III updated THRIFT-66:
-------------------------------------

    Attachment: ThriftCSharpEndpointsChannels.zip

This patch zip contains a diff to apply to the trunk as of Sunday August 8 2010.
It contains enhancements for the C# thrift compiler and runtime library.
Normally patches address single issues, however given the content of the change which
encompasses the entire C# runtime, it has to be presented as a single patch.

Bugfixes and Enhancements:

(not in Jira): The library is now compiled for .NET 2.0 by default; moving to v3.5
               does not cause any significant gains and excludes a large class of
               potential implementers still at .NET 2.0.

(not in Jira): The C# runtime was not properly assigning a sequence ID to requests.

(not in Jira): The C# runtime forced exceptions to be created using multiple statements.
               They can now be created on a single code line (for simple types).

(not in Jira): The legacy C# runtime Server code has been refactored and simplified.

(not in Jira): Thrift protocol is unidirectional.  This has changed with the introduction
               of Endpoints.  Using the new Endpoints in C# you can host a service that
               allows each end to register request handlers on different channels (see 
               THRIFT-66).  There is also a new TListeningEndpoint to replace the
               [now] legacy C# Server implementation.  Tests are included.

THRIFT-66:  Allow multiplexing multiple services over a single TCP connection
            This is now possible through Thrift Channels.  Up to 256 Thrift Services 
            can run over a single connection if both sides are channel-aware. Only the
            C# runtime has this feature in this patch.  Compatibility with legacy
            clients is easily maintained by providing for a channel zero implementation 
            of a thrift service.  There is no discovery protocol for this
            mechanism.  Channel IDs are also not expressly put into the Thrift IDL
            to bind a service to just one channel.  This will allow for flexibility 
            in API versioning and various debugging scenarios.  
            Tests are also included.

THRIFT-181: C# SSL Support
            Full SSL support with two-way certificate validation has been added.
            Tests are also included.

THRIFT-509: C# Library Does Not Provide Strong Name
            The runtime and MSVC Single File Code Generators are now strongly named.

THRIFT-740: Visual Studio 2008 .thrift file complete integration
            This patch includes the Microsoft Visual Studio 2008 Single File Code Generator
            patch previously submitted to the project.  The test project depends on it.
            Tests (examples), and a tutorial are included.

To apply this patch, apply the .patch file and then copy the files from lib and test
into the appropriate locations; the patch generator for subverion does not handle binaries.

Jim King
James_E_K@dell.com

> Allow multiplexing multiple services over a single TCP connection
> -----------------------------------------------------------------
>
>                 Key: THRIFT-66
>                 URL: https://issues.apache.org/jira/browse/THRIFT-66
>             Project: Thrift
>          Issue Type: New Feature
>          Components: Library (C#), Library (C++), Library (Cocoa), Library (Erlang), Library (Java), Library (Perl), Library (Python), Library (Ruby)
>            Reporter: Johan Stuyts
>            Priority: Trivial
>         Attachments: CalculatorImpl.java, MultiplexTestClientMain.java, MultiplexTestServerMain.java, SharedImpl.java, Thrift Endpoints and Channels.vsd, ThriftCSharpEndpointsChannels.zip, ThriftMultiplexInvocationHandler.java, TMultiplexServer.java, TMultiplexServer.py, TSimpleMultiplexServer.java
>
>
> The current {{TServer}} implementations expose a single service on a port. If an application has many services many ports have to be opened. This is cumbersome because:
> - you have to document which service is available on which port, and remembering the port numbers is difficult
> - to prevent the overhead of connection setup on each call, a client has to maintain to many connections: at least one to each port
> - it requires opening many ports on a firewall if one is between the client and the server.
> By multiplexing multiple services on a single port the problems above are resolved:
> - instead of a port number a symbolic name can be assigned to a service
> - a client can maintain a small pool of connections to a single port
> - only one port has to be opened on the firewall
> The attached Java implementation simply wraps a normal {{CALL}} message with a (new) {{SERVICE_SELECTION}} message. It is not necessary to modify or wrap the response. No changes are needed to the generated classes. Only a new type of server is introduced, and an invocation handler for a dynamic proxy around the {{Client}} classes of services is provided for the client side. The implementation does not handle communication errors (invalid data, timeouts, etc.) yet.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.