[
https://issues.apache.org/jira/browse/THRIFT-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12882396#action_12882396
]
James E. King, III commented on THRIFT-66:
------------------------------------------
I also wanted to explitly avoid having service discovery as part of the
protocol, although there is nothing preventing someone from adding their own
extension that does this. Originally I had made it so that the channel was
part of the service declaration, i.e.:
service Rand channel 5
{
...
}
However that was met with some opposition. So now the channel identifier is
declared in code when starting up an endpoint. As long as both sides have some
innate knowledge of what runs on a given channel, it should be okay. This just
leaves the channel namespace up to the host application. I will attach my
Visio diageam of endpoints and channels.
> 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.
