libbt-devel — C Library for Bittorrent Developers

Re: [Libbt-devel] libbt proposed changes

[Peter S. <stu...@cd...>]

On Wed, Feb 09, 2005 at 01:37:14PM +0100, Alien wrote:
> > > > Sort of like what libcurl does for HTTP and FTP transports.
> > > 
> > > don't go there...
> >
> > Why not?
> 
> no point in reinventing the wheel

Ah, about giFT. All right, well, I will look into giFT some more, but
I'm still not convinced I can fit BT into there and get what I want.

But I was thinking about the libbt API here. My point was that libbt
should allow for fine-grained control for applications that want it,
but have good defaults so applications that don't need control can
just fire up a download with a few calls. curl is pretty well
designed in this area; I've only used it from PHP so far, but I
assume the PHP API reflects the C API, possibly minus some
allocations/frees.


> > The problem is that the BitTorrent paradigm doesn't fit at all
> > well into giFT. :(
> 
> yes, but then i'm quite sure that if there were soem necessary
> changes, that giFT would be willing to accomodate.

That's an excellent point. :)


> > I'm not sure about the giFT internals, but I do know that there
> > is virtually zero way to control protocol low-level parameters at
> > least from the giFTcurs client.
> 
> there is a per backend config file which can be used for it.

Yeah, but no runtime changing. But..


> well actually, in most cases, the daemonized system of gift runs
> chrooted as another user; ideally, the regular user does not have
> any access to that system

Does in my environment. But..


> you should make a wrapper script/program to accomplish this (in
> another project), that'll ideally get the functionality some people
> want and not lose the safeness of most deamonized systems, anyway,
> this is not the place to discuss it, direct your mails to gift.

..that's all off the libbt topic. I'll shut up about that so we can
stick to libbt here. Thanks for straightening me out here! :)


//Peter

[Libbt-devel] role of libevent

[Emil S. <si...@MI...>]

On Wed, 09 February 2005 at 17:23 (-0800), Elliott Mitchell wrote:
> associated system calls. glib provides similar services, though through a
> poll() centric interface rather than libevent's select() centric
> interface.

libevent is not select()-centric: it provides a single API
to /dev/poll, kqueue(2), select(2), poll(2) and epoll(4).
See http://www.monkey.org/~provos/libevent/. 

The point of introducing libevent was to cleanly handle 
asynchronous I/O.  It frees libbt from the details of
different async I/O interfaces.  I'm curious what Alien
means by the "removal of event".

Re: [Libbt-devel] second grouping complete

[Peter S. <stu...@cd...>]

(Again, please use list-reply in your mail client so it doesn't CC
me, I'm on the list. Thanks! :)

On Wed, Feb 09, 2005 at 05:23:33PM -0800, Elliott Mitchell wrote:
> >From: Peter Stuge <stu...@cd...>
> > 
> > Can someone clarify what, exactly, libevent is used for?
> 
> I/O handling. Helps handling of all the streams, timers and the
> associated system calls. glib provides similar services, though
> through a poll() centric interface rather than libevent's select()
> centric interface.

I was hoping for more specific details, but I do of course have the
source. :) Anyway, a quick grep;

stuge@carepad4 ~/lb/libbt $ grep -cr event src | (IFS=':'; while read
f n; do test $n -gt 0 && echo $n $f; done) | sort -n
1 src/Makefile
1 src/Makefile.am
1 src/Makefile.in
1 src/TODO
2 src/btcheck.c
2 src/protocol.c
9 src/context.c
10 src/btget.c
13 src/torrent.c
15 src/peer.c
16 src/fetchurl.c
stuge@carepad4 ~/lb/libbt $ 

I say we just roll our own small set of functions for these tasks,
event isn't very heavily used and IMHO it's really worth small effort
or duplication to remove a dependance.


//Peter

Re: [Libbt-devel] second grouping complete

[Elliott M. <eh...@m5...>]

