File Transfer Daemon

bjorn · Post by **bjorn** » 03 Jan 2007, 09:13

Hi all!

I've recently played around with bubba-server a bit, and i am curious about the workings of the FTD for bittorrent transfers, it seems that it's using ports TCP/1024 to TCP/5000 (rough estimate from my side...) But i have yet t o find a configuration file where to set options for ports, is there any at all or do i need to set them at compile-time for the ftd?

In the later case, where could i find sources (if available)?

/Bjorn

Post by **tor** » 03 Jan 2007, 14:19

Hi Bjorn,

The Bittorrent part of the FileTransferDaemon, ftd, is built upon libtorrent. The ports you observe is, most likely, the local port numbers used for connections. These are atm not configurable in libtorrent.

What could be configurable but is not at the moment is the ports which ftd listens on. Today these are hard coded to be in the interval 10000-14000 including port 14000.

Regarding source code. Ftd is atm closed source developed in house by Excito. But that said, if enough interest should arise, we are not foreign to the thought on opening it.

jamerson · Post by **jamerson** » 23 Feb 2007, 03:01

Does this mean that ports 10000 to 14000 should be forwarded to get the most out of torrent downloads? Or am I not getting this right...

/pelle

bjorn · Post by **bjorn** » 25 Feb 2007, 10:28

Hi again excito crew!

I'm interested in the FTD-sources, would you consider publishing them?

/Bjorn

Post by **tor** » 25 Feb 2007, 17:22

Hi bjorn,

As said before atm ftd is our closed source. But we are not foreign to the idea to open source it. This however is something we will have to think deeper about and i can't make any promises right now.

But if you want to discuss this further or have any ideas. Don't hesitate to contact us, we are always interested in possible cooperation.

/Tor

bjorn · Post by **bjorn** » 25 Feb 2007, 18:09

Yes, i understand your position.

Perhaps i should have clarified my post a bit, you said earlier:

But that said, if enough interest should arise, we are not foreign to the thought on opening it.

Consider this to be one point of interest from me, and when you feel that you've collected "enough" to open up the sources, let me know. I'm not in a hurry

Best Regards
/Bjorn

TheEagleCD · Post by **TheEagleCD** » 28 Feb 2007, 11:42

Which options and arguments does ftd or rather its bittorrent portion support?

More specifically what I'm currently trying to work out how I can add an option on where I want to save the file that I'm downloading. While the standard "download" directory is a no-brainer I would like to select different directories depending on what I download (e.g. I want a dir for all my crankygeeks and dl.tv episodes).

