Allow socket connect for non-localhost

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start nTorrent and try to Login
2.
3.

What is the expected output? What do you see instead?

Currently it is only possible to choose "LOCAL" for connecting to port
5000. I'd love this feature for every host

What version of the product are you using? On what operating system?
I chnaged the .rtorrent.rc file scgi_port line from localhost:5000 to
:5000. Now rtorrent also waits for incoming connections from other hosts
than localhost.

Please provide any additional information below and if necessary, attach
the nTorrent log file found under $HOME/.ntorrent/.

I am running rtorrent on a headless alix board. As of now, I need to
install at least lighthttpd or have ntorrent running locally. When you add
this enhancement, all I need to install locally is rtorrent. Such an
architecture would be just like I am using it with mpd.

Original issue reported on code.google.com by scritch...@googlemail.com on 9 Nov 2008 at 2:30

[GoogleCodeExporter]

One more (unrelated) issue, since I just read your project plan and i really 
like
ntorernt as it currently is but I fear this might become subject to change:

As for your current project plans, you are writing:

   3. a new slim and fast "nTorrent protocol" to give richer functionality to the end
user whilst still having flexibility.
   5. Enable file- transfer/deletion/execution from nTorrent with ssh, local and the
new nTorrent protocol.
   6. Implement download manager.
   7. A greater level of module based application structure, giving easy flexibility
in what the end user want out of the program, what features to be 
included/excluded.
   8. it's a secret, but the keyword is, JavaFX :) 

All those features add a value which is not really needed. The reason why 
utorrent
for win32 and rtorrent for linux are the most popular clients are their 
simplyness.
Just finish the acces to the rtorrent features and ntorrent will be perfect.
Otherwise you will probably end up just like Azureus/Vuze did and does.

If you want to add those features, please zhink of providing two future 
versions of
ntorrent in future: a basic client as pure standard rtorrent-ui and a client 
which
has the additional features you are currently thinking of.

Keep the good work up!

Original comment by scritch...@googlemail.com on 9 Nov 2008 at 2:59

[GoogleCodeExporter]

I don't see why you can't use the ssh protocol for connection to your box, as 
it is a
much more secure way for connecting. (is however slower as of the encryption
overhead, but that can be changed in sshd_config) The reason i have not yet
implemented a pure socket connection to other hosts is the security issue, as
everyone can talk to the port that is on your network. But ofc, if people want 
this
feature, then i won't stay in the way of that. i will however add a nb about the
security of changing localhost to something else. as of the other features im
planning on implementing, i understand your concerns, and that is exactly why im
trying to split individual areas of the code into plugins, so that the users
themselves can decide what code they want to load into the jvm, and what they 
don't
want. So in effect you can have as minimalistic nTorrent while someone else 
could
have the full bells and whistles.My plan is not to force functionality on you 
that
you dont need, but you will atleast have the option to use it.

Original comment by kei...@gmail.com on 9 Nov 2008 at 10:44

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by kei...@gmail.com on 9 Nov 2008 at 10:44

• Added labels: Milestone-Release0.6

[GoogleCodeExporter]

Well, allowing to connect to port 5000 remotely is even more secure than ssh 
imo. If
I have to use ssh, i have to set AllowTcpForwarding to yes and provide every 
nTorrent
user the login for my torrent user account. For me, this is a much bigger issue 
than
opening a single port on which xmlrpc-c is listening. And finally, Id prefer 
somebody
deleting all my torrents and adding garbage over somebody who uses my system as 
his
dedicated proxy. :)

The perfect solution would be to have some account infos in every rtorrent 
xmlrpc
call, though. But I doubt that this will be added to rtorrent.

Good to hear about the plugin issue.

When can we expect version 0.6?

Original comment by scritch...@googlemail.com on 9 Nov 2008 at 12:20

[GoogleCodeExporter]

i see. this feature will come in the nTorrent protocol, when i have time to get
around too it. im thinking that the protocol will have a separate list of user
account than the linux system, and also maybe even different sets of user 
access.
then this will be assosciated with a rtorrent process. but it entails that you 
will
have to add a "ntorrent protocol server" as a middle man between the socket and
ntorrent. 

as a temprorary workaround i guess you can add some kind of portforwarding so 
that
every request to 127.0.0.1:5000 is rerouted to some.ip:5000. version 0.6 will
probably take some time, as im in a full time job. but i try to take my 
weekends off
to work on nTorrent.

This should be a small thing to implement, but since i decided to rewrite the 
profile
system (due to some nasty bugs), it will probably take some time before i get 
around
to it. and frankly, there are other issues that take precedence.

Original comment by kei...@gmail.com on 9 Nov 2008 at 1:50

[GoogleCodeExporter]

For the workaround: Well, actually I already got it working. Was not that hard 
to
change LocalProfileModel.host and recompile it. =) I just wanted it to become 
part of
the offical future releases. 

I guess i wont even use your protocol server since I have a small fetish on 
keeping
things a simple as possible. The solution I have runnning right now is nearly
perfect. Just waiting eagerly for the peers view plugin.

Original comment by scritch...@googlemail.com on 9 Nov 2008 at 3:15

[GoogleCodeExporter]

Original comment by kei...@gmail.com on 21 Dec 2008 at 1:38

• Changed state: Started

[GoogleCodeExporter]

this is now fixed for the upcoming release.

Original comment by kei...@gmail.com on 21 Mar 2009 at 6:33

• Changed state: Fixed