libbt-devel — C Library for Bittorrent Developers

Re: [Libbt-devel] what's the typical use-case? [was: mess]

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

Op vrijdag 11 februari 2005 02:03, schreef Peter Stuge:
> On Thu, Feb 10, 2005 at 11:07:33AM -0800, Tyler MacDonald wrote:
> > > - functions for creating torrent files
> > > - functions for checking torrent files
> > > - functions for adding torrent files
> > > - functions for deleting torrent files
> > > - functions for selecting files in torrent files
> > > - functions for initiating the library
> > > - functions for freeing the library
> > > - functions for setting options in the library
> > > - functions for hooking callback functions (or select stuff)
>
> [..]
>
> > - functions for converting peer communication into data structures

i'd rather not, and instead supply a function that gives a the structure=20
that's already in memory

> > - functions for converting peer responses from data structures into
> > buffers * both communication of metadata and actual torrnent data

i don't think this is necessary

> > - functions for enumerating the list of peers we are presently connected
> > to with a callback
> >   * presumedly this function would be part of the core loop
> >   * with write access, to set throttling flag, etc

yes

> > - functions for enumerating the list of available peers with a callback

yes, but it doesn't have to have a callback

> > - functions for dropping connections to specific peers

yes

> > - functions for initiating connections to specific peers

I'm not sure about this one

furthermore, it may be better to have a function that lists ALL torrents bu=
sy=20
and a function that gives all peers/torrent, and functions for adding=20
deleting peers/torrent etc...

wouldn't it be better if the library handled the torrent details, so that=20
frontends were easier to make?

> What are people's intentions for libbt?
>
> I believe it was originally targeted at non-p2p applications, but
> rather as a transport plugin to allow applications to access random
> files via BT.
>
> Should it stay there?
>
> I re-read the protocol spec and since it's really simple it may not
> be worth the effort to work on a library abstracting BitTorrent but
> still allowing fine-grained control over things like outgoing
> bandwidth, which peers should be used/accepted for what, and so on -
> since these things are so easily determined in the actual application
> context anyway.
>
> Thoughts?

probably make them easy by delivering functions for them
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] what's the typical use-case? [was: mess]

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

On Thu, Feb 10, 2005 at 11:07:33AM -0800, Tyler MacDonald wrote:
> > - functions for creating torrent files
> > - functions for checking torrent files
> > - functions for adding torrent files
> > - functions for deleting torrent files
> > - functions for selecting files in torrent files
> > - functions for initiating the library
> > - functions for freeing the library
> > - functions for setting options in the library
> > - functions for hooking callback functions (or select stuff)

[..]

> - functions for converting peer communication into data structures
> 
> - functions for converting peer responses from data structures into buffers
>   * both communication of metadata and actual torrnent data
> 
> - functions for enumerating the list of peers we are presently connected to
>   with a callback 
>   * presumedly this function would be part of the core loop
>   * with write access, to set throttling flag, etc
> 
> - functions for enumerating the list of available peers with a callback
> 
> - functions for dropping connections to specific peers
> 
> - functions for initiating connections to specific peers

What are people's intentions for libbt?

I believe it was originally targeted at non-p2p applications, but
rather as a transport plugin to allow applications to access random
files via BT.

Should it stay there?

I re-read the protocol spec and since it's really simple it may not
be worth the effort to work on a library abstracting BitTorrent but
still allowing fine-grained control over things like outgoing
bandwidth, which peers should be used/accepted for what, and so on -
since these things are so easily determined in the actual application
context anyway.

Thoughts?


//Peter

Re: [Libbt-devel] role of libevent

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

>From: Alien <ali...@us...>
> Op donderdag 10 februari 2005 05:38, schreef Elliott Mitchell:
> > Does not include Windows though...
> 
> i couldn't care less about that

Despite the annoyance they do exist. To truely takeover the world it is
best not to argue with the end users.

I'm suggesting glib as it is capable of encapsulating all IO in a
cross-platform manner. Also has a nice object system written in C already
put together.

>From: Peter Stuge <stu...@cd...>
> On Thu, Feb 10, 2005 at 05:02:09PM +0100, Alien wrote:
> > > Only reason to use it is the increased performance.
> > 
> > i sincerely doubt that event would be more performant than using
> > select directly, really, in fact with using select directly, you
> > should see a slight performance increase.
> 
> Well, on reading the libevent page and a few other pages linked from
> it, I learned that there are other interfaces available that offer
> even better performance than select(). libevent uses them all. Check
> out the C10K page for more information. It's about handling thousands
> of connections on a server, and while that probably wont be happening
> in Torrent clients anytime soon, spending unneccessary time in the
> kernel is never useful. :)

