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.
_______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
