[Mono-dev] Keep-alive connection with Remoting?

Ympostor ympostor at clix.pt
Tue Aug 8 18:12:10 EDT 2006

Brian Crowell wrote:
> Ympostor wrote:
>>> Is there a way to use only a connection (with a somewhat keep-alive 
>>> behaviour) between the client and the server so as to allow to bypass 
>>> any firewalls (that prevent incoming connections, like NAT) that may 
>>> affect the client?
>> http://www.ingorammer.com/Software/OpenSourceRemoting/BiDirTcpChannel.html
> If what you're looking for is bi-directional support over firewalls, you won't 
> have many choices. If you're only looking for uni-directional support, the fact 
> that remoting closes the connection every now and then won't hurt you.
> Bi-directional support in remoting can be tricky, *especially* if you're behind 
> a NAT. Remember that every marshalled object has a URI that allows the remoting 
> framework to find its way to it. Anything that would allow bi-directional 
> remoting has to account for the fact that you can't use the hostname on return.

Yes, that's why I was asking for some configuration parameter or 
something to modify this behaviour... :(

> If you're willing to step up the game a bit, though, it's possible to hijack the 
> remoting pipeline right at the end, where it would try to find your client based 
> on its URL and send a message across to it. You'd be creating an IChannelSender 
> and an IChannelReceiver pair, with maybe one or two other supporting classes.

Are you referring to any of the tecniques that are being used by the 
solutions that Robert and I have mentioned?

> But, of course, that's a tad advanced. Alternative, simpler methods exist 
> outside of remoting, such as just creating your own 
> System.Net.Sockets.NetworkStream and piping your data across it.

I don't want to deal with Sockets. I am trying to use Remoting so as to 
avoid the implementation of the network bits :-/

> So... I'd say no, there's no simple way to do it, not without finding an 
> already-made product, and I don't know of any.

Thanks for the info Brian!



More information about the Mono-devel-list mailing list