glib looks poll() oriented, libcurl is definitely select() oriented
(wonder how they claim to work on EvilOS?). It appears that select() is
discouraged in modern programs, with functions like poll() being
recommended.

> On Thu, Feb 10, 2005 at 11:03:43AM -0500, Emil Sit wrote:
> > On Thu, 10 February 2005 at 16:45 (+0100), Peter Stuge wrote:
> > > libraries. I can certainly live with select() in libbt as for
> > > performance, I think it will be good enough. But, on the other
> > > hand,
> > 
> > Performance is not the issue.  The hard problem is how to isolate 
> > event-handling code from the details of the library/application so
> > that you have a clean and maintainable program.  Much of the work
> > that I did was to create clean abstractions. 
> > 
> > The hard part about making libbt a library is in allowing the I/O
> > handling to integrate with the program that it is being linked into.
> > If your application uses X, how do you integrate X event loop
> > and select/poll/libevent-abstracted I/O handling?
> > 
> > giFT seems to have the right idea by isolating the I/O into
> > a separate process and communicating using RPCs with front-end
> > applications.
> 
> This brings us to the API/internals topic.. Should libbt work on each
> torrent in a separate process, or work on all active torrents in a
> libbt process separate from the application, or should we shoehorn
> all the IO into the main application process?
> 
> I think either libbt process or torrent process is fine, with the
> former looking nicer and scaling a lot better.

I think this is an application's choice, not the library's. As such run
everything in the single process, allow for an app to fork() for each
torrent, but do not require that.

Another thing to imagine is that a system might have a global torrent
handling process, having a unified cache and doing whole bandwidth
regulation. It would be in the domain of a library to be prepared to
talk to such a process.

> I don't know enough X to answer your question, but say libbt provides
> a fd from pipe() back to the application for notification, would that
> be easy enough to check for? If so, libbt can do async however it
> wants in it's own process and just send status back through the pipe.

For every X-server you're talking to you'll have a file-descriptor that
can be watched for being ready for output or having input ready (I have
looked at this). Programs in general may need an arbitrary number of FDs
that need monitoring.


-- 
(\___(\___(\______          --=> 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] mess

[Tyler M. <ty...@yi...>]

Alien <ali...@us...> wrote:
> we need to make a full protocol of what libbt (as a library) needs to have in 
> respect of the functions:
> 
> - functions for creating torrent files
> - functions for checking torrent files
> - functions for adding torrent files
> - functions for deleting torrent files
> - functions for selecting files in torrent files
> - functions for initiating the library
> - functions for freeing the library
> - functions for setting options in the library
> - functions for hooking callback functions (or select stuff)
> 
> if you guys think this is too highlevel, please let me know.

	I would like to see the lower-level functions that make all of this
work be part of the official API as well, such as:

- functions for converting peer communication into data structures

- functions for converting peer responses from data structures into buffers
  * both communication of metadata and actual torrnent data

- functions for enumerating the list of peers we are presently connected to
  with a callback 
  * presumedly this function would be part of the core loop
  * with write access, to set throttling flag, etc

- functions for enumerating the list of available peers with a callback

- functions for dropping connections to specific peers

- functions for initiating connections to specific peers

	- Tyler

Re: [Libbt-devel] role of libevent

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

Op donderdag 10 februari 2005 17:37, schreef Emil Sit:
> On Thu, 10 February 2005 at 17:26 (+0100), Peter Stuge wrote:
> > be easy enough to check for? If so, libbt can do async however it
> > wants in it's own process and just send status back through the pipe.
>
> note that in this architecture, "libbt" is not a library.

with some necessary changes, libbt is a library (it is right now), see my=20
other post about API for libbt.

> alien's init/free/update suggestion is workable for the library
> case; it is what libcurl does.  See libcurl-multi (3).

i stand corrected, we need more

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

[Libbt-devel] mess

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

well, you guys weren't kidding, this is a mess:

we need to make a full protocol of what libbt (as a library) needs to have =
in=20
respect of the functions:

=2D functions for creating torrent files
=2D functions for checking torrent files
=2D functions for adding torrent files
=2D functions for deleting torrent files
=2D functions for selecting files in torrent files
=2D functions for initiating the library
=2D functions for freeing the library
=2D functions for setting options in the library
=2D functions for hooking callback functions (or select stuff)

if you guys think this is too highlevel, please let me know.

furthermore, there is also an idea that one could add torrent files to some=
=20
directory and they start downloading immediately, i don't know if you guys=
=20
want to work like that...

let me know
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] role of libevent

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

On Thu, 10 February 2005 at 17:26 (+0100), Peter Stuge wrote:
> be easy enough to check for? If so, libbt can do async however it
> wants in it's own process and just send status back through the pipe.

note that in this architecture, "libbt" is not a library. 

alien's init/free/update suggestion is workable for the library
case; it is what libcurl does.  See libcurl-multi (3).

Re: [Libbt-devel] role of libevent

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

On Thu, Feb 10, 2005 at 05:02:09PM +0100, Alien wrote:
> > Only reason to use it is the increased performance.
> 
> i sincerely doubt that event would be more performant than using
> select directly, really, in fact with using select directly, you
> should see a slight performance increase.

Well, on reading the libevent page and a few other pages linked from
it, I learned that there are other interfaces available that offer
even better performance than select(). libevent uses them all. Check
out the C10K page for more information. It's about handling thousands
of connections on a server, and while that probably wont be happening
in Torrent clients anytime soon, spending unneccessary time in the
kernel is never useful. :)


