libbt-devel — C Library for Bittorrent Developers

[Libbt-devel] Re: Need some "other than Mac" checking done

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

hey,

good job, except that i don't work the with 1.03 codebase, you'll have to g=
et=20
this to Kevin, I don't use the 1.03 codebase in CVS HEAD, and frankly, the=
=20
util.c and util.h isn't really used much anymore, I do intend to keep most=
=20
stuff independant of platform...

I'm almost done reworking the CVS HEAD, until it is a little functional, no=
t=20
optimized in the least...

when it's more or less working, i'll send you a mail asking you to compile =
it=20
on mac...

about your patch:

well, I cannot compile it, for the simple reason that I only have linux, an=
d i=20
only have 64bit system, branch 1.03 has never worked for me before...

so, i could not even test your files if i wanted to...

i'll forward this mail to the mailing list, and we'll see if anything=20
happens...

good job, though...

AL13N

Op donderdag 5 mei 2005 23:38, schreef Dakidd:
> Hey guy...
> I think I've managed to knock the kinks out of util.c/util.h for use on
> Macs. I need somebody who can compile for Windows/Unix to check it out and
> see if I screwed up and trashed things for those platforms, or if my
> surgery managed to fix the Mac troubles, yet still leave the "other
> platforms" functional.
>
> The most obvious change (aside from "prettifying" the code - No offense
> intended against Kevin, but he writes code that, in my opinion, is all but
> completely unreadable) is that cacheopen() now takes a void * rather than=
 a
