Ruby BitTorrent

Has anybody started a Ruby BitTorrent transfer library? I wanted to start a RubyForge project for one but I hate duplicating the worthy efforts of others.

I thought of starting off with a simple layer of glue around libbt (http://libbt.sf.net).
Any thoughts, ideas?

/Curne

···

--
Mailing lists confuse me. Often I don't recognize my own posts and I set about writing a flaming reply where I violently disagree. [curne@curnomatic.dk]

Has anybody started a Ruby BitTorrent transfer library? I wanted to
start a RubyForge project for one but I hate duplicating the worthy
efforts of others.

Yep, it's me :wink:

http://ntecs.de/viewcvs/viewcvs/BitTorrent/

I've started with the client protocol, but that in a very ungood shape,
and is not yet commited.

I thought of starting off with a simple layer of glue around libbt
(http://libbt.sf.net).
Any thoughts, ideas?

hm, why not write BT in pure Ruby?

Regards,

  Michael

···

On Thu, Nov 04, 2004 at 06:13:17PM +0900, Simon Conrad-Armes wrote:

(Curne) Simon Conrad-Armes ha scritto:

Has anybody started a Ruby BitTorrent transfer library? I wanted to start a RubyForge project for one but I hate duplicating the worthy efforts of others.

I thought of starting off with a simple layer of glue around libbt (http://libbt.sf.net).
Any thoughts, ideas?

/Curne

it seem nobody still named this:
http://aversa.rubyforge.org/
linked from bt.rubyforge.org

Has anybody started a Ruby BitTorrent transfer library? I wanted to
start a RubyForge project for one but I hate duplicating the worthy
efforts of others.

Yep, it's me :wink:

http://ntecs.de/viewcvs/viewcvs/BitTorrent/

I've started with the client protocol, but that in a very ungood shape,
and is not yet commited.

That's cool tho. I figured someone out there must have gotten the same idea :slight_smile:
Are you writing a full client or a library? From the code in repo it is difficult to see.

I thought of starting off with a simple layer of glue around libbt
(http://libbt.sf.net).
Any thoughts, ideas?

hm, why not write BT in pure Ruby?

More work... But I suppose you are right. Coding RubyC for I/O-centric stuff is an old habit based on performance superstition. From other implementation in other than pure C, I have seen greatly varying transfer rates... But you have the semi-working code. Have you noticed any performance issues?

···

On Nov 4, 2004, at 11:33 AM, Michael Neumann wrote:

On Thu, Nov 04, 2004 at 06:13:17PM +0900, Simon Conrad-Armes wrote:

--
Mailing lists confuse me. Often I don't recognize my own posts and set about writing a flaming reply where I violently disagree. [curne@curnomatic.dk]

Nice. I thought about doing that too. :slight_smile:

But I got no further than the name[1], then my other ruby projects
started to call for attention. :confused:

Anyway, all I wanted to say was; if you can do it as a library with a
seperate FE; then it would be great. Your idea about a great frontend
may not be the same a mine, but I'd still be able to use your backend
code...

client = BitTorrent.new(...)

:wink:

//F
[1] rottenr. With some tagline like 'more rotten than usual'. Name
formed from switching 'r' and 't', since I wanted a name starting with
'r'.

···

On Thu, 4 Nov 2004 19:33:23 +0900, Michael Neumann <mneumann@ntecs.de> wrote:

On Thu, Nov 04, 2004 at 06:13:17PM +0900, Simon Conrad-Armes wrote:
> Has anybody started a Ruby BitTorrent transfer library? I wanted to
> start a RubyForge project for one but I hate duplicating the worthy
> efforts of others.

Yep, it's me :wink:

From the page: "Aversa is a little utility for creating and viewing BitTorrent metainfo files."

Maybe some useful code, but I think what be even more useful was an actual package. I was thinking along the lines of the following feature set:

- completely isolated library or backend
- off-line mode (run in background)
- front-end can reconnect to backend
- upload/download cap (max upload setting)
- queueing (max downloads at a time)

It would be cool if the backend serviced frontends through DRB.

/Curne

···

On Nov 4, 2004, at 1:53 PM, gabriele renzi wrote:

(Curne) Simon Conrad-Armes ha scritto:

Has anybody started a Ruby BitTorrent transfer library? I wanted to start a RubyForge project for one but I hate duplicating the worthy efforts of others.
I thought of starting off with a simple layer of glue around libbt (http://libbt.sf.net).
Any thoughts, ideas?
/Curne

it seem nobody still named this:
http://aversa.rubyforge.org/
linked from bt.rubyforge.org

--
If vegatarians eat vegetables, what do humanitarians eat?
[curne@curnomatic.dk] [http://curnomatic.dk/\] [curne@jabber.org]

Yup, Ikkei and I - actually, about 95% of the work is Ikkei's - have
been working on Aversa for a while. We've got much of a tracker done,
and Ikkei has done a nice job of pulling everything out into modules.
He's even written a C extension for the BEncoder:

http://rubyforge.org/cgi-bin/viewcvs.cgi/aversa/ext/?cvsroot=aversa

Good times,

Tom

···

On Thu, 2004-11-04 at 07:53, gabriele renzi wrote:

(Curne) Simon Conrad-Armes ha scritto:
> Has anybody started a Ruby BitTorrent transfer library? I wanted to
> start a RubyForge project for one but I hate duplicating the worthy
> efforts of others.
>
it seem nobody still named this:
http://aversa.rubyforge.org/
linked from bt.rubyforge.org

>>Has anybody started a Ruby BitTorrent transfer library? I wanted to
>>start a RubyForge project for one but I hate duplicating the worthy
>>efforts of others.
>
>Yep, it's me :wink:
>
>http://ntecs.de/viewcvs/viewcvs/BitTorrent/
>
>I've started with the client protocol, but that in a very ungood shape,
>and is not yet commited.

That's cool tho. I figured someone out there must have gotten the same
idea :slight_smile:
Are you writing a full client or a library? From the code in repo it is
difficult to see.

My initial goal was to write a full client (but no tracker). But I
canceled it in favor of other more important things.

>>I thought of starting off with a simple layer of glue around libbt
>>(http://libbt.sf.net).
>>Any thoughts, ideas?
>
>hm, why not write BT in pure Ruby?
>

More work... But I suppose you are right. Coding RubyC for I/O-centric
stuff is an old habit based on performance superstition. From other
implementation in other than pure C, I have seen greatly varying
transfer rates... But you have the semi-working code. Have you noticed
any performance issues?

But the original BT was written in Python? I assume that there's no big
difference between Python and Ruby in performance (except that Python
has native threads).

Nope, I never got that far. Okay, I am able to read a .bittorrent
metainfo file, connect to a tracker and then finally connect to a peer
and communicate with it a bit. The peer protocol is not yet 100%
complete, but that should be very easy to do. The hard part is really
the application logic (managing the connections, choking, unchoking
etc.). If someone is interested to write this, then I would take the
time to finish the low-level peer protocol stuff.

Regards,

  Michael

···

On Thu, Nov 04, 2004 at 12:58:09PM +0100, Simon Conrad-Armes wrote:

On Nov 4, 2004, at 11:33 AM, Michael Neumann wrote:
>On Thu, Nov 04, 2004 at 06:13:17PM +0900, Simon Conrad-Armes wrote:

Me too :wink:

Regards,

  Michael

···

On Thu, Nov 04, 2004 at 09:19:47PM +0900, Fredrik Jagenheim wrote:

On Thu, 4 Nov 2004 19:33:23 +0900, Michael Neumann <mneumann@ntecs.de> wrote:
> On Thu, Nov 04, 2004 at 06:13:17PM +0900, Simon Conrad-Armes wrote:
> > Has anybody started a Ruby BitTorrent transfer library? I wanted to
> > start a RubyForge project for one but I hate duplicating the worthy
> > efforts of others.
>
> Yep, it's me :wink:

Nice. I thought about doing that too. :slight_smile:

But I got no further than the name[1], then my other ruby projects
started to call for attention. :confused:

From the page: "Aversa is a little utility for creating and viewing
BitTorrent metainfo files."

Yup, that's all the current release does.

Maybe some useful code, but I think what be even more useful was an
actual package. I was thinking along the lines of the following feature
set:

- completely isolated library or backend
- off-line mode (run in background)
- front-end can reconnect to backend
- upload/download cap (max upload setting)
- queueing (max downloads at a time)

Right on! A full client, a full tracker... all that good stuff.

It would be cool if the backend serviced frontends through DRB.

Sweet!

Tom

···

On Thu, 2004-11-04 at 10:18, Simon Conrad-Armes wrote:

On Nov 4, 2004, at 1:53 PM, gabriele renzi wrote:

Has anybody started a Ruby BitTorrent transfer library? I wanted to
start a RubyForge project for one but I hate duplicating the worthy
efforts of others.

Yep, it's me :wink:

http://ntecs.de/viewcvs/viewcvs/BitTorrent/

I've started with the client protocol, but that in a very ungood shape,
and is not yet commited.

That's cool tho. I figured someone out there must have gotten the same
idea :slight_smile:
Are you writing a full client or a library? From the code in repo it is
difficult to see.

My initial goal was to write a full client (but no tracker). But I
canceled it in favor of other more important things.

I thought of starting off with a simple layer of glue around libbt
(http://libbt.sf.net).
Any thoughts, ideas?

hm, why not write BT in pure Ruby?

More work... But I suppose you are right. Coding RubyC for I/O-centric
stuff is an old habit based on performance superstition. From other
implementation in other than pure C, I have seen greatly varying
transfer rates... But you have the semi-working code. Have you noticed
any performance issues?

But the original BT was written in Python? I assume that there's no big
difference between Python and Ruby in performance (except that Python
has native threads).

Like I said. I was just being superstitious and paranoid :slight_smile:
Nevermind

Nope, I never got that far. Okay, I am able to read a .bittorrent
metainfo file, connect to a tracker and then finally connect to a peer
and communicate with it a bit. The peer protocol is not yet 100%
complete, but that should be very easy to do. The hard part is really
the application logic (managing the connections, choking, unchoking
etc.). If someone is interested to write this, then I would take the
time to finish the low-level peer protocol stuff.

Micheal, do you want to start a Rubyforge project? I will certianly join in, and it sounds as if a few other people would like to too. The best thing about registering it as a project is that we can create a mailing list to work on it.

/Curne

···

On Nov 4, 2004, at 1:38 PM, Michael Neumann wrote:

On Thu, Nov 04, 2004 at 12:58:09PM +0100, Simon Conrad-Armes wrote:

On Nov 4, 2004, at 11:33 AM, Michael Neumann wrote:

On Thu, Nov 04, 2004 at 06:13:17PM +0900, Simon Conrad-Armes wrote:

--
POLS is in the eye of the beholder. The difference is the community's intent to converge or diverge. I choose Ruby. --curne@curnomatic.dk

Wow! That's really cool!

Regards,

  Michael

···

On Fri, Nov 05, 2004 at 12:34:31AM +0900, Tom Copeland wrote:

On Thu, 2004-11-04 at 10:18, Simon Conrad-Armes wrote:
> On Nov 4, 2004, at 1:53 PM, gabriele renzi wrote:
> From the page: "Aversa is a little utility for creating and viewing
> BitTorrent metainfo files."

Yup, that's all the current release does.

> Maybe some useful code, but I think what be even more useful was an
> actual package. I was thinking along the lines of the following feature
> set:
>
> - completely isolated library or backend
> - off-line mode (run in background)
> - front-end can reconnect to backend
> - upload/download cap (max upload setting)
> - queueing (max downloads at a time)

Right on! A full client, a full tracker... all that good stuff.

Oh, sorry, I should have said "a full client, a full tracker... that's
the goal of Aversa, too." Because we're certainly not there yet :slight_smile:

Yours,

Tom

···

On Thu, 2004-11-04 at 10:43, Michael Neumann wrote:

> > - completely isolated library or backend
> > - off-line mode (run in background)
> > - front-end can reconnect to backend
> > - upload/download cap (max upload setting)
> > - queueing (max downloads at a time)
>
> Right on! A full client, a full tracker... all that good stuff.

Wow! That's really cool!