On Thu, Feb 10, 2005 at 11:03:43AM -0500, Emil Sit wrote:
> On Thu, 10 February 2005 at 16:45 (+0100), Peter Stuge wrote:
> > libraries. I can certainly live with select() in libbt as for
> > performance, I think it will be good enough. But, on the other
> > hand,
> 
> Performance is not the issue.  The hard problem is how to isolate 
> event-handling code from the details of the library/application so
> that you have a clean and maintainable program.  Much of the work
> that I did was to create clean abstractions. 
> 
> The hard part about making libbt a library is in allowing the I/O
> handling to integrate with the program that it is being linked into.
> If your application uses X, how do you integrate X event loop
> and select/poll/libevent-abstracted I/O handling?
> 
> giFT seems to have the right idea by isolating the I/O into
> a separate process and communicating using RPCs with front-end
> applications.

This brings us to the API/internals topic.. Should libbt work on each
torrent in a separate process, or work on all active torrents in a
libbt process separate from the application, or should we shoehorn
all the IO into the main application process?

I think either libbt process or torrent process is fine, with the
former looking nicer and scaling a lot better.

I don't know enough X to answer your question, but say libbt provides
a fd from pipe() back to the application for notification, would that
be easy enough to check for? If so, libbt can do async however it
wants in it's own process and just send status back through the pipe.


//Peter

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

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

Op donderdag 10 februari 2005 16:59, schreef Peter Stuge:
> On Thu, Feb 10, 2005 at 12:38:30PM +0100, Alien wrote:
> > > 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.
> >
> > so you are trying to build it with a autoconf-2.13 version?
>
> The above error came from when I just ran autogen.sh from a fresh
> checkout. That tried to use autoheader-2.59. When I changed
> autogen.sh to explicitly invoke autoheader-2.13 instead of
> autoheader, it worked.
>
> > you don't have a newer one? in case i'm not mistaken, automake-1.6
> > requires autoconf-2.53.
>
> I have these autotools;
> (-r* are Gentoo package revisions of the upstream versions)
>
> stuge@carepad4 /var/db/pkg/sys-devel $ ls -ld auto*
> drwxr-xr-x  2 root root 4096 Jan  9 19:54 autoconf-2.13
> drwxr-xr-x  2 root root 4096 Jan  9 19:56 autoconf-2.59-r6
> drwxr-xr-x  2 root root 4096 Jan  9 19:54 autoconf-wrapper-2
> drwxr-xr-x  2 root root 4096 Jan  9 20:03 automake-1.4_p6
> drwxr-xr-x  2 root root 4096 Jan  9 19:57 automake-1.5
> drwxr-xr-x  2 root root 4096 Jan  9 20:01 automake-1.6.3
> drwxr-xr-x  2 root root 4096 Jan  9 20:05 automake-1.7.9
> drwxr-xr-x  2 root root 4096 Jan  9 19:59 automake-1.8.5-r2
> drwxr-xr-x  2 root root 4096 Jan 25 22:50 automake-1.9.4
> drwxr-xr-x  2 root root 4096 Jan  9 20:03 automake-wrapper-1
>
> I believe the wrappers are used to make smart decisions about which
> underlying version to use for the particular task at hand.
>
> > in any case, in the top configure.ac file there is a ACPREREQ() for
> > what autoconf version it has to have.
> >
> > I'm afraid i don't know much about old stuff like that, even on the
> > mdk8.2 i used years ago, it already had autoconf-2.5 and
> > automake-1.6, and all my projects are built with it, because at that
> > time, everyone seemed to have made the leap towards automake-1.6.
>
> Well, it did complain that both configure.in and configure.ac were
> present, even if it picked out configure.ac on it's own.
>
> I see AUTOMAKE_VERSION=3D"-1.7" in autogen.sh, that shouldn't matter to
> autoconf, though..
>
> I just did a fresh update of CVS and with the WANT_AUTOCONF_2_5 it
> works great. :)
>
> stuge@carepad4 ~/lb/libbt $ sh autogen.sh
> Makefile.am: installing ./COPYING'
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
>
> Thanks!

