[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!
Regards.
--
More information about the Mono-devel-list
mailing list