Odd upload loop ???

[Pop_G]

Has anyone experienced this weird anomaly when sharing?

Half the time when someone tries to upload from me, the transfer will start, but then it will keep restarting. *Let's say a file is 175,000 bytes. *They will get 2048 bytes, then 4064, then 8092, but then it will go back to 2048, then 3192, 8075 ect., restarting over and over forever.

I'm using WinMX 3.22. *I never used 3.2 or any 3x version before so I don't know if it's unique to 3.22. *(I was an eDonkey, KaZaA, WinMX 2.6 user during all this 3x testing)

I tried testing 3.2, but it won't connect to the network. *Since 3.22 is suppose to have a drastically improved/changed network, maybe it's something in this latest version. *Maybe the loop happens when someone with a different revision tries to upload from me.

Well if you want to see the problem that I'm talking about, go here --> and download a zipped video capture I made of the upload window. *You'll have to view it full screen in your player to see it clearly. *The DivX avi is all muddy looking because it is a "jpeg" type codec not suited for solid colored graphics, but it's the codec I think most people have.

I sized the columns to conceal the filenames and users. *I like to stay anonymous on peer-to-peer networks, call it myyy prerogative:tilted

I can't guarantee the links will always be alive, as this is free web space, and when you eat up a host's bandwidth by transferring big files, they tend to want to pull the plug on your site. *:error404 NOTFOUND
*

[Caitlyn Marble]

I had that happen to me this morning. (I'm on 3.22) We were both on cable and he was d/l a 6 megs file at about 20k/s. It should have been done quickly, but it didn't so I just cancelled it after 45mins.

[Pop_G]

Originally posted by Caitlyn Marble
I had that happen to me this morning. (I'm on 3.22)

Glad to know I'm not the only one who encountered this problem

I do hope this bug is fixed by the next revision though
*

[tufftuff]

yep, I confirm that this has happened to me as well, 5 or 6 times. Annoying ...

[ston]

many p2p filesharing programs have a built-in ongoing file verification check. If an error occurs in transmission, such as due to poor line conditions, and part of a file did not match the original, then it is re-downloaded.

It might seem to take longer this way, but this is added insurance that the file will complete without errors.

And if you think winmx is bad, just consider edonkey2000. It does a check after it completes a 9MB portion of download, and if it finds a single error, it will redownload the entire 9MB.

[DigitalJunkie]

ston, eDonkey2000 will report which part of the file is corrupted but only will re-download that part. Not the entire file!

[Pop_G]

Originally posted by DigitalJunkie
eDonkey2000 will report which part of the file is corrupted but only will re-download that part. Not the entire file!

I think that's what ston was saying, Donkey will re-download a 9 MB segment of say a 700 MB file.

I've had eDonkey dl's in progress that had those "corruption found in xxx" messages. *Sometimes I would close & restart Donkey so it re-hashes say, a 695 MB incomplete file with 690 MB done, when it starts downloading a source, the file is now rolled back to 681 MB, pushing you a little bit further away from completion

Originally posted by ston
many p2p filesharing programs have a built-in ongoing file verification check. If an error occurs in transmission,... *and part of a file did not match the original, then it is re-downloaded.

It might seem to take longer this way, but this is added insurance that the file will complete without errors.

Yes eDonkey does this and eventually gets the file done. *With WinMX, when a 65,000 byte JPG file never completes an upload at 32 KB/sec, you start thinking "somethin' ain't working like it's suppose to" *I once let an upload like this go on for 6 hours, when it should have been instantaneous between 2 broadband connections. *Trust me, civilization as we know it, would have ended:wings , city ruins buried in snow in the next ice-age:santa , and this transfer would still be going, if either end didn't abort.