heh, i probably was in the middle of working on it, or something...
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] role of libevent

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

Op donderdag 10 februari 2005 17:03, schreef Emil Sit:
> On Thu, 10 February 2005 at 16:45 (+0100), Peter Stuge wrote:
> > libraries. I can certainly live with select() in libbt as for
> > performance, I think it will be good enough. But, on the other hand,
>
> Performance is not the issue.  The hard problem is how to isolate
> event-handling code from the details of the library/application so
> that you have a clean and maintainable program.  Much of the work
> that I did was to create clean abstractions.
>
> The hard part about making libbt a library is in allowing the I/O
> handling to integrate with the program that it is being linked into.
> If your application uses X, how do you integrate X event loop
> and select/poll/libevent-abstracted I/O handling?
>
> giFT seems to have the right idea by isolating the I/O into
> a separate process and communicating using RPCs with front-end
> applications.

well, that was more or less my idea about splitting btget and libbt, and th=
at=20
is what i am working on now.

i have not looked at this more, but the simplest thing to split it up is to=
=20
provide a init, update and free function to frontends, with the idea that t=
he=20
update function has to be called in some kind of loop, until it returns 0 o=
r=20
something similar...

maybe i should look into giFT and see what they have as a system

any other idea's are welcome
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] libbt proposed changes

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

On Thu, Feb 10, 2005 at 12:44:12PM +0100, Alien wrote:
> instead of stealing idea, how about stealing the frontend code only

We could just as well change or copy btget and make it look the same.
There's no big difference in functionality. (btget is even more
robust..)


> wait, ctorrent is in C++? the info on SF said it was to be using C?

Yep, I was a little surprised too.

stuge@carepad4 ~/lb/ctorrent-1.3.4 $ ls
AUTHORS       btconfig.cpp   connect_nonb.cpp  peer.cpp
COPYING       btconfig.h     connect_nonb.h    peer.h
ChangeLog     btcontent.cpp  ctorrent.cpp      peerlist.cpp
Doxyfile      btcontent.h    def.h             peerlist.h
INSTALL       btfiles.cpp    depcomp           rate.cpp
Makefile.am   btfiles.h      downloader.cpp    rate.h
Makefile.in   btrequest.cpp  downloader.h      setnonblock.cpp
NEWS          btrequest.h    httpencode.cpp    setnonblock.h
README        btstream.cpp   httpencode.h      sigint.cpp
VERSION       btstream.h     install-sh        sigint.h
aclocal.m4    bufio.cpp      iplist.cpp        stamp-h.in
bencode.cpp   bufio.h        iplist.h          tracker.cpp
bencode.h     config.h.in    missing           tracker.h
bitfield.cpp  configure      mkinstalldirs
bitfield.h    configure.ac   msgencode.h

Here's the help output, for reference;

stuge@carepad4 ~/lb/ctorrent-1.3.4 $ ctorrent -h
CTorrent devel          Copyright: YuHong(992126018601033)
WARNING: THERE IS NO WARRANTY FOR CTorrent. USE AT YOUR OWN RISK!!!

