<br><br><div class="gmail_quote">On Wed, Apr 11, 2012 at 05:32, Jason Grout <span dir="ltr">&lt;<a href="mailto:jason-sage@creativetrax.com" target="_blank">jason-sage@creativetrax.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>On 4/10/12 3:53 PM, MinRK wrote:<br>
&gt; I just tried IPC on my latptop, and it definitely does work, though the<br>
&gt; config is a bit weird, due to some assumptions that TCP is what people<br>
&gt; actually use:<br>
&gt;<br>
&gt; $&gt; ipcontroller --transport=ipc --ip=$HOME/ipcluster/socket<br>
&gt;<br>
&gt; will result in a bunch of files called `$HOME/ipcluster/socket:12345`.<br>
<br>
</div>Thanks; I missed the --transport option.  When you say it is a bit<br>
weird, are you just talking about the --ip option?  What if we make --ip<br>
a synonym for --address?  --address seems to be more general (though it<br>
still doesn&#39;t seem to roll off the tongue as well as, say, --basename<br>
and using filenames that were more descriptive when using ipc).<br></blockquote><div><br></div><div>There are just some TCP assumptions - for instance, it is weird to specify `ip` as an arg that is actually a file, and it&#39;s also a bit weird that it creates a series of files with &#39;socket:12345&#39; filenames, due to the ip/port assumptions in the code.  These are really cosmetic issues, of course.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
&gt;   This sets up IPC communication for the cluster.<br>
&gt;<br>
&gt; The only thing I don&#39;t know about is forwarding UDS connections from the<br>
&gt; client to the Hub, but if you know how to do that, you might be set<br>
&gt; (some code would need to change in the ssh forwarding utils, but that<br>
&gt; shouldn&#39;t be much).<br>
<br>
</div>I was thinking that if you had forwarding set up, then you were sshing<br>
into the hub server and then running the client there.</blockquote><div><br></div><div>If you are just going to ssh to the Hub machine and start the client there, then there is nothing to tunnel, and this will just work as it is right now.  I was thinking of using the tunneling we have now to start a Client on a machine remote to the Hub, which requires setting up tunnels.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  Hmmm...it does<br>
seem like an interesting problem to tunnel a UDS connection from the<br>
client machine to the hub machine.  If you do tunnel, then you&#39;re<br>
opening up a tcp port, so the advantages of not having a port open are<br>
out the window, I guess.  So maybe this is just a solution where the<br>
client and hub are all on one computer.  Or, like in our planned case,<br>
we have Google App Engine messages coming in over a App Engine &quot;channel&quot;<br>
to the hub computer, then sent to the hub.<br>
<div><div><br>
Jason<br>
_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org" target="_blank">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br>