[
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_...@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.