>From: Peter Stuge <stu...@cd...>
> On Wed, Feb 09, 2005 at 11:53:55PM +0100, Alien wrote:
> > next stop: IPv6 fixes, followed by trying to make a seperate module
> > bttools, which will have the btget, btcheck and btlist executables;
> > also the samples and documentation will have their own modules;
> > followed by trying to make define a good API for the library; then
> > probably removal of event; and then removal of btget, btcheck and
> > btlist from the libbt module. that should be celebrated by release
> > 1.1.0 . then protocol2 together with maybe ctorrent devel to a good
> > cursed and non-cursed frontend of libbt. with the end of all libbt
> > protocols comes 2.0.0. the end.
> 
> Great roadmap! Put it on the web. :)
> 
> Can someone clarify what, exactly, libevent is used for?

I/O handling. Helps handling of all the streams, timers and the
associated system calls. glib provides similar services, though through a
poll() centric interface rather than libevent's select() centric
interface.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \   (    |         EH...@gr... PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/

Re: [Libbt-devel] second grouping complete

[Peter S. <stu...@cd...>]

On Wed, Feb 09, 2005 at 11:53:55PM +0100, Alien wrote:
> next stop: IPv6 fixes, followed by trying to make a seperate module
> bttools, which will have the btget, btcheck and btlist executables;
> also the samples and documentation will have their own modules;
> followed by trying to make define a good API for the library; then
> probably removal of event; and then removal of btget, btcheck and
> btlist from the libbt module. that should be celebrated by release
> 1.1.0 . then protocol2 together with maybe ctorrent devel to a good
> cursed and non-cursed frontend of libbt. with the end of all libbt
> protocols comes 2.0.0. the end.

Great roadmap! Put it on the web. :)

Can someone clarify what, exactly, libevent is used for?


//Peter

Re: [Libbt-devel] first group of changes complete

[Peter S. <stu...@cd...>]

On Wed, Feb 09, 2005 at 02:56:11PM +0100, Alien wrote:
> using ./autogen.sh ), that way, any unnecessary double files will
> be gone, and some chances of mistake with it.

I like it.


> however: anyone is encouraged to try it out and build from CVS
> (maybe on a fresh checkout), if anything doesn't work, please
> notify me (preferably with info) (I can't check all possible
> setups).

Didn't work too well here..

stuge@carepad4 ~/lb/libbt $ sh autogen.sh 
warning: `configure.ac' and `configure.in' both present.
 at /usr/bin/aclocal-1.7 line 59
