Author Topic: WinMXGroup Beta Patch (Read 23013 times)

KM · « **Reply #60 on:** August 30, 2006, 08:54:53 am »

the post i just made has 3 of them in it...

Faithless_Sniper · « **Reply #61 on:** August 30, 2006, 08:55:22 am »

well if you was on msn the forum would not get clogged up of me asking for things lol

GhostShip · « **Reply #62 on:** August 30, 2006, 09:23:35 am »

I suggest more time spent reading Quick Slide

Well done KM

Faithless_Sniper · « **Reply #63 on:** August 30, 2006, 10:21:44 am »

yeah i realised that i was not looking properly so sorry all and thanks KM i like the work you are doing.

Bearded Blunder · « **Reply #64 on:** August 30, 2006, 04:35:22 pm »

Now that Open Nap has been running for an extended period, there still appears to be a problem, during my routine queue management (starting folks waiting for small files so they don't wait forever behind huge iso & avi files etc) out of 12 users i attempted to start, all 12 timed out & none started, it appeared irrelevent weather they were open nap or wpn users, I also now have no secondaries connected (did when i went to bed) which may or may not be significant.

I'm now waiting for one of those large uploads to finish in order to watch the effect, when winmx itself tries to start them rather than me doing so manually.

Bearded Blunder · « **Reply #65 on:** August 30, 2006, 05:59:43 pm »

Furthur to above post, 4 transfers started by winmx also timed out rather than start, then the problem appeared to clear itself

I shall continue running open nap (not usually my habit) & checking from time to time, to see if the problem reoccurs, at this time I think it would be useful if some regular open nap users were to test, to help identify if this IS a problem, or something unique to my system.. as I seem to be a jinx on this patch version

SamSeeSam · « **Reply #66 on:** August 30, 2006, 06:01:11 pm »

Opennap worked nice even on eta 4,2 what ever Anyways, the new beta is great Everything seems fine. The update bar was also greeat when it told that a new beta was avaiable. All red and all
Great patch as usual. Thank you KM

Cheers

KM · « **Reply #67 on:** August 30, 2006, 06:09:33 pm »

finally someone who recognised it was red not pink! lol

I'm going to assume the opennap thing isn't fixed - it's unreliable at best - in my case i can confirm i get periods of uploads not working at all then they start again - but after a little edit which i didn't think would fix it it didn't happen again - probably more luck than having fixed it then... i'll keep trying to figure it out...

SamSeeSam · « **Reply #68 on:** August 30, 2006, 06:21:15 pm »

Faithless_Sniper · « **Reply #69 on:** August 30, 2006, 07:47:19 pm »

all i can say KM is try and keep up the good work you are doing well and we all know that.

Thanks for a good patch over and over again

p2p rules · « **Reply #70 on:** August 30, 2006, 10:01:31 pm »

I was downloading & uploading from a opennap user yesterday an they were getting files from me but then after a while the files they were trying to get from me were timing out.I hope he managed to get the files from me , I went to bed leaving MX on then I woke & saw the BSOD then shut off my PC an went back to bed , so I'm not sure if they got the files or not .

X · « **Reply #71 on:** September 03, 2006, 09:59:59 am »

not that i use winmx anymore (besides chat) but if you could, outgoing protocol encryption and incoming legacy connections, it would make it more likely to get by isp's blocks...there are a few p2p programs that i know of that have this in their programs. (utorrent for example)

Bearded Blunder · « **Reply #72 on:** September 03, 2006, 11:24:22 am »

Ways to deal with ISP blocks, throttling & filtering have certainly been discusssed, I have no doubt KM has given the matter some thought, I think it may be for a later release, however.

KM · « **Reply #73 on:** September 03, 2006, 01:37:55 pm »

the protocols don't allow for much in the way of changes to protocols - to get past ISP issues you'd need to change the handshake... it would make it completely incompatible with other clients if you did that

Sophosaurus · « **Reply #74 on:** September 04, 2006, 11:48:58 pm »

Don't you think Timeout-Problems with Opennaps aren't caused by something specific in 3.1b? Nearly every Upload to Opennap-Users is timing aout on my System.

KM · « **Reply #75 on:** September 05, 2006, 02:31:35 am »

the problem is not uploading to opennap users (although they are effected as much as winmx ones) what actually happens is you can have winmx working perfectly, then as soon as you start connecting to opennap you become unable to start any new uploads (of any kind) as they all fail

it is 3.1 specific as testing with 3.0 or earlier confirms it to work fine there - however I can't quite figure out what the problem is, the most likely cause would be some bug with more than a certain number of connections, however i have gone over all of the relevant code several times and can't find anything at all that would function any differently if there were 2 or 2,000 connections active (except taking a little more CPU to do more loops of course)

the hardest part of it is that it doesn't break well enough for me - lol, it is almost impossible for me to get it to break during controlled testing (ie. when i am monitoring it closely)... it's like it breaks, i fire up ethereal to watch the handshake, and it fixes itself... just to annoy me no doubt! i have managed to get it to fail during a few tests so have narrowed it down a big, but have no idea what could possibly cause the disconnects during that part of it

SamSeeSam · « **Reply #76 on:** September 28, 2006, 05:43:03 am »

I just got this on an opennap user...., mabye it might help somehow....
Opennap works sometime, sometimes doesn't:
I keep getting this for quite a few times for some users.... the first time it has happened like this Normally, the sizes match. But it's awlays the same file size: 7,898,014 bytes
Have a look:

Cheers

KM · « **Reply #77 on:** September 28, 2006, 06:22:51 am »

I think that was probably a user trying to download a non-matching file from you, where they had say 7MB of a 9MB file or whatever and the original source went so they tried to resume from your different (smaller) file... one possible explanation (when it asked to resume from a point past the end of the file it assumes it has completed)

although another explanation is "you may never know for sure"