userland features wishlist
Yassen Roussev
Alessandro Calorì
4. DHT and PeX
5. better IPC protocol to make the daemon share more information about
torrents (mostly peers and trackers)
Moreover encryption would require the use of secure sockets so we
should choose the library to use: OpenSSL or GnuTLS.
2010/7/30 Yassen Roussev <goat...@gmail.com>:
Lars Nooden
> Moreover encryption would require the use of secure sockets so we
> should choose the library to use: OpenSSL or GnuTLS.
What's wrong with tunneling over SSL/TLS or SSH?
The keys or certificates need to be pre-loaded, but that should be done
anyway to avoid eavesdropping.
/Lars
Yassen Roussev
Julien Laffaye
> Moreover encryption would require the use of secure sockets so we
> should choose the library to use: OpenSSL or GnuTLS.
Doesn't btpd already require OpenSSL as stated on the (old) website?
Regards,
Julien
Lars Nooden
6. A read-only mode, where data being seeded is in a read-only file,
directory, file system or medium. That would mean that the metadata
would have to be stored in a different directory from the torrent.
/Lars
Alessandro Calorì
> What's wrong with tunneling over SSL/TLS or SSH?
> The keys or certificates need to be pre-loaded, but that should be done
> anyway to avoid eavesdropping.
Nothing's wrong... it's just brainstorming... ;)
2010/7/30 Julien Laffaye <kim...@gmail.com>:
> Doesn't btpd already require OpenSSL as stated on the (old) website?
You're right but I don't remember what it is used for: maybe for the
connection with trackers which announce on HTTPS. I'm gonna take a
quick look at the code...
Bye,
Alessandro.
Marq Schneider
> 2010/7/30 Julien Laffaye <kim...@gmail.com>:
>> Doesn't btpd already require OpenSSL as stated on the (old) website?
>
> You're right but I don't remember what it is used for: maybe for the
> connection with trackers which announce on HTTPS. I'm gonna take a
> quick look at the code...
HTTPS isn't supported (yet). OpenSSL is used for the libcrypto to
implement the SHA-1 cryptographic hash function.
-Marq
Alessandro Calorì
> HTTPS isn't supported (yet). OpenSSL is used for the libcrypto to
> implement the SHA-1 cryptographic hash function.
Ah yes, thank you. We should use OpenSSL for encrypted peer and
tracker connections also.
> -Marq
Bye,
Alessandro
Marq Schneider
what all these features mean so I can better evaluate the request.
Below are my current thoughts:
> 1. encryption
I would like to see this in future versions of btpd too. From what it
looks like, the method used most commonly is MSE/PE (Message Stream
Encryption/Protocol Encryption) which seems to be some custom method
utilizing RC4. It also appears that OpenSSL's libcrypto also supports
RC4, so it might not take significant effort to add this in. I still
need to dive further into it to really be able to tell. Added to
issues list [0].
> 2. option for btpd to stop automatically if previously available seeds
> (100%) become unavailable, due to storage problems etc, rather than
> initiate download from tracker
By this, do you mean torrents you are currently seeding and have 100%
and you yank the storage device they are stored on? I don't really
see this as necessary, but would welcome more comments on use cases
for this.
> 3. support for multiple storage directories. (apologies if I haven't done
> enough of RTFM and this is already supported) Symlinks can do it, but
> can become a bit too much, so if btpd supported this it it would be amazing.
Have you looked at the "-d" option for "btcli add"? See btcli --help
and let me know if that's what you are looking for. If not, please
clarify this request.
> 4.a. DHT
Agreed. DHT seems to be supported by any modern bittorrent client
since it is an official extension. Added to issues list [1].
> 4.b. PeX
Similar story with PEX here. However, PEX has two different
implementations: AZMP and LTEP. Does anyone have any experience with
either of these? Added to issues list [2].
> 5. better IPC protocol to make the daemon share more information
> about torrents (mostly peers and trackers)
This could be handy if showing more info for in user interface. Can
you give more specific examples on the kind of info you'd want to see?
We still need to have a separate discussion for IPC and libbtpdclient
API. I need to give this some more careful thought.
> 6. A read-only mode, where data being seeded is in a read-only file,
> directory, file system or medium. That would mean that the metadata
> would have to be stored in a different directory from the torrent.
I can see a use case for this. Added to issues list [3].
[0] http://github.com/btpd/btpd/issues/issue/20
[1] http://github.com/btpd/btpd/issues/issue/21
[2] http://github.com/btpd/btpd/issues/issue/22
[3] http://github.com/btpd/btpd/issues/issue/23
-Marq
Cedric Tefft
> 2. option for btpd to stop automatically if previously available seeds
> (100%) become unavailable, due to storage problems etc, rather than
> initiate download from tracker
By this, do you mean torrents you are currently seeding and have 100%
and you yank the storage device they are stored on? I don't really
see this as necessary, but would welcome more comments on use cases
for this.
I don't have a need for this myself, but I could maybe see if the btpd download directory is on an external drive (NFS, USB, etc.) that falls down, you wouldn't want it trying to download the whole torrent and storing it on the the local drive where the external drive used to be mounted -- particularly if you are the original content provider. Just speculatn'.
Hopefully the person who requested this feature will chime in.
Alessandro Calorì
>> 5. better IPC protocol to make the daemon share more information
>> about torrents (mostly peers and trackers)
> This could be handy if showing more info for in user interface. Can
> you give more specific examples on the kind of info you'd want to see?
1. Better error messages: right now they are written to the log file
and the torrent is flagged as erroneous. It would be useful to pass a
string or a code which identifies the error.
2. Trackers information: tracker URL or a list of URL (for
multitracker torrents), swarm informations (scrape).
3. Peers information: IP addresses, available data (%), received and sent data.
IMHO those three are important information to share with the clients,
not only for viewing them but also for future implementation of other
features (i.e. manual IP ban).
> We still need to have a separate discussion for IPC and libbtpdclient
> API. I need to give this some more careful thought.
The client's shared library is a good idea: I had to implement a
static one for gbtpd. The API should follow the complete specs of the
application protocol otherwise we are going to break API among
versions for sure. For the new IPC I would strongly suggest to use
XMLRPC: XML is standard and eXtensible so we can add data without
risking to break compatibility.
>
> -Marq
>
Bye,
Alessandro.
Yassen Roussev
> 2. option for btpd to stop automatically if previously available seeds
> (100%) become unavailable, due to storage problems etc, rather than
> initiate download from tracker
By this, do you mean torrents you are currently seeding and have 100%
and you yank the storage device they are stored on? I don't really
see this as necessary, but would welcome more comments on use cases
for this.
Yes, you have interpreted my comments correct. It makes sense for btpd to stop seeded torrents whose storage directory disappears than starting leeching them from the tracker i.e after a check will prove that all or some parts are missing, btpd will attempt leeching the torrent.
> 3. support for multiple storage directories. (apologies if I haven't done
> enough of RTFM and this is already supported) Symlinks can do it, but
> can become a bit too much, so if btpd supported this it it would be amazing.Have you looked at the "-d" option for "btcli add"? See btcli --help
and let me know if that's what you are looking for. If not, please
clarify this request.
I think this already does what I was requesting...
Alessandro Calorì
> Yes, you have interpreted my comments correct. It makes sense for btpd to
> stop seeded torrents whose storage directory disappears than starting
> leeching them from the tracker i.e after a check will prove that all or some
> parts are missing, btpd will attempt leeching the torrent.
For this to be implemented would be necessary to store the status of
the torrents (i.e. downloaded bytes or packets). It would be a nice
feature.
Bye,
Alessandro.