> char * as its first parameter - I *THINK* I've included the right "magic"
> to make this transparent, but I haven't got a way to test that theory. If
> you're wondering about the reason for this, it's kinda in-depth and a pain
> to explain, but I can give you the 411 if you really think it's needed. T=
he
> short version: Macs are *MUCH* happier dealing with files when they're
> passed around as an FSSpec rather than pathnames. There's a lot of voodoo
> involved, but it boils down to "if you want it to work properly in all
> situations on a Mac, do it with FSSPec structs instead of pathnames,
> otherwise, expect to hear your users screaming at you about meltdowns that
> happen for no apparent reason."
>
> I've done my best to conditionalize my changes (on the "TARGET_MACOS"
> value, set up in config.h) so that Unix/Windows can continue passing in a
> char * with a fully-qualified pathname and never notice a difference, whi=
le
> Macs will pass in an FSSpec, but have no way to test the Unix/Windows
> functionality.
>
> I've also done some cleanup and rewiring in the cacheopen() routine -
> You'll notice that the "mode" and "options" parameters have been renamed -
> Those two drove me absolutely *NUTS* until I finally broke down and
> "hand-executed" the code. The names were hideously confusing, and once I
> got through things, it became clear that Kevin had screwed the pooch
> bigtime - "options" gets passed in only when setting up a "writeable" fil=
e,
> and is the Unix file-access permission setting that should be used when t=
he
> file is created. As it was coded, it was being stored as one of the things
> to look at for deciding whether the file was open and cached or not. *BIG*
> screwup! It's obvious (now that I've "hand-executed" it) from looking at
> the rest of the routine that the intention was to open/cache a file based
> on its name and whether it was opened for read or write mode. Checking
> against the file permissions is pointless, and was the source of some maj=
or
> hair-pulling as I tried to figure out why nothing I did would make the
> routine work as expected on a Mac. This forced changes to the cache
> struct/array (c_fileset), and some rewriting of the code that worked with
> it.
>
> openPath() has also been reworked, again mainly to deal with the "Macs li=
ke
> FSSpecs better than pathnames" concept, and again, I believe I've managed
> to make the alterations transparent to Unix/Windows systems through
> conditionals.
>
> If you look through util.c, you'll also notice some "brain surgery" on the
> btAlloc/btMalloc/etc routines - This was done in the interest of
> speed/efficiency - I have yet to meet a library on the Mac that doesn't e=
nd
> up calling directly into the OS for malloc/calloc/realloc/etc calls exact=
ly
> as I do in the revised routines, but with idiotic amounts of useless
> overhead before doing so. So I've basically "chopped out the middleman" a=
nd
> gone straight to the MacOS toolbox routines - which are as old as the Mac
> itself, stable as a rock, and quite well documented - where the
> Windows/Unix versions got things done by way of the standard library
> routines. Operation for them shouldn't be affected, due to conditional
> compilation on the "TARGET_MACOS" value, but on the Mac, it's a good bit
> quicker.
>
> Overall, I've done some pretty major surgery throughout util.c, but I'm
> pretty sure that I've either made the needed changes compatible with, or
> transparent to, Unix and Windows systems by use of conditional compilation
> keyed on the "TARGET_MACOS" value.
>
> Now I need you (or someone else capable of compiling on Windows and/or
> Unix) to check and see if my changes are as compatible/transparent as I
> hope they are...
>
> Basically, "They work on my Mac. Do they still work on other platforms?"
>
> My altered versions (starting from the 1.03 version of the codebase) are
> attached. They might need line-end tweaking to be readable (Macs use '\r',
> windows '\n\r', and unix '\n') Let me know what you come up with, eh?
>
> (Oh - If you reply from somewhere other than your sourceforge.net address,
> make sure to put the string "PopperAndShadow" somewhere in the subject li=
ne
> - I've had to go to full-out email lockdown due to getting hit with more
> than 150 spams a day. I've got your sourceforge address whitelisted, but =
if
> you reply from somewhere else, I've got my procmailrc file set up to send
> *EVERYTHING* that isn't whitelisted straight to dev/null unless the subje=
ct
> line has the "PopperAndShadow" password in it somewhere - I might find out
> (far too late for it to make a difference) that you sent something if I
> notice in my procmail log, but otherwise, I'll never even know it existed)

Re: [96] [Libbt-devel] Coordinating development

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

Op zaterdag 23 april 2005 06:33, schreef Kevin Smathers:
> >>  * Hanging out on the IRC channel (#libbt on irc.freenode.net)
> >
> >i'm already there ;-)
>
> I'm not on IRC, but I can be IM'd at any of:
>
> Y!: kevin_at_ank AT yahoo DOT com
> MSN: kevin.smathers AT hp DOT com
> ICQ:  56409049
>
> >>  * Having someone actually be in charge: Kevin, could you clarify
> >>    what role you want to play in libbt?
> >
> >yes, actually in charge, this is the major problem I have been having, i
> >cannot seem to contact kevin...
>
> LibBT is one of several spare time research projects of mine.  I do work
> on it when I happen to need to transfer something through BitTorrent and
> find that it has broken with respect to current client customs.  At
> present my real research project at the lab is taking most of my
> attention (I was up at 4am for telecon's all this week for example), and
> what spare time I have I've been working on a different, though
> complementary program.  When that development is at a stage where I will
> need BT again, I'll take the time to either retread LibBT or else
> rewrite based on whatever the current protocol spec is (if Bram ever
> gets his Merkle tree specification finished.)
>
> If LibBT main branch manages to track the protocol (through people like
> Vanraes who have the time to make it do so), and simultaneously define
> some sort of library API, then great, I might not have to do any work
> when I need LibBT again later.
>
> I see the main trunk as a playground -- there should be room for
> experimentation there.  If the experiment fails, I'll revert the trunk
> and start over, or else let whoever wants to play on the trunk next do
> so.  If the experiment succeeds in being more useful than the stable
> branch (with all of its limitations) then I have no problem with letting
> it evolve.

I think it's well on it's way to become more usefull, but it isn't now... I=
=20
may well like to make a pre-release within a few weeks, maybe a month

> >>In addition to these logistic items (which don't require any one to
> >>write any code), it might be nice if there were some sort of
> >>consensus on these items before people continue hacking:
> >>
> >>  * Release goals/plan
> >>  * API definition
> >>    - Model for integration with applications (separate process or
> >>      linked in library with appropriate I/O multiplexing)
> >
> >more or less finished ( libbt/include/bt/bt.h ) + see also libbt/TODO
> >
> >>  * Implementation decisions:
> >>    - code style
> >>    - portable string/binary library
> >>    - portable network I/O
> >
> >can be usefull to agree upon.
> >
> >The big problem is that there is no active maintainer, therefor I
> > repectfully ask of kevin or Pandora that I be given maintainer
> > priviledges. I will not act without consulting the mailing list, but I
> > can be there _every_ day to "maintain" libbt.
> >
> >I have a buddy who wanted to help me coding on libbt HEAD CVS, and he
> > still (more or less a month) waits for ext CVS access or for kevin to
> > contact him. I just hope he wants to help now...
>
> No offense but I didn't see anything in his email that made me want to
> grant him developer access.   Have the
> guy submit patches until he shows an interest in some development project.

ok, no problem

but the real problem is that you aren't in contact when I need to contact y=
ou,=20
don't you check your mails? or didn't my mails come through?

as a second thing, how about maintainer priviledges, so I can change trove=
=20
categorisation, and change tracker stuff and etc... and file releases when =
i=20
have to.

Re: [96] [Libbt-devel] Coordinating development

[Kevin S. <ke...@an...>]

>>  * Hanging out on the IRC channel (#libbt on irc.freenode.net)
>>    
>>
>
>i'm already there ;-)
>
>  
>
I'm not on IRC, but I can be IM'd at any of:

Y!: kevin_at_ank AT yahoo DOT com
MSN: kevin.smathers AT hp DOT com
ICQ:  56409049

>>  * Having someone actually be in charge: Kevin, could you clarify
>>    what role you want to play in libbt?
>>    
>>
>
>yes, actually in charge, this is the major problem I have been having, i 
>cannot seem to contact kevin...
>  
>
LibBT is one of several spare time research projects of mine.  I do work 
on it when I happen to need to transfer something through BitTorrent and 
find that it has broken with respect to current client customs.  At 
present my real research project at the lab is taking most of my 
attention (I was up at 4am for telecon's all this week for example), and 
what spare time I have I've been working on a different, though 
complementary program.  When that development is at a stage where I will 
need BT again, I'll take the time to either retread LibBT or else 
rewrite based on whatever the current protocol spec is (if Bram ever 
gets his Merkle tree specification finished.)

If LibBT main branch manages to track the protocol (through people like 
Vanraes who have the time to make it do so), and simultaneously define 
some sort of library API, then great, I might not have to do any work 
when I need LibBT again later.

I see the main trunk as a playground -- there should be room for 
experimentation there.  If the experiment fails, I'll revert the trunk 
and start over, or else let whoever wants to play on the trunk next do 
so.  If the experiment succeeds in being more useful than the stable 
branch (with all of its limitations) then I have no problem with letting 
it evolve.

>  
>
>>In addition to these logistic items (which don't require any one to
>>write any code), it might be nice if there were some sort of
>>consensus on these items before people continue hacking:
>>
>>  * Release goals/plan
>>  * API definition
>>    - Model for integration with applications (separate process or
>>      linked in library with appropriate I/O multiplexing)
>>    
>>
>
>more or less finished ( libbt/include/bt/bt.h ) + see also libbt/TODO
>
>  
>
>>  * Implementation decisions:
>>    - code style
>>    - portable string/binary library
>>    - portable network I/O
>>    
>>
>
>can be usefull to agree upon.
>
>The big problem is that there is no active maintainer, therefor I repectfully 
>ask of kevin or Pandora that I be given maintainer priviledges. I will not 
>act without consulting the mailing list, but I can be there _every_ day to 
>"maintain" libbt.
>
>I have a buddy who wanted to help me coding on libbt HEAD CVS, and he still 
>(more or less a month) waits for ext CVS access or for kevin to contact him. 
>I just hope he wants to help now...
>
>  
>
No offense but I didn't see anything in his email that made me want to 
grant him developer access.   Have the
guy submit patches until he shows an interest in some development project. 

>As a side note, I have mostly rewrote the existing code (at least i copy paste 
>some stuff, and some stuff I leave; but there isn't a file that's been 
>changed; and some are now obsolete ).
>  
>

Re: [Libbt-devel] Intro and... suggestions

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

Op donderdag 21 april 2005 02:48, schreef Dakidd:
> >Hi,
> >
> >I'm the only one active at this time, and I'm already doing what you
> >describe,
> >except i didn't commit yet, because it'll break CVS HEAD.
>
> Hi yerself! :)
>
> No, Alien, you're not the "only one active"...=20

sorry, but I haven't heard much from you... and I am the only one active at=
=20
CVS, no offense.

> I've just been effectively=20
> silent, quietly banging away at adding stuff to make the thing truly
> cross-platform. As it stands now, it's Windows/*nix freindly (at least for
> the most part) but actively hostile to those of us still stuck by
> circumstances working on Macs that run an OS version below MacOS X (MacOS=
 X
> folks can use it *ALMOST* "as-is" due the the unix-like underpinnings of
> the OS). I'm hacking away, slowly but steadily, at changing that with a
> massive introduction of
> #if TARGET_MACOS
> ...
> #else
> ...
> #endif
> conditionals. At this point, I've done SOMETHING that has broken most of
> the library in a massive way, and am working on figuring out what it was
> that turned out to be "poison", but prior to the change that did it,
> btcheck, and "ctx_loadfile", which was basically all it called directly,
> was working 100% for me. I'll try to keep the list posted as I make
> progress back to functionality.

portability is good, i guess...

> FWIW:
> I started my "battle" on version 0.3, and that's where I'm sticking at
> least until I get things back to functional. It appears as though 1.3 is
> *MOSTLY* very similar, at least in the "core" btxxxxx code but I haven't
> wrapped my head around the various changes that come with the most recent
> versions, so I'm a lot more comfortable dealing with "the old one" until I
> get it functional again.
>
> If you'd like to see my changes so far, I'm willing to crate up SOME
> sections and pass them along to anyone interested, but outside of the
> "core" code listed, it's pretty much a minefield, since I've had to hack
> out huge swathes of utterly incompatible networking code to get a compile
> at all - peer.c being particularly obnoxious for me at this point - I'd
> estimate I've got more than 75% of it commented or conditionalized onto t=
he
> scrapheap - It's THAT hostile to Mac-style networking.

just a note, on CVS HEAD: peer.c is being completely rewritten. I do howeve=
r=20
not check anything little or big endian. which is not portable for some=20
*nixes including mac. but I must admit that there isn't much htonl stuff=20
anymore.

> Such a "crate up and send" will, by neccessity, have to be done "outside
> the channel" of CVS, since, quite bluntly, I'm *NOT* going to take the ti=
me
> needed to re-acquire the programs and skills needed to work with CVS away
> from banging on the code - never mind that committing anything in the sha=
pe
> it's currently in on my machine would be something close to a terrorist
> attack in terms of likely "damage" to the current codebase.

since I'm getting like "back to basics", for efficiency and maybe a little=
=20
portability reasons, you might be interested to check out how CVS HEAD work=
s=20
and extract it in a second codebase.

> >but because you seem interested, i'll commit everything now anyway, the
> >minute
> >i get my own version working a little again.
> >
> >I can tell you that i have gotten far and I restructured everything into=
 a
> >functional system, more or less...
> >
> >this "library" wasn't really a library when I started, they have 3 tools
> > (as the release from the 1.03 branch shows) btcheck, btlist & btget...
> >
> >the first 2 work more or less, the third is still not operational, becau=
se
> >i'm
> >working on the peer protocols now.
> >
> >
> >
> >The things i keep in mind:
> > - get rid of libevent
>
> Doesn't exist in MY copy of the source, but then, as mentioned, I'm worki=
ng
> from an old (v0.3) sourcebase.

thank god

> > - think of generalisation: 64bit, IPv6, torrent protocol deviations
>
> Something that should be "back burner" at least until basic IPv4/32 bit
> functionality is achieved - IMO...

well, I'm on a 64bit CPU and OS, so, it's big for me, i've never had it=20
working...

!plus! I am programming protocol independant, this reduces alot of htonl ca=
lls=20
and is much more simpler.

> > - make headers structured and make internal dependencies
> >
> >
> >
> >
> > - see libbt/include/bt/bt.h (it holds a header file that is supposed to
> > have all functions).
>
> This item is a *HUGE* one in my book, and in my opinion, needs to be at t=
he
> top of the priority list.

most of this is done.

> > - clean up the code
>
> Not far behind creation of a useful bt.h file in priority. Again, my
> opinion...

I must tell you that all of these above are only my big priorities...

good luck, and maybe you should check out CVS, or check the very near new=20
release for mac compatibility.

Re: [Libbt-devel] Coordinating development

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

Op donderdag 21 april 2005 03:39, schreef Emil Sit:
> On Wed, 20 April 2005 at 17:48 (-0700), Dakidd wrote:
> > No, Alien, you're not the "only one active"... I've just been effective=
ly
> > silent, quietly banging away at adding stuff to make the thing truly
>
> I don't have the time to contribute to libbt unfortunately.
> However, I am worried that there are currently many developers
> proceeding on essentially independent paths with very little
> coordination.

This is a little where you're wrong: kevin said he was only busy with 1.03=
=20
branch, and that noone else was busy with CVS. and at the time, he was righ=
t.=20

In the time i just got here, I've been the only one changing CVS. ( and i=20
don't touch the stable branch ).

and since I'm the one doing the heavy coding, I expect my say to carry=20
somewhat far.

> This could be improved probably in several ways ---
>
>   * Updating the libbt website on sf to indicate the current
>     status and future plans, perhaps adding a registration-required
>     wiki.

can't help you there

>   * Automatic e-mails after commits to CVS.

don't think it's necessary

>   * Hanging out on the IRC channel (#libbt on irc.freenode.net)

i'm already there ;-)

>   * Having someone actually be in charge: Kevin, could you clarify
>     what role you want to play in libbt?

yes, actually in charge, this is the major problem I have been having, i=20
cannot seem to contact kevin...

> In addition to these logistic items (which don't require any one to
> write any code), it might be nice if there were some sort of
> consensus on these items before people continue hacking:
>
>   * Release goals/plan
>   * API definition
>     - Model for integration with applications (separate process or
>       linked in library with appropriate I/O multiplexing)

more or less finished ( libbt/include/bt/bt.h ) + see also libbt/TODO

>   * Implementation decisions:
>     - code style
>     - portable string/binary library
>     - portable network I/O

can be usefull to agree upon.

The big problem is that there is no active maintainer, therefor I repectful=
ly=20
ask of kevin or Pandora that I be given maintainer priviledges. I will not=
=20
act without consulting the mailing list, but I can be there _every_ day to=
=20
"maintain" libbt.

I have a buddy who wanted to help me coding on libbt HEAD CVS, and he still=
=20
(more or less a month) waits for ext CVS access or for kevin to contact him=
=2E=20
I just hope he wants to help now...


As a side note, I have mostly rewrote the existing code (at least i copy pa=
ste=20
some stuff, and some stuff I leave; but there isn't a file that's been=20
changed; and some are now obsolete ).

[Libbt-devel] Coordinating development

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

On Wed, 20 April 2005 at 17:48 (-0700), Dakidd wrote:
> No, Alien, you're not the "only one active"... I've just been effectively
> silent, quietly banging away at adding stuff to make the thing truly

I don't have the time to contribute to libbt unfortunately.
However, I am worried that there are currently many developers
proceeding on essentially independent paths with very little
coordination.

This could be improved probably in several ways ---

  * Updating the libbt website on sf to indicate the current
    status and future plans, perhaps adding a registration-required
    wiki.
  * Automatic e-mails after commits to CVS.
  * Hanging out on the IRC channel (#libbt on irc.freenode.net)
  * Having someone actually be in charge: Kevin, could you clarify
    what role you want to play in libbt?

In addition to these logistic items (which don't require any one to
write any code), it might be nice if there were some sort of
consensus on these items before people continue hacking:

  * Release goals/plan
  * API definition
    - Model for integration with applications (separate process or
      linked in library with appropriate I/O multiplexing)
  * Implementation decisions:
    - code style
    - portable string/binary library
    - portable network I/O

Re: [Libbt-devel] Intro and... suggestions

[Dakidd <da...@so...>]

>Hi,
>
>I'm the only one active at this time, and I'm already doing what you
>describe,
>except i didn't commit yet, because it'll break CVS HEAD.

Hi yerself! :)

No, Alien, you're not the "only one active"... I've just been effectively
silent, quietly banging away at adding stuff to make the thing truly
cross-platform. As it stands now, it's Windows/*nix freindly (at least for
the most part) but actively hostile to those of us still stuck by
circumstances working on Macs that run an OS version below MacOS X (MacOS X
folks can use it *ALMOST* "as-is" due the the unix-like underpinnings of
the OS). I'm hacking away, slowly but steadily, at changing that with a
massive introduction of
#if TARGET_MACOS
...
#else
...
#endif
conditionals. At this point, I've done SOMETHING that has broken most of
the library in a massive way, and am working on figuring out what it was
that turned out to be "poison", but prior to the change that did it,
btcheck, and "ctx_loadfile", which was basically all it called directly,
was working 100% for me. I'll try to keep the list posted as I make
progress back to functionality.

FWIW:
I started my "battle" on version 0.3, and that's where I'm sticking at
least until I get things back to functional. It appears as though 1.3 is
*MOSTLY* very similar, at least in the "core" btxxxxx code but I haven't
wrapped my head around the various changes that come with the most recent
versions, so I'm a lot more comfortable dealing with "the old one" until I
get it functional again.

If you'd like to see my changes so far, I'm willing to crate up SOME
sections and pass them along to anyone interested, but outside of the
"core" code listed, it's pretty much a minefield, since I've had to hack
out huge swathes of utterly incompatible networking code to get a compile
at all - peer.c being particularly obnoxious for me at this point - I'd
estimate I've got more than 75% of it commented or conditionalized onto the
scrapheap - It's THAT hostile to Mac-style networking.

Such a "crate up and send" will, by neccessity, have to be done "outside
the channel" of CVS, since, quite bluntly, I'm *NOT* going to take the time
needed to re-acquire the programs and skills needed to work with CVS away
from banging on the code - never mind that committing anything in the shape
it's currently in on my machine would be something close to a terrorist
attack in terms of likely "damage" to the current codebase.

>but because you seem interested, i'll commit everything now anyway, the
>minute
>i get my own version working a little again.
>
>I can tell you that i have gotten far and I restructured everything into a
>functional system, more or less...
>
>this "library" wasn't really a library when I started, they have 3 tools (as
>the release from the 1.03 branch shows) btcheck, btlist & btget...
>
>the first 2 work more or less, the third is still not operational, because
>i'm
>working on the peer protocols now.



>The things i keep in mind:
> - get rid of libevent

Doesn't exist in MY copy of the source, but then, as mentioned, I'm working
from an old (v0.3) sourcebase.

> - think of generalisation: 64bit, IPv6, torrent protocol deviations

Something that should be "back burner" at least until basic IPv4/32 bit
functionality is achieved - IMO...

> - make headers structured and make internal dependencies




> - see libbt/include/bt/bt.h (it holds a header file that is supposed to have
>all functions).

This item is a *HUGE* one in my book, and in my opinion, needs to be at the
top of the priority list.

> - clean up the code

Not far behind creation of a useful bt.h file in priority. Again, my opinion...


Don Bruder -  da...@so...      <--- Preferred Email - unmunged
I will choose a path that's clear: I will choose Free Will! - N. Peart

Re: [Libbt-devel] bt.h interface functions

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

Op woensdag 20 april 2005 15:17, schreef Nathan Ford:
> Hey all,
>
> I was looking through libbt/include/bt/bt.h and i'm noticing that
> there are no functions to start a torrent from a file (or more
> specifically from a buffer in memory).
>
> When the time comes in the project i'm working on i'll happily code
> them in, just wanted to mention it and maybe have them added to the
> interface specification.

actually the addtorrent function gets the torrent file through curl or just=
=20
locally, so i don't really see why it's necessary to add torrents from FILE=
*=20
or memory...

Re: [Libbt-devel] bt.h interface functions

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

Op woensdag 20 april 2005 15:17, schreef Nathan Ford:
> Hey all,
>
> I was looking through libbt/include/bt/bt.h and i'm noticing that
> there are no functions to start a torrent from a file (or more
> specifically from a buffer in memory).
>
> When the time comes in the project i'm working on i'll happily code
> them in, just wanted to mention it and maybe have them added to the
> interface specification.

you mean a file as in filename or url, or you mean FILE* or strbuffer ?

[Libbt-devel] bt.h interface functions

[Nathan F. <zi...@gm...>]

Hey all,

I was looking through libbt/include/bt/bt.h and i'm noticing that
there are no functions to start a torrent from a file (or more
specifically from a buffer in memory).

When the time comes in the project i'm working on i'll happily code
them in, just wanted to mention it and maybe have them added to the
interface specification.

thx,
--Nate

[Libbt-devel] IRC channel

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

shit, i forgot:

I've registered an IRC Channel on Freenode: #libbt

anyone is invited to go there and join the talks...

AL13N

Re: [Libbt-devel] Intro and... suggestions

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

Hi,

I'm the only one active at this time, and I'm already doing what you descri=
be,=20
except i didn't commit yet, because it'll break CVS HEAD.

but because you seem interested, i'll commit everything now anyway, the min=
ute=20
i get my own version working a little again.

I can tell you that i have gotten far and I restructured everything into a=
=20
functional system, more or less...

this "library" wasn't really a library when I started, they have 3 tools (a=
s=20
the release from the 1.03 branch shows) btcheck, btlist & btget...

the first 2 work more or less, the third is still not operational, because =
i'm=20
working on the peer protocols now.


The things i keep in mind:
 - get rid of libevent
 - think of generalisation: 64bit, IPv6, torrent protocol deviations
 - make headers structured and make internal dependencies
 - see libbt/include/bt/bt.h (it holds a header file that is supposed to ha=
ve=20
all functions).
 - clean up the code

I'll clean up my own version and commit, you'll see what i mean, then...

Secondly, i've been trying to get in touch with project admin of this proje=
ct,=20
and now you've suddenly became one... odd, but what the hell

there's a guy that wanted to help (like a month back) and he asked ext CVS=
=20
access, but he never got a reply...=20

please set trove categorisation, that's been buggin me, since i got here...

I'm here because i wanted a library i could use for my own application...

oh yeah: can you read the archives of the mailing list for a month or two=20
back?

AL13N

Op woensdag 20 april 2005 07:16, schreef Pandora:
> Good morning all, Pandora here, aka synx13 on sourceforge.  I like the
> notion of a bittorrent library, since I'm planning an app that uses both
> bittorrent, and other stuff (some sort of feed protocol).  Since I'd
> therefore be making a bittorrent library anyway, I was hoping to help
> you folks out with whatever my twisted little mind could cook up.
>
> Okay, intros aside.  I had some difficulty with the CVS of the code.  To
> be honest it's gotten quite... messy.  I'd like to discuss some
> standards here.  As I fix the code there are a few things I'm not
> certain on; things that could go either way.  I have recommendations,
> but before acting on those recommendations I'd like to ask other people
> here what they'd want.
>
> 1) Object naming
>
> Many places (but not all; messy!) I see classes named this way:
> | struct btClass;
> | typedef struct btClass btClass;
>
> As elegant as that is, my syntax highlighter likes to see _t at the end
> of typenames.  It's got a point too: everywhere in C you have to
> identify what a type is (struct, union, enum, etc) right by the type
> name, except typedefs.  So adding a _t makes it easier to identify
> something as a type, and also leaves the class's formal name open for
> the name of a variable.
>
> Also, there's a trick we could use so we can even pretend we're not
> using pointers, which results in much less * writing, and really seems
> to work out elegantly when I've done it.
>
> So I propose we do this:
> | typedef struct btClass *btClass_t;
>
> instead of this:
> | struct btClass;
> | typedef struct btClass btClass;
>
> When we want to get at the implementation of btClass, we can use 'struct
> btClass' but otherwise we can toss around btClass_t things like they
> were opaque candy.
>
> | btClass  *someFunction(btClass *, btClass **); //The old interface
> | btClass_t someFunction(btClass_t, btClass_t*); //The new interface
>
> So... what about that?  Obey my syntax highlighter and use _t?  Typedefs
> to all opaque structures as pointers, not just aliases?  I'm going
> forward with this system unless anybody brings forth any issues.  Okay?
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time involved in
> creating, integrating, and deploying reporting solutions. Free runtime
> info, new features, or free trial, at:
> http://www.businessobjects.com/devxi/728
> _______________________________________________
> Libbt-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libbt-devel

