The BitTorrent dilemma
Alex Taylor
growing more so recently.
AFAIK, there are basically three clients that are usable under OS/2:
BitTornado, CTorrent (Ehrlich port), and Azureus (SWTSwing port). All have
their own problems.
BitTornado worked for me for a long time, but lately I've been finding more
and more torrents and/or trackers that it just doesn't work with. I'm not
sure what's wrong, but it shows all the symptoms of missing announce-list
support, at least in the command-line version. This is strange, though,
because announce-list support is supposed to be one of BitTornado's
marquee features (it was invented by the BitTornado developer, after all).
But maybe it's only present in the GUI version (which is unusable under
OS/2)?
I think BitTornado also lacks DHT support, which is becoming more and more
widely used.
Another problem with BitTornado is lack of >2GB file support, as (last I
checked) it wouldn't work with the kLIBC ports of Python.
CTorrent (more correctly, Enhanced CTorrent) is probably the best OS/2
client at the moment. It works very well within its limitations.
Unfortunately:
- It hasn't been updated since version 1.3.4, and Enhanced CTorrent is now
up to version 3.3.2. I've tried building the latest version, and while
can I produce an executable, it doesn't actually work (I don't know why).
It's also missing the OS/2-specific enhancements that ctorrent9.exe
includes, obviously.
- It doesn't include DHT support, which is a major limitation these days.
- It doesn't include announce-list support, ditto.
This means that ctorrent9.exe is simply unusable for a large number of
torrents. Evn more unfortunately, the source code patches for ctorrent9.exe
don't seem to be available anywhere.
Another problem with CTorrent is that it's a single-torrent command-line
app, which means a separate instance has to be run for every single torrent.
This clutters up the desktop and/or window list, making it hard to simply
run multiple torrents in the background in a non-intrusive way. It also
tends to peg the CPU at 100% when it's checking torrent files, which also
makes multiple background instances problematic.
Azureus does include both announce-list and DHT support, but I don't think
it supports >2GB files (or more correctly, OS/2 Java doesn't). It's also
unstable and suffers from some infuriating bugs. And, being a very large
Java app, it's pretty resource-hungry. These problems make it more or less
impossible to just run it quietly in the background, which is part of the
point of a BitTorrent client in the first place.
In light of these problems, I've spent quite some time looking for an
alternative. I'd particularly like something that's (a) graphical,
multi-threaded, and resource-light, making it easy to run in the background
with multiple torrents; (b) supports DHT; (c) supports the announce-list
(multiple trackers) feature, and (d) supports NAT traversal.
But I've had no luck at all. The problem is, most open-source BitTorrent
clients are written in C++ (which I don't know very well) and are largely
based on the libtorrent library, which can't be built without Boost (which
doesn't seem to be available on OS/2). Many of them require versions of
GTK, QT, and/or KDE which aren't available on OS/2 either. (qBittorrent,
for instance, which looks almost perfect for my criteria, requires QT4.)
I'm desperate enough at this point that I'm seriously considering trying to
WRITE my own BitTorrent client. This presents its own problems, of course;
the BitTorrent protocol is pretty fearsomely complicated, and the
specifications are all awfully vague on details about how things should be
implemented. Still, an idea I've had is to write a REXX-callable
BitTorrent library which could then be used by applications. This might
be quite useful. Graphical or command-line REXX programs could then be
written to use it, giving us quite a lot of flexibility.
I realize this post has turned into more of a long-winded rant than anything
else, but I'd really like to hear thoughts and ideas from other people. Is
there anything I'm overlooking? Is there some easier alternative available?
--
Alex Taylor
Fukushima, Japan
http://www.socis.ca/~ataylo00
Please take off hat when replying.
Paul Smedley
On Sat, 9 May 2009 02:47:02 UTC, "Alex Taylor"
<mai...@reply.to.address> wrote:
> But I've had no luck at all. The problem is, most open-source BitTorrent
> clients are written in C++ (which I don't know very well) and are largely
> based on the libtorrent library, which can't be built without Boost (which
> doesn't seem to be available on OS/2). Many of them require versions of
> GTK, QT, and/or KDE which aren't available on OS/2 either. (qBittorrent,
> for instance, which looks almost perfect for my criteria, requires QT4.)
I have Boost building here - if you point me to libtorrent, I'll take
a look at it.
qBittorrent might be easy enough to port soon, assuming we get enough
sponsorship for http://qt.netlabs.org
--
Cheers,
Paul.
Tellerbop
I use this for years and never let me down.."P
new ACTorrent ftp://i...@79.135.201.38/dcincoming/act027t2.rar
It's based on ctorrent:
Enhanced CTorrent dnh3.3.2 [ACT 0.2.7 t2]
Original code Copyright: YuHong(992126018601033)
WARNING: THERE IS NO WARRANTY FOR CTorrent. USE AT YOUR OWN RISK!!!
Hope this is good for you to...
--
With the best regards from the Netherlands,
Alex Taylor
<pauld...@despamsmedley.id.au> wrote:
> > But I've had no luck at all. The problem is, most open-source
> >BitTorrent clients are written in C++ (which I don't know very well) and
> >are largely based on the libtorrent library, which can't be built without
> >Boost (which doesn't seem to be available on OS/2). Many of them require
> >versions of GTK, QT, and/or KDE which aren't available on OS/2 either.
> >(qBittorrent, for instance, which looks almost perfect for my criteria,
> >requires QT4.)
> I have Boost building here - if you point me to libtorrent, I'll take
> a look at it.
Ooh, that would be awesome.
http://www.rasterbar.com/products/libtorrent/
(Not to be confused with the unrelated libtorrent-Rakshasa, which is only a
beta and not very widely used.)
> qBittorrent might be easy enough to port soon, assuming we get enough
> sponsorship for http://qt.netlabs.org
I must go and donate, then. :)
Thanks!
Alex Taylor
> I use this for years and never let me down.."P
> new ACTorrent ftp://i...@79.135.201.38/dcincoming/act027t2.rar
> It's based on ctorrent:
>
> Enhanced CTorrent dnh3.3.2 [ACT 0.2.7 t2]
Interesting. Whose work is this?
I'll take a look at it, although it presumably suffers from CTorrent's
limitations (i.e. no DHT, no real announce-list support, etc.)...
Tellerbop
Some Russian guy is working on it.
Don't have any email from him, but i speak to him through Irc.
If you can tell me what exactly you wanted in, i can ask him....
Also some russian is working on Rtorrent
*** rTorrent 0.8.4/0.12.4***
Enhanced CTorrent dnh3.3.2 [ACT 0.2.7 t2]
Original code Copyright: YuHong(992126018601033)
WARNING: THERE IS NO WARRANTY FOR CTorrent. USE AT YOUR OWN RISK!!!
On Sat, 9 May 2009 10:07:01 UTC, "Alex Taylor"
<mai...@reply.to.address> wrote:
> On Sat, 9 May 2009 07:46:50 UTC, "Tellerbop" <Tell...@wint.nl> wrote:
>
> > I use this for years and never let me down.."P
> > new ACTorrent ftp://i...@79.135.201.38/dcincoming/act027t2.rar
> > It's based on ctorrent:
> >
> > Enhanced CTorrent dnh3.3.2 [ACT 0.2.7 t2]
>
>
> Interesting. Whose work is this?
>
> I'll take a look at it, although it presumably suffers from CTorrent's
> limitations (i.e. no DHT, no real announce-list support, etc.)...
>
--
Alex Taylor
> Hi Alex,
> Some Russian guy is working on it.
> Don't have any email from him, but i speak to him through Irc.
> If you can tell me what exactly you wanted in, i can ask him....
No, I was just wondering why it's so hidden/obscure... it's not on Hobbes
or anywhere, from what I can tell.
Anyway, it looks really good after I ran it through some brief paces.
I think it actually maybe does support DHT after all, and it certainly
works with various torrents that ctorrent9.exe couldn't handle. Also,
it doesn't peg the CPU at 100% for several minutes when checking an
existing file.
So, thanks!
Ian Manners
> No, I was just wondering why it's so hidden/obscure... it's not on Hobbes
> or anywhere, from what I can tell.
http://www.os2site.com/sw/internet/peer_peer/index.html
Go down to ctor.....
Ian Manners
Oops, and also act....
:-)
Cheers
Karlheinz Schmidthaus
> BitTorrent has always been a bit problematic on OS/2, but it seems to be
> growing more so recently.
>
> checked) it wouldn't work with the kLIBC ports of Python.
>
This is not true. I'm using BitTornado-cvs-318 with the latest Python
build and download a Ubuntu DVD ISO Image without problems.
Alex Taylor
wrote:
Does the latest Python now include curses support then?
Paul Smedley
On Mon, 11 May 2009 08:47:02 UTC, "Alex Taylor"
<mai...@reply.to.address> wrote:
> On Sun, 10 May 2009 11:43:13 UTC, Karlheinz Schmidthaus <ksng...@ksit.de>
> wrote:
>
> > > BitTorrent has always been a bit problematic on OS/2, but it seems to be
> > > growing more so recently.
> > >
> > > Another problem with BitTornado is lack of >2GB file support, as (last I
> > > checked) it wouldn't work with the kLIBC ports of Python.
> > >
> >
> > This is not true. I'm using BitTornado-cvs-318 with the latest Python
> > build and download a Ubuntu DVD ISO Image without problems.
>
>
> Does the latest Python now include curses support then?
It does, not sure how well it works though.
Looking at libtorrent-rasterbar-0.14.3 right now,
http://btg.berlios.de/ (which uses libtorrent) sounds interesting,
particularly as it seems to have a SDL and web client
--
Cheers,
Paul.
Bart
I think I shall use it instead of ctorrent from now on.
Thanks for bringing up this topic Alex!
Bart
Toronto
Andy
I tried updating the latest ctorrent (dtorrent I think the version is)
and I too only got an executable that launches but doesn't actually do
anything. I then went through and updated all the OS/2 specific
changes and thought that was probably it as it made changes to binary
vs. text in places. It still didn't work any better. I then looked
at the options and found the verbose option and found:
Error from select: Invalid argument
which I haven't gotten past yet.
Andy
--
Marty
Probably an issue of trying to use a network socket like a file.
--
[Reverse the parts of the e-mail address to reply.]
Alex Taylor
<pauld...@despamsmedley.id.au> wrote:
> > > This is not true. I'm using BitTornado-cvs-318 with the latest Python
> > > build and download a Ubuntu DVD ISO Image without problems.
> >
> > Does the latest Python now include curses support then?
> It does, not sure how well it works though.
Oh, cool. I should check that out then.
> Looking at libtorrent-rasterbar-0.14.3 right now,
> http://btg.berlios.de/ (which uses libtorrent) sounds interesting,
> particularly as it seems to have a SDL and web client
That does sound interesting! Thanks again.
Alex Taylor
<nospam-abwil...@nospam-gmail.com> wrote:
> > CTorrent (more correctly, Enhanced CTorrent) is probably the best OS/2
> > client at the moment. It works very well within its limitations.
>
> I tried updating the latest ctorrent (dtorrent I think the version is)
> and I too only got an executable that launches but doesn't actually do
> anything. I then went through and updated all the OS/2 specific
> changes and thought that was probably it as it made changes to binary
> vs. text in places. It still didn't work any better. I then looked
> at the options and found the verbose option and found:
> Error from select: Invalid argument
> which I haven't gotten past yet.
Did you see the discussion about ACT elsewhere in this thread? It's
an updated build of Enh CTorrent at the latest code level, plus some OS/2
enhancements similar to ctorrent9.
It works very well, actually... considerably better than ctorrent9 at
this point. I'm currently writing a GUI wrapper for it in VX-REXX.
Christian Hennecke
<mai...@reply.to.address> wrote:
> Did you see the discussion about ACT elsewhere in this thread? It's
> an updated build of Enh CTorrent at the latest code level, plus some OS/2
> enhancements similar to ctorrent9.
>
> It works very well, actually... considerably better than ctorrent9 at
> this point. I'm currently writing a GUI wrapper for it in VX-REXX.
Cool! I'd really like a copy. :-)
--
"I smell blood and an era of prominent madmen." - W.H. Auden
Alex Taylor
<christian...@ruhr-uni-bochum.de> wrote:
> > Did you see the discussion about ACT elsewhere in this thread? It's
> > an updated build of Enh CTorrent at the latest code level, plus some
> > OS/2 enhancements similar to ctorrent9.
> >
> > It works very well, actually... considerably better than ctorrent9 at
> > this point. I'm currently writing a GUI wrapper for it in VX-REXX.
>
> Cool! I'd really like a copy. :-)
Of ACT, or my GUI?
Christian Hennecke
<mai...@reply.to.address> wrote:
> > > Did you see the discussion about ACT elsewhere in this thread? It's
> > > an updated build of Enh CTorrent at the latest code level, plus some
> > > OS/2 enhancements similar to ctorrent9.
> > >
> > > It works very well, actually... considerably better than ctorrent9 at
> > > this point. I'm currently writing a GUI wrapper for it in VX-REXX.
> >
> > Cool! I'd really like a copy. :-)
>
> Of ACT, or my GUI?
Your GUI.
Wolfi
> The Act application is cool!
> I think I shall use it instead of ctorrent from now on.
Enhanced CTorrent dnh3.3.2 [ACT 0.2.7 t2]:
Does anyone know if this is a problem of the WPS or cmd.exe or an issue
with act, that using the option:
-org position Set window corner position (left, bottom) as 'x,y'
in act.cfg only works, if <X> is at least 100?
For any smaller value, the VIO window ends up being positioned somewhere
close to the bottom of the screen, no matter of the value of <Y>.
Wolfi
Looks like I hit another snag with ACT.
Within less than 24h I now had it abort for the fourth time on 2
different torrents after d/l'ing just fine for some time with a:
SYS1808:
Der Proze� wurde gestoppt. Der Softwarediagnosecode
(Fehlercode der Ausnahmebedingung) ist 0097.
Anyone else seeing this?
With the cTorrent9 so far I never had anything like this happen.
Alex Taylor
<christian...@ruhr-uni-bochum.de> wrote:
>>>> It works very well, actually... considerably better than ctorrent9 at
>>>> this point. I'm currently writing a GUI wrapper for it in VX-REXX.
>>>
>>> Cool! I'd really like a copy. :-)
>>
>> Of ACT, or my GUI?
>
> Your GUI.
Well, a very preliminary first release is working:
http://users.socis.ca/~ataylo00/programming/os2/pmctm_001.zip
(Currently I'm referring to it as "PM CTorrent Manager"... not terribly
snappy, I'll admit. Maybe I'll come up with a better name later on.)
Currently, it only functions as a (somewhat incomplete) CTCS server/
console. I'll eventually add the ability to open torrent files and launch
new CTorrent downloads directly (e.g. as a browser helper app).
I've tested mostly with ACT, but it appears to work with CTORRENT9.EXE as
well. In theory it should work with any version of Enhanced CTorrent (or,
indeed, any CTCS client).
Rigt now, you have to run ACT (or whatever) manually, and specify the server
address (with port 2780) using the -S option.
e.g.
act.exe -S localhost:2780 somefile.torrent
The beauty of using the CTCS protocol is that you can run CTorrent on a
different computer entirely, as long as it's on the network; just replace
"localhost" in the above example with the IP address of the system running
PMCTM.
Regardless, whether it's running locally or remotely, you MUST specify the
-S option when starting CTorrent/ACT, otherwise the client will not show up
in the GUI.
You can start PMCTM (or close and restart it) at any time, independently of
when you started CTorrent/ACT.
Why this program? Well, it lets you view, monitor, or terminate all your
CTorrent/ACT downloads from a single window. This should let you run
CTorrent/ACT detached if you want to, thus not cluttering up your desktop
and/or window list. It'll become even more useful once it supports opening
torrent files and launching CTorrent/ACT directly.
Alex Taylor
wrote:
> Well, a very preliminary first release is working:
> http://users.socis.ca/~ataylo00/programming/os2/pmctm_001.zip
I should add that this hasn't been tested under heavy stress, and
probably has bugs. This is by far the most complicated program,
multithreading-wise, that I've ever attempted to write...
Tellerbop
<mai...@reply.to.address> wrote:
> On Mon, 25 May 2009 14:18:02 UTC, "Alex Taylor" <mai...@reply.to.address>
> wrote:
>
> > Well, a very preliminary first release is working:
> > http://users.socis.ca/~ataylo00/programming/os2/pmctm_001.zip
>
> I should add that this hasn't been tested under heavy stress, and
> probably has bugs. This is by far the most complicated program,
> multithreading-wise, that I've ever attempted to write...
>
Hi Alex,
Thankz for this, only remark from me is that the prog loads cpu to
100%
Wolfi
Same here.
Alex Taylor
> > > Well, a very preliminary first release is working:
> > > http://users.socis.ca/~ataylo00/programming/os2/pmctm_001.zip
> >
> > I should add that this hasn't been tested under heavy stress, and
> > probably has bugs. This is by far the most complicated program,
> > multithreading-wise, that I've ever attempted to write...
>
> Thankz for this, only remark from me is that the prog loads cpu to
> 100%
Hmm, you're right. I guess I didn't notice that because it doesn't
actually slow down the system at all (that I can tell).
It's the daemon thread that causes it. Something about the SockAccept()
loop, apparently. I added a SysSleep 1 to the loop as a quick-and-dirty
workaround and it seems to stop the CPU from maxing out. I'll test it a
bit before releasing an update, though.
Alex Taylor
wrote:
> > > > Well, a very preliminary first release is working:
> > > > http://users.socis.ca/~ataylo00/programming/os2/pmctm_001.zip
> > >
> > > I should add that this hasn't been tested under heavy stress, and
> > > probably has bugs. This is by far the most complicated program,
> > > multithreading-wise, that I've ever attempted to write...
> >
> > Thankz for this, only remark from me is that the prog loads cpu to
> > 100%
>
> It's the daemon thread that causes it. Something about the SockAccept()
> loop, apparently. I added a SysSleep 1 to the loop as a quick-and-dirty
> workaround and it seems to stop the CPU from maxing out. I'll test it a
> bit before releasing an update, though.
OK, v0.02 uploaded, should fix this problem (and various others):
http://users.socis.ca/~ataylo00/programming/os2/#pmctm
Tellerbop
Works ok now, looks verry nice :P
On Tue, 26 May 2009 14:47:02 UTC, "Alex Taylor"
<mai...@reply.to.address> wrote:
> On Tue, 26 May 2009 07:21:01 UTC, "Alex Taylor" <mai...@reply.to.address>
> wrote:
>
> > > > > Well, a very preliminary first release is working:
> > > > > http://users.socis.ca/~ataylo00/programming/os2/pmctm_001.zip
> > > >
> > > > I should add that this hasn't been tested under heavy stress, and
> > > > probably has bugs. This is by far the most complicated program,
> > > > multithreading-wise, that I've ever attempted to write...
> > >
> > > Thankz for this, only remark from me is that the prog loads cpu to
> > > 100%
> >
> > It's the daemon thread that causes it. Something about the SockAccept()
> > loop, apparently. I added a SysSleep 1 to the loop as a quick-and-dirty
> > workaround and it seems to stop the CPU from maxing out. I'll test it a
> > bit before releasing an update, though.
>
> OK, v0.02 uploaded, should fix this problem (and various others):
> http://users.socis.ca/~ataylo00/programming/os2/#pmctm
>
>
--
Wolfi
> Hi Alex,
>
> Works ok now, looks verry nice :P
I second that :-) Thanks Alex.
Marty
No idea if this is related to the problem you see, but keep in mind that
the coordinate origin (0,0) in the OS/2 PM is the bottom left of the
screen. Many other windowing systems make the origin in the upper left.
Wolfi
I was aware of the PM origin (it is mentioned in act.cfg).
What happens is that the VIO window initially opens up in the upper left
corner and then act should reposition it according to the coordinates
specified in act.cfg.
But this repositioning only works as expected, if the X-value is at
least 100, for anything smaller, the repositioned window ends up at
slightly different locations around the lower left screen corner.
Alex Taylor
> Looks like I hit another snag with ACT.
>
> Within less than 24h I now had it abort for the fourth time on 2
> different torrents after d/l'ing just fine for some time with a:
>
> SYS1808:
> Der Proze� wurde gestoppt. Der Softwarediagnosecode
> (Fehlercode der Ausnahmebedingung) ist 0097.
>
> Anyone else seeing this?
>
> With the cTorrent9 so far I never had anything like this happen.
I did have it die on a SYS3175 once, but I haven't seen that particular
one.
I do notice that the '-file' option doesn't actually function as
advertised: it behaves exactly like '-n'. And files are always
preallocated on disk regardless of whether or not '-a' is specified.
Wolfi
> On Sun, 24 May 2009 03:35:25 UTC, Wolfi <public...@yahoo.fr> wrote:
>
>> Looks like I hit another snag with ACT.
>>
>> Within less than 24h I now had it abort for the fourth time on 2
>> different torrents after d/l'ing just fine for some time with a:
>>
>> SYS1808:
>> Der Proze� wurde gestoppt. Der Softwarediagnosecode
>> (Fehlercode der Ausnahmebedingung) ist 0097.
>>
>> Anyone else seeing this?
>>
>> With the cTorrent9 so far I never had anything like this happen.
>
> I did have it die on a SYS3175 once, but I haven't seen that particular
> one.
After running for some 35 hours now, I just had it happen again, while
a second torrent of the same age still works.
> I do notice that the '-file' option doesn't actually function as
> advertised: it behaves exactly like '-n'.
Here I am still puzzled about the meaning of those "Files" | "File
Numbers". Are we talking here about numbered chunks within a torrent or
a list o torrents, which then are processed sequentially?
> And files are always
> preallocated on disk regardless of whether or not '-a' is specified.
Hadn't noticed that yet, since I considered it being active as default
in act.cfg to be quite useful.
Alex Taylor
> > I do notice that the '-file' option doesn't actually function as
> > advertised: it behaves exactly like '-n'.
>
> Here I am still puzzled about the meaning of those "Files" | "File
> Numbers". Are we talking here about numbered chunks within a torrent or
> a list o torrents, which then are processed sequentially?
It's the number of the file within the torrent, when the torrent contains
multiple files (as shown by 'act -x torrentfile').
> > And files are always
> > preallocated on disk regardless of whether or not '-a' is specified.
>
> Hadn't noticed that yet, since I considered it being active as default
> in act.cfg to be quite useful.
I turned it off in my config file, although as I noted it doesn't seem to
make any difference.
I have very limited disk space, so I prefer to have it turned off.
More to the point, when using '-file' or '-n' it results in the entire
contents of the torrent being allocated on disk, which is pretty annoying
when you only want to grab one file out of a 20 GB torrent...
Wolfi
> On Mon, 1 Jun 2009 15:05:12 UTC, Wolfi <public...@yahoo.fr> wrote:
>
>>> I do notice that the '-file' option doesn't actually function as
>>> advertised: it behaves exactly like '-n'.
>> Here I am still puzzled about the meaning of those "Files" | "File
>> Numbers". Are we talking here about numbered chunks within a torrent or
>> a list o torrents, which then are processed sequentially?
>
> It's the number of the file within the torrent, when the torrent contains
> multiple files (as shown by 'act -x torrentfile').
Aaah, now I finally get it ;-)
So far I only had single file torrents or those where I wanted all it
contained and I didn't even know, that one could selectively get
individual ones out of a torrent. That really is sweet :-)
>>> And files are always
>>> preallocated on disk regardless of whether or not '-a' is specified.
>> Hadn't noticed that yet, since I considered it being active as default
>> in act.cfg to be quite useful.
>
> I turned it off in my config file, although as I noted it doesn't seem to
> make any difference.
>
> I have very limited disk space, so I prefer to have it turned off.
So do I,
> More to the point, when using '-file' or '-n' it results in the entire
> contents of the torrent being allocated on disk, which is pretty annoying
> when you only want to grab one file out of a 20 GB torrent...
... but so far in my few cases with always wanting all of it, the
preallocation actually has been the better choice for me, preventing me
from accidentally running out of space, while the torrent is still going.