Hi first off all i just wanted to tell u that your code is incredibly clear, although it's not very much comented one can read it (like me ) and understand almost avrything.
I have been triyng to touch something and aparently i broke something else... the thing is that i cant open the infowidget plug in. when i try to load it, ktorrent crashes. i didnt touch anything in the plugin folder. just aded an atribute to "struct stats" and to "class TorrentInterface" "torrentinterface.h" without removing anything. i would like to preserve my non-polyted changes so it would be great if someone could tell me where to look in infowidget or somewhere else in order to void it from crashing due to my interface changes...
thanks

It should not crash if you just added one member to stats struct. Unless you've changed something else too? What happens if you revert your changes?

BTW, if you modify code make sure to do a 'make install' after compilation or your plugin libraries won't be up to date.

I did make install; but after configure --prefix=/root/local/
the original instalation is in the default dir.
yes i changed some .cpp but not any other interface:
./ktorrent-2.0.3/libktorrent/torrent/torrentcontrol.cpp
./ktorrent-2.0.3/libktorrent/interfaces/torrentinterface.cpp
./ktorrent-2.0.3/apps/ktorrent/ktorrent.cpp
./ktorrent-2.0.3/libktorrent/interfaces/torrentinterface.h
these are the files that i touched. to ensure that I untared the './ktorrent-2.0.3/plugins/' folder over tha old one...
-
-Ups!
wait..
i works fine, the location was the problem.. i didn't want to screw up the original compilation, there for "config --prefix=/root/local" but i took the risk and it works all great...
Now do u know why the infowidget plugin didnt work whith the installation in /root/local?
befor makein a "configure" i troed cp -r /root/local/* /usr/local/
and didnt work neither.
Any way the problem is fixed.
Thanks! and sorry for wasting your time.

PD: i felt naked without the infowidget plugin

Yeah, that can be a problem. You have to install with $KDEDIR prefix otherwise KTorrent won't find your plugins or in this case it'll try and use old ones which will cause a crash. This is how KDE plugin system works - it requires installation in $KDEDIR.

Glad your problem is solved.

Many people can cheat the trakers becouse they believe what the clients report as "trk_bytes_uploaded". that is a weak way of controlling priority.. Don't u think that if all clients report :
trk_bytes_downloaded
trk_bytes_uploaded
AND
trk_Peerid_bytes_received_from
For each peer that is conected to the client for the torrent that is beeing repoted.
the traker may have more elements to find out who is cheating...
(if my upload doesnt match the SUM of all my mates's trk_Peerid_bytes_received_from with my peerid, then i'm probably cheating)
the only problem that i see in this solution sugestion is in multi-traker torrents, couse if not every client have the same trakers they coul be sending useless informtion to some of them. unless u have a struct to remember what peer has been discovered from wich traker.
if u have time and want to see my changes (wich i'm not going to distribute) u can tell me where to send them:
20K 2006-11-02 18:09 ktorrent-2.0.3.Parcheado.tar.gz
THANKS! (again)

Wouldn't that break down when a peer leaves the swarm ? When a peer leaves, the sum of all the bytes the swarm got from you will no longer match your amount of uploaded bytes ?

!
::
then the trk_bytes_uploaded should split in:
struct trk_bytes_uploaded_to_peerid
so when a peer leaves the swarm, untill my client know that... the traker could discard my trk_bytes_uploaded_to_peerid with peerid=gone-peer
? what do u think?
so if u are gone. my upload to u shouldnt grow and can be ignored.
there will always be a difference.. becouse not all report at the same time...
but this diference will be related with the time dif and the presumed Upload speed and cant continuously grow... it must have a roof.

besides i think this aproach could save computational work to the traker (compared to the last one) since here there is no need for a sum(peer_download_related_toPeerid_And_file)
becouse it cam compare directly:
peer 1 uploaded to peer 2 10Gb
peer 2 downloaded from peer 1 90Mb
Someone is cheating..
when the peer comes back, he does whit the same peerid?
if this could be implemented and get to work.. i think the only wy of cheating is to lie about how mucho we downloaded.. and this could lead to a peer banned.
this peer will probably be the one that sends u more bytes.. and who wants to loose the best uploader? besides everyone cant be lying so if i report bad info for more than one or two peers it should be me the cheater...

Cheating is easy with this scheme, it just takes two clients :

cleint 1 says that it got 10 GB from client 2
client 2 confirms this

If you control the 2 clients it is easy to cheat. You can sent the amount you want to the tracker, as long as your second client confirms this.

The only difficulty would be to convince the tracker that client 1 and client 2 are from a different host (private trackers will not allow this). Which easily can be done by letting one client use a HTTP proxy.

yep! u are absolutely rigth. didnt thougth this... it´s more dificult to cheat but also require a more complex scheme.
thanks. now i don´t have the doubt about if things could be done better.

The problem with this problem is that no matter what scheme you come up with, you have to work with data from untrustworthy sources.