[Libbt-devel] Intro and... suggestions

[Pandora <pub...@pa...>]

Good morning all, Pandora here, aka synx13 on sourceforge.  I like the
notion of a bittorrent library, since I'm planning an app that uses both
bittorrent, and other stuff (some sort of feed protocol).  Since I'd
therefore be making a bittorrent library anyway, I was hoping to help
you folks out with whatever my twisted little mind could cook up.

Okay, intros aside.  I had some difficulty with the CVS of the code.  To
be honest it's gotten quite... messy.  I'd like to discuss some
standards here.  As I fix the code there are a few things I'm not
certain on; things that could go either way.  I have recommendations,
but before acting on those recommendations I'd like to ask other people
here what they'd want.

1) Object naming
Many places (but not all; messy!) I see classes named this way:
| struct btClass;
| typedef struct btClass btClass;
As elegant as that is, my syntax highlighter likes to see _t at the end
of typenames.  It's got a point too: everywhere in C you have to
identify what a type is (struct, union, enum, etc) right by the type
name, except typedefs.  So adding a _t makes it easier to identify
something as a type, and also leaves the class's formal name open for
the name of a variable.

Also, there's a trick we could use so we can even pretend we're not
using pointers, which results in much less * writing, and really seems
to work out elegantly when I've done it.

