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.
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?
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'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
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]
But I got no further than the name[1], then my other ruby projects
started to call for attention.
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(...)
//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.
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
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:
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
>
>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
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:
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
Nice. I thought about doing that too.
But I got no further than the name[1], then my other ruby projects
started to call for attention.
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:
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'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
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
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
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
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.