Generic Options:
-h/-H           Show this message.
-x              Decode metainfo(torrent) file only, don't download.
-c              Check exist only. don't download.

Download Options:
-e int          Exit while seed <int> hours later. (default 72 hours)
-p port         Listen port. (default 2706 -> 2106)
-s save_as      Save file/directory/metainfo as... 
-C cache_size   Cache size,unit MB. (default 16MB)
-f              Force seed mode. skip hash check at startup.
-b bf_filename  Bit field filename. (use it carefully)
-M max_peers    Max peers count.
-m min_peers    Min peers count.
-B rate         Max bandwidth (unit KB/s)
-P peer_id      Set Peer ID [-CT1304-]

Make metainfo(torrent) file Options:
-t              With make torrent. must specify this option.
-u url          Tracker's url.
-l piece_len    Piece length.(default 262144)

eg.
hong> ctorrent -s new_filename -e 12 -C 32 -p 6881 eg.torrent

home page: http://ctorrent.sourceforge.net/
bug report: bs...@si...


And the home page describes the status display that I like, it shows
number of peers, pieces on disk, pieces in torrent and pieces on
network followed by average down and up speed, and current down and
up speed.


> well, i have never ran any on the programs here, since i was only
> busy with the configuring step, i'll look into things like that
> now, since i wanna be sure that it runs on 64bit platforms

One of btget's better features is that it catches SIGTERM and sends a
cancel to the tracker. On the other hand it has a pretty annoying
unixtime printout every second. But it wasn't really designed to be
used as a client, rather an example of how libbt could be used.


//Peter

Re: [Libbt-devel] role of libevent

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

On Thu, 10 February 2005 at 16:45 (+0100), Peter Stuge wrote:
> libraries. I can certainly live with select() in libbt as for
> performance, I think it will be good enough. But, on the other hand,

Performance is not the issue.  The hard problem is how to isolate 
event-handling code from the details of the library/application so
that you have a clean and maintainable program.  Much of the work
that I did was to create clean abstractions. 

The hard part about making libbt a library is in allowing the I/O
handling to integrate with the program that it is being linked into.
If your application uses X, how do you integrate X event loop
and select/poll/libevent-abstracted I/O handling?

giFT seems to have the right idea by isolating the I/O into
a separate process and communicating using RPCs with front-end
applications.

Re: [Libbt-devel] role of libevent

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

Op donderdag 10 februari 2005 16:45, schreef Peter Stuge:
> On Thu, Feb 10, 2005 at 12:32:45PM +0100, Alien wrote:
> > > Perhaps make it a compile-time option?
> >
> > if we have it without and we can choose to go with and without it,
> > well, we might as well drop it totally.
>
> Only reason to use it is the increased performance.

i sincerely doubt that event would be more performant than using select=20
directly, really, in fact with using select directly, you should see a slig=
ht=20
performance increase.
=2D-=20
Alien is my name and head-biting is my game.

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

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

On Thu, Feb 10, 2005 at 12:38:30PM +0100, Alien wrote:
> > 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.
> 
> so you are trying to build it with a autoconf-2.13 version?

The above error came from when I just ran autogen.sh from a fresh
checkout. That tried to use autoheader-2.59. When I changed
autogen.sh to explicitly invoke autoheader-2.13 instead of
autoheader, it worked.


> you don't have a newer one? in case i'm not mistaken, automake-1.6
> requires autoconf-2.53.

I have these autotools;
(-r* are Gentoo package revisions of the upstream versions)

stuge@carepad4 /var/db/pkg/sys-devel $ ls -ld auto*
drwxr-xr-x  2 root root 4096 Jan  9 19:54 autoconf-2.13
drwxr-xr-x  2 root root 4096 Jan  9 19:56 autoconf-2.59-r6
drwxr-xr-x  2 root root 4096 Jan  9 19:54 autoconf-wrapper-2
drwxr-xr-x  2 root root 4096 Jan  9 20:03 automake-1.4_p6
drwxr-xr-x  2 root root 4096 Jan  9 19:57 automake-1.5
drwxr-xr-x  2 root root 4096 Jan  9 20:01 automake-1.6.3
drwxr-xr-x  2 root root 4096 Jan  9 20:05 automake-1.7.9
drwxr-xr-x  2 root root 4096 Jan  9 19:59 automake-1.8.5-r2
drwxr-xr-x  2 root root 4096 Jan 25 22:50 automake-1.9.4
drwxr-xr-x  2 root root 4096 Jan  9 20:03 automake-wrapper-1