So I propose we do this:
| typedef struct btClass *btClass_t;
instead of this:
| struct btClass;
| typedef struct btClass btClass;

When we want to get at the implementation of btClass, we can use 'struct
btClass' but otherwise we can toss around btClass_t things like they
were opaque candy.

| btClass  *someFunction(btClass *, btClass **); //The old interface
| btClass_t someFunction(btClass_t, btClass_t*); //The new interface

So... what about that?  Obey my syntax highlighter and use _t?  Typedefs
to all opaque structures as pointers, not just aliases?  I'm going
forward with this system unless anybody brings forth any issues.  Okay?

Re: [Libbt-devel] anyone alive?

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

Alien <ali...@us...> wrote:
> this mailing list seemed to have died out, and no devel seem to answer, is 
> there a problem with my email, or are you guys not interested anymore?

	Alien,
		I'm still interested, I just don't have much time right now
:)

		- Tyler

Re: [Libbt-devel] anyone alive?

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

Hey!

On Wed, Apr 13, 2005 at 01:11:50PM +0200, Alien wrote:
> this mailing list seemed to have died out, and no devel seem to
> answer, is there a problem with my email, or are you guys not
> interested anymore?

Well, I've got lots of other things going on, and I've also begun to
think twice about using libbt as the foundation in a full-featured BT
client, since the focus is slightly shifted towards integration of BT
in applications rather than a feature-complete "reference" library.
But I haven't decided either way, and as I don't have a lot of spare
time I guess I wont be working hard on that client this week either.
:)


