[Mono-list] MonoTorrent error + fix

[Alan McGovern]

Hey


>   I haven't experienced any more size-related crashes with the latest
> SVN code.


Good good. Another bug crushed ;)

  I have a few more questions/suggestions WRT the library, though.
> I'd like to show a list of peers and how fast each one is
> delivering/receiving data, and this seems to be impossible with the
> current code.  It's keeping track of how fast it's interacting with
> each peer, but it's keeping that information to itself - in
> TorrentManager.connectedPeers[i].Peer.Connection.Monitor.UploadSpeed.
> What would a good way to expose this be?


I thought i had exposed this. My mistake if i haven't. Whenever a connection
is opened with another peer, that peer is given to you in an event. What
will happen (in the next SVN commit) is that you should be able to directly
access the bytes downloaded/uploaded from/to that peer, the current
upload/download speed, the current state (choked/unchoked/if he's a seeder
etc), the client that is running (if it's known) and the number of hashfails
from that peer. Is there any more information you would like?


  TorrentManager.DownloadSpeed() occasionally returns NaN.  This means
> I need code like this to keep track of ETA:
> ETA = ((obj.downSpeed == 0) || double.IsNaN(obj.downSpeed)) ?
> TimeSpan.MaxValue : TimeSpan.FromSeconds((double)obj.bytesLeft /
> obj.downSpeed);
> It'd be more convenient to get back non-NaN values, and the fact that
> it's giving NaNs is an indication to me that something's up with the
> rate calculations.  I can't get it to happen right now or I'd send a
> better bug report.


Yup, that's on my todo list. I'm not quite sure what is causing the problem.
I could implement a workaround to hide the bug from the end user but i
haven't as of yet so i get a constant reminder that it's not right ;)

I'm not 100% sure what is causing the problem. What i think has been
happening is that sometimes when writing a block to the disk (or reading
from the disk) the operation blocks for a few engine "ticks" and that breaks
the speed calculations then as then 3-4 ticks would run at the same time
causing division by 0's in the speed calculation giving NaN. The problem is
i can't reliably replicate the situation so it makes debugging hard.


  There's no quick way to tell how many bytes have been downloaded in
> total (not just from this session) that I can tell of.


I was wary about putting that in because i didn't want to confuse the users
of the library by having 10 different listings of "downloaded data".
Currently i have separate counts for the amount of protocol data
sent/received, the amount of actual data sent/received and there's another
count for each peer showing that they've sent/received. I didn't want to add
more ones for TotalBytesRemaining and TotalBytesDownloaded.

Easiest way to find out how many bytes have been downloaded overall would
be:
int bytesDownloaded= manager.Progress() * manager.Torrent.Size;

bytes remaining would be:
int remaining = manager.Torrent.Size -  bytesDownloaded;

If you have any comments or suggestions, give me a shout. Or if you can find
a way to easily replicate the NaN bug, that'd be great.

Thanks,
Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20070122/5e0537b9/attachment.html