[
https://issues.apache.org/jira/browse/THRIFT-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882173#action_12882173
]
James E. King, III commented on THRIFT-66:
------------------------------------------
I took a completely different approach to solving this... there is an unused
byte in the VERSION_1 Thrift message header which I designated for a "Channel".
I rewrote the C# runtime and added two-way communication, SSL Support, and
multiple services on a single connection which is binary compatible with older
clients (they can only communication on channel zero, in one direction, just
like a legacy client would..)
When an endpoint initializes it can install protocol handlers on whatever
channel it wants. Each side of the connection is able to implement a protocol
handler, and each side is able to make a client to query the other side. Each
side is also able to process multiple requests in parallel on a single
connection. It is still going through testing, and I would like to refactor
the shutdown logic so that it does not rely on socket exceptions before I post
it though, unless folks would like to get the ball rolling on two-way
communication across all Thrift languages and use this as a template to work
from..
> 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,
> 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.