//Peter

[Libbt-devel] anyone alive?

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

this mailing list seemed to have died out, and no devel seem to answer, is=
=20
there a problem with my email, or are you guys not interested anymore?

Alien

Re: [Libbt-devel] btget bugs...

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

Op woensdag 23 maart 2005 09:23, schreef Greg M. Kurtzer:
> Sorry, I am not on the email list, so please CC my in any potential
> replies.

sorry to be so slow, i figured the maintainer of the stable branch would=20
answer, but even i have difficulty reaching him, i don't know if he had put=
=20
this in CVS or not.

I have been granted permission to restructure current CVS HEAD. and since i=
'm=20
always looking for help, i wanted to ask for your help in changing libbt to=
=20
make a real shared/static library for inclusions in other projects.

thanks for the patch in any case

> I am having some problems getting btget to work properly. At the moment, I
> can't get it to upload to other bt peers or seed properly. It appears to
> "see" the other peer, but it never sends anything.
>
> Also, it seems to be a bit slower then the standard python based bittorre=
nt
> utilities.
>
> It is running on a caos2 system which utilizes gcc 3.4.3, glibc 2.3.3 and
> linux-2.6.11.5. I am using libbt version 1.03.
>
>
>
> I also made the following change to reneable the -q option in btget (not
> sure if it is correct, but it seems to be working right):
>
> diff -ru libbt-1.03/src/btget.c libbt-1.03.gmk/src/btget.c
> --- libbt-1.03/src/btget.c      2004-04-19 15:11:28.000000000 -0700
> +++ libbt-1.03.gmk/src/btget.c  2005-03-23 00:17:25.663976440 -0800
> @@ -586,11 +586,10 @@
>             }
>         }
>
> -#if 0
>         if (optquiettmo > 0) {
>             static int lastcheck =3D 0;
>             static int donetime  =3D 0;
> -           int check =3D (ctx->complete =3D=3D 1) && peer_allcomplete(
> &ctx->downloads[0]->peerset); +           int check =3D (complt =3D=3D
> ctx->downloads[0]->fileset.npieces ) && peer_allcomplete(
> &ctx->downloads[0]->peerset); if (check) {
>                 if (!lastcheck) {
>                     printf("=3D=3D=3D All peers done!\n");
> @@ -604,7 +603,6 @@
>             }
>             lastcheck =3D check;
>         }
> -#endif
>      }
>
>      return 0;