According to the [url=file:///C:/Dokumente%20und%20Einstellungen/Christoph/Desktop/Temporary%20Files/libtorrent-0.11/libtorrent-0.11/docs/manual.html#add-torrent]libtorrent API[/url] the "add_download" method also allows for a "save_path" variable to be specified.

From my first glance at the downloads.php file it looks as though I'll probably have to add that save_path value somewhere in this code-segment:

Code: Select all

if($add_download=='Add'){
         $url=$_POST['url'];
         $uuid=$_POST['uuid'];
         if(trim($url)!=""){
            $dl->add_download($_SESSION["user"],$url,$uuid);
         }

Assuming that I'm on the right path I'm thinking that apart from adding

Code: Select all

$path=$_POST['path'];

I'd somehow have to add that "$path" to the add_download(...) call, unfortunately I've got no idea where to add it exactly.

Anyway, I'd appreciate any pointers or advice.

Cheers,
Christoph

Post by **tor** » 28 Feb 2007, 17:37

Hi TheEagleCD,

Cool that you are interested in comunication with the ftd. We will of course try to answer any questions about it as good as possible.

Unfortunately there is no way today to add a path to the add_download command. The daemon does not support it today.

That said, it is of course posible to add this functionality to the daemon. And we have of course thouhgt about it and in the long term we will try to support it.

The problem is that it adds quite a lot of extra work to implement it. It is not as easy as just add a path argument to the add_download.

You would have to do some heavy validation of that path. To make sure it fx didnt conflict with another download. A sure way to crash the ftd download application today.

What we of course will do in a much shorter timeframe hopefully to the next update. Is to provide the means for an easy to use function to move files and directories around with the web-based filemanager. Hopefully that will work as a replacement until we get around to make the download manager more flexible.

/Tor

TheEagleCD · Post by **TheEagleCD** » 28 Feb 2007, 19:00

tor wrote:Unfortunately there is no way today to add a path to the add_download command. The daemon does not support it today.

That said, it is of course posible to add this functionality to the daemon. And we have of course thouhgt about it and in the long term we will try to support it.

The problem is that it adds quite a lot of extra work to implement it. It is not as easy as just add a path argument to the add_download.

You would have to do some heavy validation of that path. To make sure it fx didnt conflict with another download. A sure way to crash the ftd download application today.

If ftd doesn't support this functionality at the moment than that obviously makes things significantly more difficult than I had initially figured.

Anyway, I just had a look at the libtorrent / rtorrent website and while browsing the rtorrent man-pages I stumbled across the "-d directory" option (Set the default download directory. Defaults to "./"). So I'm thinking that a possbility for now would be to integrate that option into ftd. That would give users at least a very basic option on where they want to save their files while probably not being all that painful to implement for you guys. Anyway, just a thought...

What we of course will do in a much shorter timeframe hopefully to the next update. Is to provide the means for an easy to use function to move files and directories around with the web-based filemanager. Hopefully that will work as a replacement until we get around to make the download manager more flexible.

Yeah, that's probably the best workaround for the moment being.

Just out of curiosity, why did you decide to go for an integrated custom solution by writing ftd? I'm assuming that having a single tool handle all the downloads makes it easier to integrate it into the rest of the software environment. Plus you can probably do some neat optimizations for the hardware platform you're using.

Thanks,
Christoph

Post by **tor** » 01 Mar 2007, 04:02

Hi TheEagleCD,

A way to change the default download directory is a nice feature that should be a bit easier to implement. Consider it added on the wanted feature list.

And then why we built an integrated solution for downloads. You are right in that it saves us from a lot of duplicate code or rather resource usage of that. As it is for now we use the same infrastructure for all downloads, torrents, http, ftp etc and we also use the ftd for upload now.

The problem with having it all integrated is that it makes it a little harder for us to support features that only exist for one target. And that is the main reason for the torrent downloader, at least right now, to be somewhat simplistic.

/Tor

Maarten · Post by **Maarten** » 10 Mar 2007, 17:26

I'm loving Bubba as well, and think Excito has done a great job in creating such a sleek machine. I am also interested in ftd, simply because I need to be able to control my bandwith (upload) a bit better than is currently possible, i.e., be able to throttle it. Linux/libtorrent provides such functionality, and it shouldn't be too hard to implement it myself (possibly via creating an /etc/ftd.conf file). IF i would be able to get my hands on the source...

Now for devil's advocate

Regarding source code. Ftd is atm closed source developed in house by Excito. But that said, if enough interest should arise, we are not foreign to the thought on opening it.

It's great to hear that you're not foreign to the thought of opening it and bears witness to your willingness to help out your customers, but given the license requirements of libtorrent itself (which ftd links to and which is GPL licensed), I'm pretty sure that you are already required to open it up if anyone asks for it. in effect, when bjorn asked for the source, you are quite probably required to provide it. And please do, I could use it as well

I'm not going to make a big stink out of this (though I would still like to get my hands on the source), because my need for this is not too great, and I like your product too much to put you through such hassle. I did think to speak up to make you aware that there are strings attached to using GPL libraries, and you might need to discuss internally about a policy to deal with such requests.

Unless of course I am greatly mistaken, and you made a separate licensing deal with the libtorrent developer(s).

In any case, keep up the good work, and hope to see many good things come out of your company.

-Maarten-

lelle · Post by **lelle** » 10 Mar 2007, 19:58

As far as I know, the GPL license states that any modification to the licensed code itself (the libtorrent library in this case), must be made public, not the source code of the application using the library.

Maarten · Post by **Maarten** » 11 Mar 2007, 03:24

The above would apply to the LGPL (the 'Library' or 'Lesser' GPL license). The GPL is pretty clear about the subject: also linking, either dynamically or statically, does not make your code free from the effects of the GPL.

-Maarten-

Ubi · Post by **Ubi** » 30 Jul 2007, 15:37

I had a look at this:

FTD seems to link against, at least, the following libs:
libc.so.6
libcrypto.so.0.9.7
libcurl.so.3
libdl.so.2
libgcc_s.so.1
libglib-2.0.so.0
libidn.so.11
libm.so.6
libpopt.so.0
libpthread.so.0
libsigc-2.0.so.0
libssl.so.0.9.7
libstdc++.so.5
libtorrent.so.10
libz.so.1

Many, if not all of these are GPL-licensed modules. Some of these are OK (such as using GCC to compile proprietary software)

The GPL says this http://www.gnu.org/licenses/gpl-faq.html:

1) Linking {closed source package} statically or dynamically with other modules is making a combined work based on {closed source package}. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

and
2) Q: If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL?
Yes, because the program as it is actually run includes the library.

The FSF says something similar: http://www.fsf.org/licensing/licenses/g ... tarySystem

In short, it seems that FTD is indeed in violation of GPL2 and liable to copyright claims. This is a serious problem. Companies like SiteCom (who used netfilter) were sued and lost in court over a comparable violation. Similar stories can be told for TomTom and KISS.

Apart from the legal argument, I see no downside to opening FTD. Many of the users are hackers which will improve your software for free. Excito, like Sun for example, is a hardware company. Unless the inner workings of FTD are a givaway to competitors Excito can only benefit from open software.

On the other hand, maybe I'm completely mis-interpreting the GPL as well as the inner workings of FTD. So hopefully I'm wrong. But it'd be a shame for a great company like Excito to be bogged down in lawsuits over something like this.

Ubi

Post by **tor** » 02 Aug 2007, 17:25

Regarding ftd and GPL.

We are very much aware of the violation in respect of libtorrent. And as said before, we are a very pro open-source company, and we have planned a release of the code for the ftd.

The delay is mostly due to us needing to clean things up a bit, mostly regarding the build, and add headers and such to our source files. After that lets hope we can gather some development comunity around it

/Tor