[ 
https://issues.apache.org/jira/browse/THRIFT-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13186516#comment-13186516
 ] 

Nevo Hed commented on THRIFT-66:
--------------------------------

Hi Pedro,

We are doing this by creating a server on each side.  Client established a
''connection'' with a normal RPC call rest of the communication is with
oneway messages ...

The Connect parameters include a address+port for the client to be reached
at.   Typically we do have a set of request+response oneway messages, but
no order or timing is required, so a "Push" works, as long as the client
ensures that the connection is alive from time to time (you can have your
own heartbeat timer).

One key major key to make this work is to do the following when
establishing the connection from the client:
  1) create socket+transport
  2) call transport::open()
  3) call getsockname on the socket's FD
  4) use the local addr returned (sin_addr.s_addr) to construct parameters
the connect-request message.

The server then takes that parameter (addr, port), converts the addr to
string.  This ensures that we keep DNS out of it, and that we talk on the
correct interface for the return traffic (as would happen if thrift would
have supported this natively)




Client                                          Server
  ===========Connect()========>

  <-------------AnyOneWayMessage() ---
  <-------------AnyOneWayMessage() ---
  --------------AnyOneWayMessage() --->
  --------------AnyOneWayMessage() --->
  --------------AnyOneWayMessage() --->
  <-------------AnyOneWayMessage() ---
  --------------AnyOneWayMessage() --->
  <-------------AnyOneWayMessage() ---
  --------------AnyOneWayMessage() --->
  <-------------AnyOneWayMessage() ---


On Sun, Jan 15, 2012 at 7:44 AM, Pedro Algarvio (Commented) (JIRA) <


                
> 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: C# - Library, C++ - Library, Cocoa - Library, Erlang - 
> Library, Java - Library, Perl - Library, Python - Library, Ruby - Library
>            Reporter: Johan Stuyts
>            Priority: Trivial
>         Attachments: CalculatorImpl.java, MultiplexTestClientMain.java, 
> MultiplexTestServerMain.java, ReleaseWaitingReplyThreadsOnDisconnect.patch, 
> SharedImpl.java, TMultiplexServer.java, TMultiplexServer.py, 
> TSimpleMultiplexServer.java, Thrift Endpoints and Channels.vsd, 
> ThriftCSharpEndpointsChannels.zip, ThriftMultiplexInvocationHandler.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.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to