[Libbt-devel] exeem protocol

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

is there anyone who wants to take care of that?

ask on if the protocol is free and ask exeem for doc regarding it, or rever=
se=20
engineer it...

[Libbt-devel] btget bugs...

[Greg M. K. <gm...@ru...>]

Sorry, I am not on the email list, so please CC my in any potential replies.

I am having some problems getting btget to work properly. At the moment, I
can't get it to upload to other bt peers or seed properly. It appears to "see"
the other peer, but it never sends anything.

Also, it seems to be a bit slower then the standard python based bittorrent 
utilities.

It is running on a caos2 system which utilizes gcc 3.4.3, glibc 2.3.3 and
linux-2.6.11.5. I am using libbt version 1.03.



I also made the following change to reneable the -q option in btget (not sure
if it is correct, but it seems to be working right):

diff -ru libbt-1.03/src/btget.c libbt-1.03.gmk/src/btget.c
--- libbt-1.03/src/btget.c      2004-04-19 15:11:28.000000000 -0700
+++ libbt-1.03.gmk/src/btget.c  2005-03-23 00:17:25.663976440 -0800
@@ -586,11 +586,10 @@
            }
        }

-#if 0
        if (optquiettmo > 0) {
            static int lastcheck = 0;
            static int donetime  = 0;
-           int check = (ctx->complete == 1) && peer_allcomplete( &ctx->downloads[0]->peerset);
+           int check = (complt == ctx->downloads[0]->fileset.npieces ) && peer_allcomplete( &ctx->downloads[0]->peerset);
            if (check) {
                if (!lastcheck) {
                    printf("=== All peers done!\n");
@@ -604,7 +603,6 @@
            }
            lastcheck = check;
        }
-#endif
     }

     return 0;