I believe the wrappers are used to make smart decisions about which
underlying version to use for the particular task at hand.


> in any case, in the top configure.ac file there is a ACPREREQ() for
> what autoconf version it has to have.
> 
> I'm afraid i don't know much about old stuff like that, even on the
> mdk8.2 i used years ago, it already had autoconf-2.5 and
> automake-1.6, and all my projects are built with it, because at that
> time, everyone seemed to have made the leap towards automake-1.6.

Well, it did complain that both configure.in and configure.ac were
present, even if it picked out configure.ac on it's own.

I see AUTOMAKE_VERSION="-1.7" in autogen.sh, that shouldn't matter to
autoconf, though..

I just did a fresh update of CVS and with the WANT_AUTOCONF_2_5 it
works great. :)

stuge@carepad4 ~/lb/libbt $ sh autogen.sh 
Makefile.am: installing ./COPYING'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes

Thanks!


//Peter

Re: [Libbt-devel] role of libevent

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

On Thu, Feb 10, 2005 at 12:32:45PM +0100, Alien wrote:
> > Perhaps make it a compile-time option?
> 
> if we have it without and we can choose to go with and without it,
> well, we might as well drop it totally.

Only reason to use it is the increased performance.


> > > I'm curious what Alien means by the "removal of event".
> >
> > Replacing it with libbt-local async IO, probably using select()
> > directly.
> 
> yup

I like this because it's pretty portable and requires no extra
libraries. I can certainly live with select() in libbt as for
performance, I think it will be good enough. But, on the other hand,
if someone wants to pull libevent in, let them use it and reap the
benefits.

Maybe we should do some real-world testing and see if the performance
is an issue? I really doubt it across the internet, but it's probably
noticable on a private network.


On Thu, Feb 10, 2005 at 12:33:29PM +0100, Alien wrote:
> > Does not include Windows though...
> 
> i couldn't care less about that

Yes and no. If possible with little effort I like to support Windows
too. But I wont write that code anytime soon though. ;)


//Peter

[Libbt-devel] question about btlist

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

when i use the program, i see this:

         0x502a88(STRING)=3D(4)'name'
         =3D>
            0x502940(STRING)=3D(11)'mandrake9.1'
         0x502aa0(STRING)=3D(12)'piece length'
         =3D>
            0x5029c0(INTEGER)=3D262144
         0x502ab8(STRING)=3D(6)'pieces'
         =3D>
            0x502a50(STRING)=3D(156040)'[EAd???g?????f????????,1U?? ????...'


this last string is that normal? a huge string? i thought the pieces were=20
supposed to be there? which it would have to be a number?

thanks for any info relating to this
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] libbt proposed changes

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

Op donderdag 10 februari 2005 05:11, schreef Peter Stuge:
> On Wed, Feb 09, 2005 at 03:22:45PM -0800, Elliott Mitchell 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.
> >
> > The other thing is to steal any useful ideas from it.

instead of stealing idea, how about stealing the frontend code only

> Honestly, there aren't that many ideas in ctorrent. The reason I use
> it is because it defaults to nonstandard ports and has nice status
> output. But other than that, and simplicity, it has no really great
> features. For one it has no SIGTERM handler so ^C means no cancel
> sent to the tracker.. And it's in C++. Oh well. I still run it! :)
>
> One thing I certainly want in the reference library is the ability to
> mux many (all?) active torrents on the same incoming port.

wait, ctorrent is in C++? the info on SF said it was to be using C?

well, i have never ran any on the programs here, since i was only busy with=
=20
the configuring step, i'll look into things like that now, since i wanna be=
=20
sure that it runs on 64bit platforms
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] libbt proposed changes

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

Op donderdag 10 februari 2005 02:53, schreef Peter Stuge:
> ..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! :)

heh, np
=2D-=20
Alien is my name and head-biting is my game.

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

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

Op donderdag 10 februari 2005 01:55, schreef Peter Stuge:
> 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.

so you are trying to build it with a autoconf-2.13 version? you don't have =
a=20
newer one? in case i'm not mistaken, automake-1.6 requires autoconf-2.53.

in any case, in the top configure.ac file there is a ACPREREQ() for what=20
autoconf version it has to have.