warning: proceeding with `configure.ac'.
 at /usr/bin/aclocal-1.7 line 59
autoheader-2.59: `configure.ac' and `configure.in' both present.
autoheader-2.59: proceeding with `configure.ac'.
*** autoheader FAILED
stuge@carepad4 ~/lb/libbt $ 

When I change autogen.sh to explicitly use autoheader-2.13 it builds
configure fine but halts since I don't have libevent.

I'm afraid I don't know much about autotools, so please tell me what
else you need to know to handle the 2.59 problem.


//Peter

Re: [Libbt-devel] libbt proposed changes

[Elliott M. <eh...@m5...>]

>From: Alien <ali...@us...>
> Op dinsdag 8 februari 2005 23:37, schreef Elliott Mitchell:
> > >From: Alien <ali...@us...>
> > > forgot to mention that the following requirements will be placed upon the
> > > developpers:
> > >
> > > automake-1.6
> >
> > Looking at Debian, as they tend to be the farthest behind of the Linux
> > distributions. Stable ships automake 1.4 as the "automake" package, but
> > has 1.5 available as "automake1.5" (guess which folks are likely to have
> > handy). This suggests to me that 1.4 is a better baseline.
> 
> My idea is that not alot of people use CVS, just a few developpers and that 
> this dependancy is only on those people. I feel bad for debian people, but I 
> know that lots of automake files have totally different macro's with 1.4 and 
> this may prove hard to support. nevertheless, if someone were to be able to 
> make this work with 1.4, i'm willing to have autogen.sh have an option (or 
> detection) of no other version than 1.4 and handle it differently, however, i 
> cannot spend my time on this.

As a result you'll piss off a significant number of folks. Looked like
the existing work didn't work with 1.4 anyway so this could be moot. I'm
not saying it shouldn't be done, just that it needs to be considered.

> > > btw: some time later, i'd like to remove this event dependency
> >
> > It is unfinished and completely untested (beyond -Wall), but the
> > events-glib was an attempt to use glib instead. This seemed a good choice
> > as GTK and therefore GNOME depends upon glib and as a result it is likely
> > to be present on most systems.
> 
> I'm not sure that backend tools should be dependant upon frontend-like 
> libraries like GTK and GNOME, i'm never much on dependancies unless most 
> distro's ship it or it already is installed, if it's a usefull dependancy I 
> can change my mind, however, it seemed to me that this event was not 
> installed on my system, and uuid isn't even available. but, these are not my 
> primary concerns at the moment.

GNOME depends on GTK which depends on glib. glib is a backend library
used by GTK. Seeing how GTK installation is very common if not universal
(noting Knoppix and SuSE), depending on glib is not a major burden. By
comparison I'd never heard of libevent prior to encountering libbt. It
seems likely that the glib/libevent switch can be made runtime, and if so
a zillion other libraries could work. The issue is simply which I/O
interface to use?

> I'm negotiating with the maintainer of ctorrent, so that I might change that 
> project so it'd use libbt, possibly if he has code to handle bittorrent 
> stuff, that i put it in here as well.

The other thing is to steal any useful ideas from it.

> In that perspective: the library should be able to be used by any kind of 
> frontend, if it cannot, then all efforts to build a library are in vain. 
> Especially if a command-line frontend wants to use it, you can understand it 
> cannot depend on stuff like libevent, since text-only distro's will probably 
> not ship it.

I agree. The problem with libevent is its rarity. Text-only distributions
can use libevent, just they choose not to because few things require it.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \   (    |         EH...@gr... PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/

[Libbt-devel] second grouping complete

[Alien <ali...@us...>]

i couldn't wait any longer, now that i have the time, i finished the CVS HE=
AD=20
transition and deleted redundant files.

next stop: IPv6 fixes, followed by trying to make a seperate module bttools=
,=20
which will have the btget, btcheck and btlist executables; also the samples=
=20
and documentation will have their own modules; followed by trying to make=20
define a good API for the library; then probably removal of event; and then=
=20
removal of btget, btcheck and btlist from the libbt module. that should be=
=20
celebrated by release 1.1.0 . then protocol2 together with maybe ctorrent=20
devel to a good cursed and non-cursed frontend of libbt. with the end of al=
l=20
libbt protocols comes 2.0.0. the end.
=2D-=20
Alien is my name and head-biting is my game.

[Libbt-devel] first group of changes complete

[Alien <ali...@us...>]

ok, the first part is complete: transition to automake

at this time: NO FILES HAVE been deleted from CVS

I had to add some files to make it automake --gnu standard compliant, eg:=20
NEWS, AUTHORS, ChangeLog

i also fixed some 64bit necessary changes

I added the automake toplevel files: Makefile.am

also the configure.ac was added, together with m4 files that have split up=
=20
from he configure.in file and the aclocal.m4 file.

i added the script to build from CVS: autogen.sh

NOTE: if you do NOT execute ./autogen.sh, you probably are still able to do=
=20
everything the old way, the next changes will make that impossible.

lots of warnings are still there because of double files, but i did not del=
ete=20
the double files YET.

lots of files in CVS will be overwritten by executing ./autogen.sh (which i=
s=20
why i intend to delete all those files (that can be generated=20
using ./autogen.sh ), that way, any unnecessary double files will be gone,=
=20
and some chances of mistake with it.

however: anyone is encouraged to try it out and build from CVS (maybe on a=
=20
fresh checkout), if anything doesn't work, please notify me (preferably wit=
h=20
info) (I can't check all possible setups).

have fun
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] libbt proposed changes

[Alien <ali...@us...>]

Op woensdag 9 februari 2005 13:10, schreef Peter Stuge:
> (Please don't CC me, just send to the list, I only need one copy of
> the messages. Thanks! :)
>
> On Wed, Feb 09, 2005 at 12:53:39PM +0100, Alien wrote:
> > I received one mail from him a few days ago, but he didn't respond
> > to my other questions or other mails, i sent him a mail in which i
> > give him 2 weeks to respond, or else i'm requesting project
> > takeover to SF.
>
> My mail to him bounced. :\
>
> > > Sounds good. My last mail sort of probed for how much control I
> > > would have of low-level things inside libbt if I were to use it,
> > > but I guess libbt isn't quite there yet for me to use.. Or?
> >
> > ksmathers said that it's not quite there yet, but i plan to do it.
>
> Cool! :)
>
> > > The ideal thing would be if libbt abstracted away everything
> > > BitTorrent and simply provided an interface for the application to
> > > optionally control as many parameters as possible. Sort of like
> > > what libcurl does for HTTP and FTP transports.
> >
> > don't go there...
>
> Why not?

no point in reinventing the wheel

> > there are other things like that, like for example giFT. if you
> > really wish something like that, please, make a giFT plugin for it
> > instead, i know I would appreciate that.
>
> The problem is that the BitTorrent paradigm doesn't fit at all well
> into giFT. :(

yes, but then i'm quite sure that if there were soem necessary changes, tha=
t=20
giFT would be willing to accomodate.

> I'm not sure about the giFT internals, but I do know that there is
> virtually zero way to control protocol low-level parameters at least
> from the giFTcurs client.

there is a per backend config file which can be used for it.

> > (i saw in your mail that you wished to start the backend when
> > starting the frontend, etc... but that's really none of it's
> > business, if you really want that, you can make a simple wrapper
> > script that actually does that.)
>
> Or I'll just make it a setting. No big deal. I see no reason not to
> do it, when it can be done well. Of course you'll be able to use the
> backend stand-alone too, but I would not want that to be the default.
> There's just no point in starting the frontend without having the
> backend running. Having them come up together will allow easier
> connection in web browsers too, which is important since that's
> explicitly one part of BitTorrent's high usability.

well actually, in most cases, the daemonized system of gift runs chrooted a=
s=20
another user; ideally, the regular user does not have any access to that=20
system

you should make a wrapper script/program to accomplish this (in another=20
project), that'll ideally get the functionality some people want and not lo=
se=20
the safeness of most deamonized systems, anyway, this is not the place to=20
discuss it, direct your mails to gift.

> Glad we've got some thoughts going! :)

that's the idea
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] libbt proposed changes

[Peter S. <stu...@cd...>]

(Please don't CC me, just send to the list, I only need one copy of
the messages. Thanks! :)


On Wed, Feb 09, 2005 at 12:53:39PM +0100, Alien wrote:
> I received one mail from him a few days ago, but he didn't respond
> to my other questions or other mails, i sent him a mail in which i
> give him 2 weeks to respond, or else i'm requesting project
> takeover to SF.

My mail to him bounced. :\


> > Sounds good. My last mail sort of probed for how much control I
> > would have of low-level things inside libbt if I were to use it,
> > but I guess libbt isn't quite there yet for me to use.. Or?
> 
> ksmathers said that it's not quite there yet, but i plan to do it.

Cool! :)


> > The ideal thing would be if libbt abstracted away everything
> > BitTorrent and simply provided an interface for the application to
> > optionally control as many parameters as possible. Sort of like
> > what libcurl does for HTTP and FTP transports.
> 
> don't go there...

Why not?


> there are other things like that, like for example giFT. if you
> really wish something like that, please, make a giFT plugin for it
> instead, i know I would appreciate that.

The problem is that the BitTorrent paradigm doesn't fit at all well
into giFT. :(

I'm not sure about the giFT internals, but I do know that there is
virtually zero way to control protocol low-level parameters at least
from the giFTcurs client.


> (i saw in your mail that you wished to start the backend when
> starting the frontend, etc... but that's really none of it's 
> business, if you really want that, you can make a simple wrapper
> script that actually does that.)

Or I'll just make it a setting. No big deal. I see no reason not to
do it, when it can be done well. Of course you'll be able to use the
backend stand-alone too, but I would not want that to be the default.
There's just no point in starting the frontend without having the
backend running. Having them come up together will allow easier
connection in web browsers too, which is important since that's
explicitly one part of BitTorrent's high usability.

Glad we've got some thoughts going! :)


//Peter

Re: [Libbt-devel] libbt proposed changes

[Alien <ali...@us...>]

Op woensdag 9 februari 2005 12:36, schreef Peter Stuge:
> Hi, Alien.
>
> Did you see my previous mail about how I'm thinking about making my
> own client and would like to use libbt if possible?
>
> On Wed, Feb 09, 2005 at 12:21:07PM +0100, Alien wrote:
> > I'm negotiating with the maintainer of ctorrent, so that I might
> > change that project so it'd use libbt, possibly if he has code to
> > handle bittorrent stuff, that i put it in here as well.
>
> I've tried to reach him but did not succeed.

I received one mail from him a few days ago, but he didn't respond to my ot=
her=20
questions or other mails, i sent him a mail in which i give him 2 weeks to=
=20
respond, or else i'm requesting project takeover to SF.

> > In that perspective: the library should be able to be used by any
> > kind of frontend, if it cannot, then all efforts to build a library
> > are in vain. Especially if a command-line frontend wants to use it,
> > you can understand it cannot depend on stuff like libevent, since
> > text-only distro's will probably not ship it.
> >
> > just my thoughts, please react to this.
>
> Sounds good. My last mail sort of probed for how much control I would
> have of low-level things inside libbt if I were to use it, but I
> guess libbt isn't quite there yet for me to use.. Or?

ksmathers said that it's not quite there yet, but i plan to do it.

> The ideal thing would be if libbt abstracted away everything
> BitTorrent and simply provided an interface for the application to
> optionally control as many parameters as possible. Sort of like what
> libcurl does for HTTP and FTP transports.

don't go there...

there are other things like that, like for example giFT. if you really wish=
=20
something like that, please, make a giFT plugin for it instead, i know I=20
would appreciate that. (i saw in your mail that you wished to start the=20
backend when starting the frontend, etc... but that's really none of it's=20
business, if you really want that, you can make a simple wrapper script tha=
t=20
actually does that.)
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] libbt proposed changes

[Peter S. <stu...@cd...>]

Hi, Alien.

Did you see my previous mail about how I'm thinking about making my
own client and would like to use libbt if possible?


On Wed, Feb 09, 2005 at 12:21:07PM +0100, Alien wrote:
> I'm negotiating with the maintainer of ctorrent, so that I might
> change that project so it'd use libbt, possibly if he has code to
> handle bittorrent stuff, that i put it in here as well.

I've tried to reach him but did not succeed.


> In that perspective: the library should be able to be used by any
> kind of frontend, if it cannot, then all efforts to build a library
> are in vain. Especially if a command-line frontend wants to use it,
> you can understand it cannot depend on stuff like libevent, since
> text-only distro's will probably not ship it.
> 
> just my thoughts, please react to this.

Sounds good. My last mail sort of probed for how much control I would
have of low-level things inside libbt if I were to use it, but I
guess libbt isn't quite there yet for me to use.. Or?

The ideal thing would be if libbt abstracted away everything
BitTorrent and simply provided an interface for the application to
optionally control as many parameters as possible. Sort of like what
libcurl does for HTTP and FTP transports.


//Peter

Re: [Libbt-devel] libbt proposed changes

[Alien <ali...@us...>]

Op dinsdag 8 februari 2005 23:37, schreef Elliott Mitchell:
> >From: Alien <ali...@us...>
> > forgot to mention that the following requirements will be placed upon t=
he
> > developpers:
> >
> > automake-1.6
>
> Looking at Debian, as they tend to be the farthest behind of the Linux
> distributions. Stable ships automake 1.4 as the "automake" package, but
> has 1.5 available as "automake1.5" (guess which folks are likely to have
> handy). This suggests to me that 1.4 is a better baseline.
>
> I'm astonished that they appear to possibly be preparing to ship *5*
> distinct versions of automake with their next release (1.4, 1.6, 1.7,
> 1.8, and 1.9). This doesn't inspire confidence in automake as a good tool
> to depend on.

well, it's like this, the mandrake also has the 1.4 as default (this may be=
=20
changed in the last version), i've never seen or heard from a 1.5 version.=
=20
but all i know is that the 1.6 is significantly different than the 1.4 one;=
=20
so significant, that most stuff wont even work, i know that from 1.6 to 1.9=
=20
there isn't much changed, when trying to build stuff with those, you get so=
me=20
warnings, but it works.

My idea is that not alot of people use CVS, just a few developpers and that=
=20
this dependancy is only on those people. I feel bad for debian people, but =
I=20
know that lots of automake files have totally different macro's with 1.4 an=
d=20
this may prove hard to support. nevertheless, if someone were to be able to=
=20
make this work with 1.4, i'm willing to have autogen.sh have an option (or=
=20
detection) of no other version than 1.4 and handle it differently, however,=
 i=20
cannot spend my time on this.

> > btw: some time later, i'd like to remove this event dependency
>
> It is unfinished and completely untested (beyond -Wall), but the
> events-glib was an attempt to use glib instead. This seemed a good choice
> as GTK and therefore GNOME depends upon glib and as a result it is likely
> to be present on most systems.

I'm not sure that backend tools should be dependant upon frontend-like=20
libraries like GTK and GNOME, i'm never much on dependancies unless most=20
distro's ship it or it already is installed, if it's a usefull dependancy I=
=20
can change my mind, however, it seemed to me that this event was not=20
installed on my system, and uuid isn't even available. but, these are not m=
y=20
primary concerns at the moment.

my primary thoughs right now are on the subject if I should split the=20
tool-frontends right away from the library, or only later... i think i'll=20
include them first and only split-up later.

this split-up being in the interest so that building a shared library is qu=
ite=20
possible, so other projects can use this library.

I'm negotiating with the maintainer of ctorrent, so that I might change tha=
t=20
project so it'd use libbt, possibly if he has code to handle bittorrent=20
stuff, that i put it in here as well.

In that perspective: the library should be able to be used by any kind of=20
frontend, if it cannot, then all efforts to build a library are in vain.=20
Especially if a command-line frontend wants to use it, you can understand i=
t=20
cannot depend on stuff like libevent, since text-only distro's will probabl=
y=20
not ship it.

just my thoughts, please react to this.

BTW: there are a few 64bit quircks in libbt and those are my primary concer=
n=20
after the changing to autotools.
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] libbt proposed changes

[Elliott M. <eh...@m5...>]

>From: Alien <ali...@us...>
> forgot to mention that the following requirements will be placed upon the 
> developpers:

> automake-1.6

Looking at Debian, as they tend to be the farthest behind of the Linux
distributions. Stable ships automake 1.4 as the "automake" package, but
has 1.5 available as "automake1.5" (guess which folks are likely to have
handy). This suggests to me that 1.4 is a better baseline.

I'm astonished that they appear to possibly be preparing to ship *5*
distinct versions of automake with their next release (1.4, 1.6, 1.7,
1.8, and 1.9). This doesn't inspire confidence in automake as a good tool
to depend on.

> btw: some time later, i'd like to remove this event dependency

It is unfinished and completely untested (beyond -Wall), but the
events-glib was an attempt to use glib instead. This seemed a good choice
as GTK and therefore GNOME depends upon glib and as a result it is likely
to be present on most systems.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \   (    |         EH...@gr... PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/

[Libbt-devel] bterror.h

[Alien <ali...@us...>]

permission to encapsulate this in the autogen.sh in a non-perl setup? (one=
=20
less dependency).

anyway, i can understand that a header file be made, but if you are adjusti=
ng=20
a some txt file, you can also just change the header file, it's not much mo=
re=20
editing...

i don't really understand the why of this script.
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] libbt proposed changes

[Alien <ali...@us...>]

Op dinsdag 8 februari 2005 17:57, schreef Emil Sit:
> On Tue, 08 February 2005 at 17:34 (+0100), Alien wrote:
> > I have communicated with ksmathers he gave me devel access, but warned =
me
> > to ask Emil (you better respond soon) about what i plan to do.
>
> As I am relatively busy with school work, I haven't contributed
> anything since my initial push to use a clean async interface.
> There are certainly things that would be nice to see, such as...
>
>   * Better API definition and documentation
>   * Using a better string library
>   * Test code
>   * autoconf
>   * cvs commit mail messages

i'm also quite busy with school and other things.

i probably won't work on all these topics (?yet?).

> > when i saw the condition of CVS HEAD i kinda wanted to clean it up, and
> > use autotools, so if anyone doesn't agree, i'll try and convert the bui=
ld
> > system of head to autotools, and after that i'll try and make a real
> > shared (or static) library and split the frontends...
>
> I thought Kevin was opposed to autotools and while I'm not great fan,
> I agree they're better than what's there now.  I always found it
> irritating that there were Linux specific Makefiles committed to the
> repository.
>
> Please feel free to improve!

well, if like the majority of GNU/Linux uses GNU build tools, why not utili=
ze=20
them to the fullest...
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] libbt proposed changes

[Alien <ali...@us...>]

arg, forgot more:

it'd be easier to have a link on http://libbt.sourceforge.net/ to=20
http://sourceforge.net/projects/libbt/ .

also, I took the liberty of registering an IRC channel on irc.freenode.org =
:=20
#libbt . you may put that one the site as well.
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] libbt proposed changes

[Emil S. <si...@MI...>]

On Tue, 08 February 2005 at 17:34 (+0100), Alien wrote:
> I have communicated with ksmathers he gave me devel access, but warned me to 
> ask Emil (you better respond soon) about what i plan to do.

As I am relatively busy with school work, I haven't contributed 
anything since my initial push to use a clean async interface.
There are certainly things that would be nice to see, such as...

  * Better API definition and documentation
  * Using a better string library 
  * Test code
  * autoconf
  * cvs commit mail messages

> when i saw the condition of CVS HEAD i kinda wanted to clean it up, and use 
> autotools, so if anyone doesn't agree, i'll try and convert the build system 
> of head to autotools, and after that i'll try and make a real shared (or 
> static) library and split the frontends...

I thought Kevin was opposed to autotools and while I'm not great fan,
I agree they're better than what's there now.  I always found it
irritating that there were Linux specific Makefiles committed to the
repository. 

Please feel free to improve!

-- 
Emil Sit / MIT: CSAIL PDOS, SIPB, OLC / http://web.mit.edu/sit/www/

Re: [Libbt-devel] libbt proposed changes

[Alien <ali...@us...>]

forgot to mention that the following requirements will be placed upon the=20
developpers:

autoconf-2.5
automake-1.6
maybe libtool

most of you developpers will already have this installed, and for end users=
=20
(not using CVS ) this will not be necessary.

the idea is that to compile from CVS you need all tools, to compile from=20
distributed source, only gcc and stuff like that is required.

btw: some time later, i'd like to remove this event dependency

furthermore, i've seen that lotsa things aren't according to GNU standards,=
=20
well, it can't hurt to use em, so i'll make changes accordingly.

small question, when branched, if i delete a file (not purge) i suspect tha=
t=20
in other branches this file will not be deleted. (i also suspect that this =
is=20
totally different with directories)

the double files i'd like to delete:
CREDITS --> AUTHORS
CHANGELOG --> ChangeLog
NEWS has to be added
=2D-=20
Alien is my name and head-biting is my game.

[Libbt-devel] libbt proposed changes

[Alien <ali...@us...>]

I have communicated with ksmathers he gave me devel access, but warned me t=
o=20
ask Emil (you better respond soon) about what i plan to do.

I'm most active in the development of oriongame, which holds a 3D engine=20
(which is what i'm trying to build), the thing is that it'd be nice if we g=
ot=20
torrent possibilities in the game, (for downloading maps, etc...).

when i saw the condition of CVS HEAD i kinda wanted to clean it up, and use=
=20
autotools, so if anyone doesn't agree, i'll try and convert the build syste=
m=20
of head to autotools, and after that i'll try and make a real shared (or=20
static) library and split the frontends...

alternatively once i had this idea to make a plugin for gift about using=20
torrents, but there are quite alot of differences between the protocols, th=
e=20
thing is that i don't have that much time, so i'll drop this probably.

the thing is, torrent is lacking a shared library. i have not found a singl=
e=20
thing that looks to what i need, it seems that every project just makes it=
=20
their own and start again.

after the split of front and backend i'd like to propose a release and afte=
r=20
that devel on protocol 2 should start also...

I will not be able to do everything, but at least i'll clean this up and tr=
y=20
to split it up, so i write a plugin that uses this library for my engine.

anyone who has any thoughts, please go ahead.

there was also some talk about splitting up in branches, but since this=20
doesn't look that active, it'll probably be no problem.

sometimes i commit things that are in preparation of further cleaning up, a=
nd=20
i have already commited one or two files, more is on the way, i'm trying to=
=20
clean this all out and install the man files as well.

I already have a autogen.sh script: so building from CVS HEAD should be eas=
y:

=2E/autogen.sh (this will call ./configure as well)
make
make install

if one should package something using the "make dist" command one could=20
install it using

=2E/configure
make
make install

that's the idea
=2D-=20
Alien is my name and head-biting is my game.

[Libbt-devel] List newcomer with crazy ideas

[Peter S. <stu...@cd...>]

Hi everyone!

I'm thinking about making a BT client that suits my needs, since I
haven't found one already, and since it will be in C, I'd like to
use libbt if possible.

Some of the features I'm looking for are only available in Azureus as
far as I've found during my idle searches for clients and their
features. (Specifically this is torrent muxing on one port.) I don't
like Java however, and will not run a Java torrent client, simple as
that. :)

Personally I don't care about bandwidth management much, but I
realize that others may, so this will probably also be a feature I'm
looking for. Worst-case through delayed TCP ACKs.

I'm thinking about a client/server design similar to that of giFT,
but would like the curses client to be better integrated with the
server, so that the server starts automatically when I start the
client, or if a server is already running, the client just attaches
to it. When exiting the client I want to either "detach" or shutdown.
With a nice API here lots of other nice client clients (hehe) could
be constructed; web-based, WAP, PDA, BlueTooth on cellphone, etc.
etc. Nothing I care about personally, but others may.

A given is really robust operation no matter what. Currently I'm
using ctorrent rather than btget for a couple of reasons, although
most of them are purely cosmetic. Anyway, ctorrent gets problems when
it can't write data to disk; since pieces were downloaded properly,
it thinks they're good on disk as well, and will happily seed invalid
data when the full torrent has been leeched, regardless of whether it
was written to disk properly or not. I'll just pause the leech if
data can't be written to disk. (Or, save to RAM, so the user can free
up disk later, configurable of course.)

This project is of course slightly on the ambitious side but I am
slowly getting sufficiently annoyed to actually start working on it.
And now, for the $10k question;

How well would you say that libbt fits into my plan?

(Or maybe you even know a much better client than what I had in
mind, already available? Please let me know! :) I've tried qtorrent,
ABC, btget and ctorrent besides the reference implementation.)


Thanks for any input!


//Peter

[Libbt-devel] Re: Bad info_hash?

[Stephen H. <li...@dr...>]

This sounds like #1083910. I was having similar problems and the fix I 
included worked for me. I suggest you try that.

Steve.

[Libbt-devel] Bad info_hash?

[Joao L. <jo...@te...>]

Hi

  I have been able to succesfully compile (gcc) and run btget under 
RedHat 9 using the Makefile provided with release 1.03, but when I try 
to get a torrent the follwoing error is returned:

"Torrent not registered with this tracker"

  I'm sure the torrent file is good because I can download it with 
Azureus without any problems. I compared the HTTP request from btget and 
Azureus and noticed that the info_hash strings are completely different. 
I know there are issues around using btget on a big-endian machines, but 
I thought they would not affect i386 ones, at least not with the latest 
libbt version. Is this a known issue?

Regards,
Joao

event_dispatch can be called only once? WAS Re: [Libbt-devel] a few questions about libbt

[Shehjar T. <sh...@sa...>]

Hi all

Emil Sit wrote:
>>Once the seeding of a few files has started , can I add more files to be 
>>seeded on the same thread/process?
> 
> 
> Yes.
> 
> 
>>In terms of code, I guess, what I mean is whether i can do another 
>>ctx_addtorrent to the same context, after I have called ctx_startserver 
>>for previously added torrents?
> 
> 
> Yes; but you only need to call ctx_startserver once.
> 
> 
>>And how will event_dispatch figure in this?
> 
> 
> It's all handled automatically.
Ok.I modified the btget.c to add two torrents and seed using the files 
in the current directory.It seems that the library starts its work only 
after the event_dispatch() is called.

I am able to call event_dispatch() only once in the whole program, that 
is after I have finished adding torrents, because of which I am not able 
to add more torrents later in a program.(since the server loop or 
whatever has already started..), and have them get seeded too.

What I now want is that I be able to add more torrents after the 
eventy_dispatch() has been called.I am not familiar with libevent at 
this stage.please help.

Heres the link to the code file:
http://users.sarai.net/~shehjar/temp/btserv.c

Thanks in advance
Shehjar