|
First alpha version available: BidirectionalTcpChannel.
This channel aims to solve several problems related to events, callbacks and client-side sponsors when Remoting is used with clients behind NATs or Firewalls. Normally, with the built-in TcpChannel, Remoting tries to open a secondary connection from the server to the client whenever any of these features are used. This is a) necessary due to the TcpChannel's internal mode of operation in terms of "hard" request/response RPC and is b) problematic because normally firewalls or NATs won't allow this secondary connection to be opened.
This BidirectionalTcpChannel works quite differently so that it allows the callback to employ the already exisiting connection which has been established by the client.
This is possible, because the channel internally works in an asynchronous, message oriented fashion so that request and response can share the same connection with a number of different simultanous requests and responses. The same connection will also be re-used for server-to-client callback requests and the client's response.
Disclaimer: Use at your own risk. If you develop a stock brokering application based on this channel and a sudden interuption in service leads to a NASDAQ crash, it's you who's going to talk to the SEC. Keep out of the reach of children. Keep away from fire. May detonate if heated or mixed with water. Store in a cool and dry place. Check the license.
Second disclaimer: Performance will get better with the next release. I'll switch from individual threads to ThreadPool and will change the ITransportHeader serialization format.
|