I'm afraid i don't know much about old stuff like that, even on the mdk8.2 =
i=20
used years ago, it already had autoconf-2.5 and automake-1.6, and all my=20
projects are built with it, because at that time, everyone seemed to have=20
made the leap towards automake-1.6.
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] role of libevent

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

Op donderdag 10 februari 2005 05:38, schreef Elliott Mitchell:
> Does not include Windows though...

i couldn't care less about that
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] role of libevent

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

Op donderdag 10 februari 2005 05:22, schreef Peter Stuge:
> On Wed, Feb 09, 2005 at 08:45:02PM -0500, Emil Sit wrote:
> > 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 did some reading and if I got everything right libevent means
>
> * abstracted async io across various platforms
> * possibly improved performance, particularly under load
> * a dependancy
>
> Performance over e.g. select() because the various platforms offer
> more efficient interfaces these days, and libevent supports them.
>
> I can see times when I as application developer would appreciate not
> having to pull in _yet_another_ library to get Torrent capability in
> my internet application, while a giFT backend could live with the
> extra dependancy tradeoff for the ultimate performance.
>
> Perhaps make it a compile-time option?

if we have it without and we can choose to go with and without it, well, we=
=20
might as well drop it totally.

> > I'm curious what Alien means by the "removal of event".
>
> Replacing it with libbt-local async IO, probably using select()
> directly.

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

Re: [Libbt-devel] libbt proposed changes

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

Op donderdag 10 februari 2005 00:22, schreef Elliott Mitchell:
> >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 up=
on
> > > > 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, b=
ut
> > > 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 a=
nd
> > 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.

well, if you want it to work with 1.4 ; try to look into how it works with =
1.4=20
and tell me, and i'll try and integrate it. The thing is that 1.4 is like=20
ancient and from 1.6 they all behave similarly.

secondly, a significant bunch of folks.. this is only on people using CVS..=
=2E I=20
think there are 9 people listed as devel, with half of them just inactive.=
=20
how many of those have no recent than 1.4 available? a small percentage, so=
=20
this looks like only 2 or 3 people will maybe be pissed off.

> > > > 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 dependan=
cy
> > 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 n=
ot
> > 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?

if it were possible i'd rather just not use it and no other dependency=20
instead...

> > 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.

heh

well, i have an additional remark about that: the SF page lists that this=20
project is about making a library, and that's what we should do, make this=
=20
library, and nothing else.

i believe we can merge these projects if i delete lotsa stuff from ctorrent=
,=20
and make ctorrent the frontend, and libbt the backend; as it's supposed to=
=20
be...

> > 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 understa=
nd
> > 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.

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

Re: [Libbt-devel] role of libevent

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

>From: Peter Stuge <stu...@cd...>
> On Wed, Feb 09, 2005 at 08:45:02PM -0500, Emil Sit wrote:
> > 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 did some reading and if I got everything right libevent means
> 
> * abstracted async io across various platforms

Does not include Windows though...

glib buys you all the Unicies and the evil mess.


-- 
(\___(\___(\______          --=> 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] role of libevent

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

On Wed, Feb 09, 2005 at 08:45:02PM -0500, Emil Sit wrote:
> 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 did some reading and if I got everything right libevent means

* abstracted async io across various platforms
* possibly improved performance, particularly under load
* a dependancy

Performance over e.g. select() because the various platforms offer
more efficient interfaces these days, and libevent supports them.

I can see times when I as application developer would appreciate not
having to pull in _yet_another_ library to get Torrent capability in
my internet application, while a giFT backend could live with the
extra dependancy tradeoff for the ultimate performance.

Perhaps make it a compile-time option?


> I'm curious what Alien means by the "removal of event".

Replacing it with libbt-local async IO, probably using select()
directly.


//Peter

Re: [Libbt-devel] libbt proposed changes

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

On Wed, Feb 09, 2005 at 03:22:45PM -0800, Elliott Mitchell 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.
> 
> The other thing is to steal any useful ideas from it.

Honestly, there aren't that many ideas in ctorrent. The reason I use
it is because it defaults to nonstandard ports and has nice status
output. But other than that, and simplicity, it has no really great
features. For one it has no SIGTERM handler so ^C means no cancel
sent to the tracker.. And it's in C++. Oh well. I still run it! :)

One thing I certainly want in the reference library is the ability to
mux many (all?) active torrents on the same incoming port.


//Peter