-- 
Greg M. Kurtzer
http://runlevelzero.net/
http://caosity.org/
http://warewulf-cluster.org/

        -- Do not look anywhere for truth, for all that is needed is to refrain 
                                                from allowing concepts to arise

[Libbt-devel] library API discussion

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

ok, i need feedback and lots of it.

i have committed a file libbt/include/bt/bt.h which is not yet used by the=
=20
code in current CVS.

this file (and a few others it depends on) will be installed on the system =
if=20
someone was to install the devel package. this file has to contain all the=
=20
functions that can be used by other projects to use libbt.

i'm sure i forgot lots of functions or group of functions or functionality=
=20
that could be required by projects depending on us.

I now want this file and API to be perfected before i go on implementing it.

when this file is finished (more or less), there should be a file explainin=
g=20
how to use this library and documentation regarding the API of this library=
=20
on the site, as well as a manual file should be made for the same purpose.=
=20
the manual could be viewable on the site as well.

for this purpose i want everyone to give their thoughts and suggest functio=
ns,=20
while this thread will continue i'll update the libbt/include/bt/bt.h file =
as=20
often as i can to reflect these suggestions and functionality.

thanks in advance.

[Libbt-devel] ayeeeeee error error

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

i may have non-intentionally committed files that aren't ready yet and have=
=20
broken CVS.

please can someone look at include/strbuf.h and include/types.h and for the=
se=20
files, revert back to last change.

btw: if non-intentionally some other things are broken, please notify me...

Re: [7] [Libbt-devel] added header files that will be installed

[Kevin S. <ke...@an...>]

Peter Stuge wrote:

>On Tue, Mar 08, 2005 at 11:35:31PM -0800, Kevin Smathers wrote:
>  
>
>>Peter Stuge wrote:
>>    
>>
>>>No, listenport is not required, if we're going to do the networking
>>>in libbt I strongly suggest that we only use a single port per
>>>application, and by default one in the dynamic port range as defined
>>>by IANA, 49152 through 65536. Start from the bottom and try
>>>allocating upwards.
>>>      
>>>
>>People who operate firewalls generally prefer to know what it is
>>that they are opening up a hole for.
>>    
>>
>
>We know that we can't tell anything about the traffic we're opening
>holes for unless we actually inspect it. A simple stateful packet
>filter will not and can not know what the application is doing and
>assuming that a certain port only carries certain traffic is silly.
>
>  
>
The way that the protocol specification reads, it is difficult to 
imagine an effective proxy for BitTorrent.  It really is designed solely 
as a peer to peer protocol.  Traversing a NAT gateway and firewall by 
opening up the appropriate port is the most widely supported way to 
connect on a peer to peer level.  A specialized proxy or NAT plug-in, if 
an appropriate one is constructed, would improve security by adding a 
boundary layer, but experience with SIP and other gateway protocols 
tells me that even hard pushing by well monied champions can fail to 
penetrate deeply into the router market, and BitTorrent is grass-roots.  
If you want to pursue it then more power to you, but I have different 
priorities.

