From: Evan Webb <evan@...>
Date: 2004-01-16T10:16:21+09:00
Subject: Re: drb, firewall, ssh tunneling, and yield

If you extend the normal drb tcp protocol a little bit, you could let it
poke holes in NATs for you. When the client is doing a callback (ie, the
server is sending data in to the client on a new port), just have the
client open a blind tcp connection on that port to the server, that way
the connection tracking will get setup and and the server can connect
back to the client. Or, since the client is doing a connection to the
server anyway to poke the hole, just do the new connection on that
channel. It boils down to only the client create new connections.

Evan

On Thu, 2004-01-15 at 17:07, Nathaniel Talbott wrote:
> On Jan 15, 2004, at 19:49, Joel VanderWerf wrote:
> 
> > Nathaniel Talbott wrote:
> >> Is the client side firewalled also? Basically callbacks work by 
> >> running a DRb server on the client, which the server then connects 
> >> back to. If your client is firewalled, the server won't be able to 
> >> connect to your client.
> >
> > Yes, that's probably it. The client is behind a NAT.
> 
> That'd do it.
> 
> 
> >> DRbFire might interest you:
> >>   http://rubyforge.org/projects/drbfire/
> >> It's still very much in development, but it allows bi-directional 
> >> communication through a firewall. It's more oriented towards 
> >> circumventing client-side firewalls, but in your case I think it 
> >> would work fine if you just forwarded the additional port it needs 
> >> (your normal DRb port + 1).
> >
> > That makes sense. But I haven't got the incantation right. On the 
> > client side, I do:
> 
> Oh, I wasn't very clear. I meant that's what you'd need to do if you 
> were using DRbFire. If you're not, you'd need to specify the url to use 
> on the client side when you do your DRb.start_service:
> 
>      DRb.start_service("druby://localhost:9877")
> 
> Otherwise DRb picks any available port, and specifies your actual 
> hostname (instead of localhost). Once you do that, this incantation...
> 
> > $ ssh -N -L 9876:remote.host:9876 -R 9877:localhost:9877 remote.host
> 
> ...should work.
> 
> 
> > DRbFire sounds great... I'll check it out!
> 
> I'm not sure how much of an advantage it would be in your case, since 
> you're already using SSH tunneling. I wrote it to avoid having to do 
> that myself. It (obviously) can't handle a firewalled server on its 
> own; it would still need the ssh tunnel for that.
> 
> HTH,
> 
> 
> Nathaniel
> 
> <:((><