Do you have a list of the changes you've made so far?

well more or less:

• load the winsock dll
• added a function that emulates poll() on windows
• disabled log rotation
• changed some function that doesn't exist/aren't similar on windows

btw it's not possible to set ToS on windows 2k/xp/2k3 http://support.microsoft.com/kb/248611 is this needed by ktorrent? it can be activated by changing a regkey anyway

Brandon wrote:well more or less:

• load the winsock dll
• added a function that emulates poll() on windows
• disabled log rotation
• changed some function that doesn't exist/aren't similar on windows

Could you send me a patch with the current status ? So I can try it out myself.

btw it's not possible to set ToS on windows 2k/xp/2k3 http://support.microsoft.com/kb/248611 is this needed by ktorrent? it can be activated by changing a regkey anyway

It's not really that important. It was only put in for people having some sort of QOS setup on their box or LAN, I do not think there are many people using it.

I think it would be fitting to post a torrent, Id like to play around with it on XP also.

I've an issue with Cache::mappedModeAllowed(), on windows there is no limit to file descriptor, except resources, rlimit is implemented in kdewin32 and it does nothing and MaxOpenFiles always returns 1, so why MaxOpenFiles() - bt::PeerManager::getTotalConnections() should be < 100? to allow mmap?

Brandon wrote:I've an issue with Cache::mappedModeAllowed(), on windows there is no limit to file descriptor, except resources, rlimit is implemented in kdewin32 and it does nothing and MaxOpenFiles always returns 1, so why MaxOpenFiles() - bt::PeerManager::getTotalConnections() should be < 100? to allow mmap?

The problem with mmap is that you have to keep the file open, so people ran into trouble hitting the system limits when they had torrents with a lot of files (to many files open errors). So we added this to prevent this from happening by using buffered mode only when we you are approaching system limits.

Seeing that windows has no limits, I suggest you let this function always return true on windows.

ok thanks

How much have you gotten to work so far?

downloading a single file in mmaped mode works, i still have problem with buffered mode and multiple files torrent. Upload seems to work too but I don't know if it uploads good or corrupted chunks

Thats kind of weird, if one file downloads, it should work for multiple files too.

assistant wrote:Thats kind of weird, if one file downloads, it should work for multiple files too.

i've tested it a bit more and i think it dependes on which torrent is(maybe size), i have a multiple file torrent that is always corrupted, while others are half good and half corrupted

Brandon wrote:

assistant wrote:Thats kind of weird, if one file downloads, it should work for multiple files too.

i've tested it a bit more and i think it dependes on which torrent is(maybe size), i have a multiple file torrent that is always corrupted, while others are half good and half corrupted

The calculation on which parts of which file to load or save for a chunk, should be portable.

However mmap under linux requires that when you mmap a part of a file, the offset must be a multiple of the page size. Maybe this is different under windows ?

George wrote:

Brandon wrote:

assistant wrote:Thats kind of weird, if one file downloads, it should work for multiple files too.

i've tested it a bit more and i think it dependes on which torrent is(maybe size), i have a multiple file torrent that is always corrupted, while others are half good and half corrupted

The calculation on which parts of which file to load or save for a chunk, should be portable.

However mmap under linux requires that when you mmap a part of a file, the offset must be a multiple of the page size. Maybe this is different under windows ?

yeah i've made that thing a bit different on windows following this example http://msdn2.microsoft.com/en-us/library/aa366548, but i'm not sure if it's the real problem, because the corrupted file is saved in the same way using both buffered and mmaped mode, i've also compared the corrupted file with the good one using an hex editor, the first part is good then the corrupted file have a null byte so the second part have an higher offset in the corrupted file, the end of the file looks like the same in both, but the corrupted one as a much higher offset(290 hex)

So there is some sort of bug in the offset calculation.

Could you send me your latest code ? Maybe I can figure it out.

Is the newest kTorrent build based completely off of KDE4?

Because I read somewhere that when most of the apps were ported to KDE4 that direct porting to other os's would be very easy.