>>>And most importantly a dynamic port fits the application. This is
>>>not a server that peers will try to connect blindly to as a result
>>>of a user command, instead peer lists come from the tracker and so
>>>ports do not matter.
>>>      
>>>
>>Bram has a lot of experience with actual deployments.  Pretend that
>>he knows what he is doing.
>>    
>>
>
>You can't seriously mean that arbitrary allocation of ports in the
>IANA reserved range by individual software manufacturers is a good
>thing?  Further, someone mentioned a post by Bram in which he
>recognized that this particular part of the protocol documentation
>was unfortunate. It's a non-issue AFAICS, since all clients always
>tell the tracker which port they're using.
>
>  
>
Actually I do think it is a good thing that software developers allocate 
ports in the absence of IANA's blessing, but that is a different and 
very philosophical discussion. 

>As for firewalls, that's another issue, I think the best solution
>would be for Bram to get a port allocated by IANA and then all BT
>software could use that as the default. Until then, nothing we do
>in libbt will be of much help for firewall operators..
>
>Plus; users should be able to pick the port if they want.
>
>  
>
On this we agree; without a doubt users should be able to pick their own 
ports. 

Re: [7] [Libbt-devel] added header files that will be installed

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

On Tue, Mar 08, 2005 at 11:35:31PM -0800, Kevin Smathers wrote:
> Peter Stuge wrote:
> >
> >No, listenport is not required, if we're going to do the networking
> >in libbt I strongly suggest that we only use a single port per
> >application, and by default one in the dynamic port range as defined
> >by IANA, 49152 through 65536. Start from the bottom and try
> >allocating upwards.
> 
> People who operate firewalls generally prefer to know what it is
> that they are opening up a hole for.

We know that we can't tell anything about the traffic we're opening
holes for unless we actually inspect it. A simple stateful packet
filter will not and can not know what the application is doing and
assuming that a certain port only carries certain traffic is silly.


> Follow the protocol spec, use the specified port range.

I prefer to follow IANA and use a non-reserved port.

Plus;

> >And most importantly a dynamic port fits the application. This is
> >not a server that peers will try to connect blindly to as a result
> >of a user command, instead peer lists come from the tracker and so
> >ports do not matter.
> 
> Bram has a lot of experience with actual deployments.  Pretend that
> he knows what he is doing.

You can't seriously mean that arbitrary allocation of ports in the
IANA reserved range by individual software manufacturers is a good
thing?  Further, someone mentioned a post by Bram in which he
recognized that this particular part of the protocol documentation
was unfortunate. It's a non-issue AFAICS, since all clients always
tell the tracker which port they're using.

As for firewalls, that's another issue, I think the best solution
would be for Bram to get a port allocated by IANA and then all BT
software could use that as the default. Until then, nothing we do
in libbt will be of much help for firewall operators..

Plus; users should be able to pick the port if they want.


//Peter

Re: [7] [Libbt-devel] added header files that will be installed

[Kevin S. <ke...@an...>]

Peter Stuge wrote:

>On Fri, Feb 11, 2005 at 09:09:28AM +0100, Alien wrote:
>  
>
>>bt.h also includes bttypes.h so it's easier not to make mistakes
>>    
>>
>
>>From btTorrent:
>
>    int listenport;             /* is this required??? */
>
>No, listenport is not required, if we're going to do the networking
>in libbt I strongly suggest that we only use a single port per
>application, and by default one in the dynamic port range as defined
>by IANA, 49152 through 65536. Start from the bottom and try
>allocating upwards.
>
>  
>
People who operate firewalls generally prefer to know what it is that 
they are opening up a hole for.  Follow the protocol spec, use the 
specified port range.

>And most importantly a dynamic port fits the application. This is not
>a server that peers will try to connect blindly to as a result of a
>user command, instead peer lists come from the tracker and so ports
>do not matter.
>
>  
>
Bram has a lot of experience with actual deployments.  Pretend that he 
knows what he is doing.

>--8<-- docs/protocol.txt, about communication between peers
>Next comes the 20 byte sha1 hash of the bencoded form of the 'info'
>value from the metainfo file. (This is the same value which is
>announced as info_hash to the tracker, only here it's raw instead of
>quoted here). If both sides don't send the same value, they sever the
>connection. The one possible exception is if a downloader wants to do
>multiple downloads over a single port, they may wait for incoming
>connections to give a download hash first, and respond with the same
>one if it's in their list.
>-->8--
>
>This sounds good to me.
>
>
>//Peter
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Libbt-devel mailing list
>Lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libbt-devel
>  
>

Re: [98] [Libbt-devel] role of libevent

[Kevin S. <ke...@an...>]

Abstraction is more important than speed in this case.  The client 
doesn't spend any significant proportion of its time in libevent(), 
poll() or select() regardless of the implementation.  The asynchrony API 
in libevent() is such that we can provide a well documented and proven 
interface for integrating socket handling between a calling program and 
the library.  Something like libevent() is the only realistic API for 
in-process BitTorrent libraries, which is why I had Emil take over the 
top of the tree.  The 1.0 branch can only ever except to become an 
out-of-process API.

Cheers,
-kls
Alien wrote:

>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 
>directly, really, in fact with using select directly, you should see a slight 
>performance increase.
>  
>