Gnutella Forums  

Go Back   Gnutella Forums > Current Gnutella Client Forums > LimeWire+WireShare (Cross-platform) > LimeWire Beta Archives
Register FAQ The Twelve Commandments Members List Calendar Arcade Search Today's Posts Mark Forums Read


Welcome To Gnutella Forums

You are currently viewing our boards as a guest which gives you limited access to view most discussions and access our other features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content, fun aspects such as the image caption contest and play in the arcade, and access many other special features after your registration and email confirmation. Registration is fast, simple and absolutely free so please, join our community today! (click here)

If you have any problems with the Gnutella Forum registration process or your Gnutella Forum account login, please contact us (this is not for program use questions.) Your email address must be legitimate and verified before becoming a full member of the forums. Please be sure to disable any spam filters you may have for our website, so that email messages can reach you.
Note: Any other issue with registration, etc., send a Personal Message (PM) to one of the active Administrators: Lord of the Rings or Birdy.

Once registered but before posting, members MUST READ the FORUM RULES (click here) and members should include System details - help us to help you (click on blue link) in their posts if their problem relates to using the program. Whilst forum helpers are happy to help where they can, without these system details your post might be ignored. And wise to read How to create a New Thread

Thank you

If you are a Spammer click here.
This is not a business advertising forum, all member profiles with business advertising will be banned, all their posts removed. Spamming is illegal in many countries of the world. Guests and search engines cannot view member profiles.



Deutsch? . . . . Español? . . . . Français? . . . . Nederlands? . .
Hilfe in Deutsch, . Ayuda en español, . Aide en français . et . LimeWire en français, . Hulp in het Nederlands

Forum Rules

Support Forums

Before you post to one of the specific Client Help and Support Conferences in Gnutella Client Forums please look through other threads and Stickies that may answer your questions. Most problems are not new. The Search function is most useful. Also the red Stickies have answers to the most commonly asked questions. (over 90 percent).
If your problem is not resolved by a search of the forums, please take the next step and post in the appropriate forum. There are many members who will be glad to help.
If you are new to the world of file sharing please do not be shy! Everyone was ‘new’ when they first started.

When posting, please include details for:
Your Operating System ....... Your version of your Gnutella Client (* this is important for helping solve problems) ....... Your Internet connection (56K, Cable, DSL) ....... The exact error message, if one pops up
Any other relevant information that you think may help ....... Try to make your post descriptive, specific, and clear so members can quickly and efficiently help you. To aid helpers in solving download/upload problems, LimeWire and Frostwire users must specify whether they are downloading a torrent file or a file from the Gnutella network.
Members need to supply these details >>> System details - help us to help you (click on blue link)


Moderators

There are senior members on the forums who serve as Moderators. These volunteers keep the board organized and moving.
Moderators are authorized to: (in order of increasing severity)
Move posts to the correct forums. Many times, members post in the wrong forum. These off-topic posts may impede the normal operation of the forum.
Edit posts. Moderators will edit posts that are offensive or break any of the House Rules.
Delete posts. Posts that cannot be edited to comply with the House Rules will be deleted.
Restrict members. This is one of the last punishments before a member is banned. Restrictions may include placing all new posts in a moderation queue or temporarily banning the offender.
Ban members. The most severe punishment. Three or more moderators or administrators must agree to the ban for this action to occur. Banning is reserved for very severe offenses and members who, after many warnings, fail to comply with the House Rules. Banning is permanent. Bans cannot be removed by the moderators and probably won't be removed by the administration.


The Rules

1. Warez, copyright violation, or any other illegal activity may NOT be linked or expressed in any form. Topics discussing techniques for violating these laws and messages containing locations of web sites or other servers hosting illegal content will be silently removed. Multiple offenses will result in consequences. File names are not required to discuss your issues. If filenames are copyright then do not belong on these forums & will be edited out or post removed. Picture sample attachments in posts must not include copyright infringement.

2. Spamming and excessive advertising will not be tolerated. Commercial advertising is not allowed in any form, including using in signatures.

3. There will be no excessive use of profanity in any forum.

4. There will be no racial, ethnic, or gender based insults, or any other personal attacks.

5. Pictures may be attached to posts and signatures if they are not sexually explicit or offensive. Picture sample attachments in posts must not include copyright infringement.

6. Remember to post in the correct forum. Take your time to look at other threads and see where your post will go. If your post is placed in the wrong forum it will be moved by a moderator. There are specific Gnutella Client sections for LimeWire, Phex, FrostWire, BearShare, Gnucleus, Morpheus, and many more. Please choose the correct section for your problem.

7. If you see a post in the wrong forum or in violation of the House Rules, please contact a moderator via Private Message or the "Report this post to a moderator" link at the bottom of every post. Please do not respond directly to the member - a moderator will do what is required.

8. Any impersonation of a forum member in any mode of communication is strictly prohibited and will result in banning.

9. Multiple copies of the same post will not be tolerated. Post your question, comment, or complaint only once. There is no need to express yourself more than once. Duplicate posts will be deleted with little or no warning. Keep in mind a forum censor may temporarily automatically hold up your post, if you do not see your post, do not post again, it will be dealt with by a moderator within a reasonable time. Authors of multiple copies of same post may be dealt with by moderators within their discrete judgment at the time which may result in warning or infraction points, depending on severity as adjudged by the moderators online.

10. Posts should have descriptive topics. Vague titles such as "Help!", "Why?", and the like may not get enough attention to the contents.

11. Do not divulge anyone's personal information in the forum, not even your own. This includes e-mail addresses, IP addresses, age, house address, and any other distinguishing information. Don´t use eMail addresses in your nick. Reiterating, do not post your email address in posts. This is for your own protection.

12. Signatures may be used as long as they are not offensive or sexually explicit or used for commercial advertising. Commercial weblinks cannot be used under any circumstances and will result in an immediate ban.

13. Dual accounts are not allowed. Cannot explain this more simply. Attempts to set up dual accounts will most likely result in a banning of all forum accounts.

14. Video links may only be posted after you have a tally of two forum posts. Video link posting with less than a 2 post tally are considered as spam. Video link posting with less than a 2 post tally are considered as spam.

15. Failure to show that you have read the forum rules may result in forum rules breach infraction points or warnings awarded against you which may later total up to an automatic temporary or permanent ban. Supplying system details is a prerequisite in most cases, particularly with connection or installation issues.

Violation of any of these rules will bring consequences, determined on a case-by-case basis.


Thank You! Thanks for taking the time to read these forum guidelines. We hope your visit is helpful and mutually beneficial to the entire community.


 
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old May 24th, 2004
Disciple
 
Join Date: April 21st, 2003
Posts: 17
Scott Drysdale is flying high
Default limewire (3.8.9, 3.8.10, 4.0.4) downloading from bearshare (4.5.0bXX)

i'm running bearshare betas (currently 4.5.0b44).

when limewire is downloading from bearshare, it sometimes thinks the file i have is larger than it really is. this causes limewire to ask for a final chunk which is too large. bearshare truncates the request to the actual number of bytes left in the file, and sends those bytes. limewire then requests the same (too large) chunk from bearshare, and round and round it goes until i cancel the upload manually.

1) limewire should pay attention to the file size on the source. in case of doing a multi-source download, make sure all sources agree as to the file size as well as the hash.

apparently, there is a bug in some versions of bearshare (not the version i'm running) in which a user can, for example, add and ID3 tag to an MP3 file, which changes it's size, but bearshare fails to make a new hash for the modified file. this causes the hash on the bad bear and my bear to be the same, but the bad bear's file size is larger than mine, triggering the limewire problem.

there's also (i hear) a bug in shareaza partial file sharing messages where the list of partial ranges from shareaza is wrong, leading to the same problem as above.

2) limewire should notice that it's attempting to download the same range more than once in a row and failing, and bail out after some number of attempts to prevent locking up the far end's upload slot.

analysis of the problem can be found in the bearshare forums at this address:
http://www.bearshare.com/forum/showthread.php?t=28238
  #2 (permalink)  
Old May 24th, 2004
verdyp's Avatar
LimeWire is International
 
Join Date: January 13th, 2002
Location: Nantes, FR; Rennes, FR
Posts: 306
verdyp is flying high
Default

Limewire DOES pay attention to both the filesize and hashes exposed in query hits.
It causes a problem with some BearShare sources that expose incorrect lengths...
The fact that this bug is produced by Shareaza not monitoring its locally modified files and spreading files to BearShare that forget to verify the file downloaded from Shareaza (to see if it matches its supposed SHA1) is not a problem of LimeWire.
If it causes LimeWire to hammer BearShare sources, it's certainly a problem, but the origin is still in Bearshare not verifying the data it sends to the network.
Limewire will integrate patches to detect the case of a file that has been modified on the BearShare host but that BearShare forgot to rehash after the change.
If your Bearshare is exposed to such hammering, you have a bug in BearShare that does not detect such changes in local files, and still accepts to upload files whose SHA1 hash should have been updated. If bearshare had detected this change, it would not reply successfully to the incoming transfer request, but would return a 404.

LimeWire on the opposite is actively monitoring possible changes that may have occured on the local files requested: When a transfer request comes in for a URN, the corresponding file is checked to see if its size or modification date has changed. If such change is detected, then the reply will be 404, the old file entry will be removed from the shared library, and the modified file will be immediately rehashed for future Query Hits.
That's why LimeWire maintains a local cache for shared file properties (name, date, size, precomputed URNs...)
__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

Last edited by verdyp; May 24th, 2004 at 04:54 PM.
  #3 (permalink)  
Old May 24th, 2004
Disciple
 
Join Date: April 21st, 2003
Posts: 17
Scott Drysdale is flying high
Default please read it CAREFULLY

please read the entire bearshare forum thread carefully.

the bearshare acting as the source and victim of limewire's infinite retries (my machine) DOES NOT have the file size bug, and even if it possibly did, it wouldn't show up because i don't modify my files. SOME OTHER bearshare/shareaza source has lied to limewire, and limewire is using that incorrect value when trying to download from me.

i care a whole hell of a lot when you occupy my upload slots FOREVER with the SAME REQUEST that CANNOT BE SATISFIED BY ME AS A SOURCE because MY COPY OF THE FILE ISN'T AS LONG AS SOME OTHER SOURCE (and thus limewire) BELIEVES IT IS.

fix the infinite loop problem - that's a limewire bug that cannot be explained away as a bug in some other client. think of it as a lesson in error handling.

look into clipping requests to match THAT SOURCE'S file size, so you are ROBUST and won't be affected by other clients' bugs.

what's so hard to grasp here?
  #4 (permalink)  
Old May 24th, 2004
verdyp's Avatar
LimeWire is International
 
Join Date: January 13th, 2002
Location: Nantes, FR; Rennes, FR
Posts: 306
verdyp is flying high
Default

Your arguments would be valid if only you said which Limewire version is causing such hammering. Can't you see that version number in your incoming download requests?
May be the looping problem is already fixed in LimeWire 4.0 and only affects previous releases (3.8.9 and 3.8.11 were common before 4.0 was released; all 3.9 versions were betas which were much less deployed).

Users are upgrading quite fast now, and all 3.8 and 3.9 versions should upgrade fast. As 4.0 includes much more verifications of sources, the looping problem that occurs only when there are several sources for the same hash will rapidly disappear completely.

I did not say that we won't check the code and won't correct it; it's just that your analysis of the problem is not enough to isolate and solve the problem, caused by older versions of BearShare and Shareaza. We have to live with old or foreign servents, including the possibility of detecting corrupted sources because it is for the safety and security of transfers on Gnutella.

For now I have never seen this problem on my LimeWire: all downloads were either completing successfully or were stopped and could not be resumed only because the source was no longer available. I did not detect any hammering.

What can be done in Limewire is to check that a successful reply that consists only in the 10 bytes of fragment overhead will be interpreted as the source not having the fragment we need.
We just need to check that the source sends more than these 10 bytes, before attempting to retry with another identical fragment.
__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml
  #5 (permalink)  
Old May 24th, 2004
Disciple
 
Join Date: April 21st, 2003
Posts: 17
Scott Drysdale is flying high
Default

Quote:
Originally posted by verdyp
Your arguments would be valid if only you said which Limewire version is causing such hammering. Can't you see that version number in your incoming download requests?
May be the looping problem is already fixed in LimeWire 4.0 and only affects previous releases (3.8.9 and 3.8.11 were common before 4.0 was released; all 3.9 versions were betas which were much less deployed).
the title of the thread is "limewire (3.8.9, 3.8.10, 4.0.4) downloading from bearshare (4.5.0bXX)." what more limewire version info do you want?
Quote:
Originally posted by verdyp
I did not say that we won't check the code and won't correct it;
from the bearshare forum thread, posted by "pve", whoever that is:
"It won't be fixed. This 10-bytes overhead is not a bug, but needed for checking fast sources that incorrectly return fake SHA1 values."
Quote:
Originally posted by verdyp
it's just that your analysis of the problem is not enough to isolate and solve the problem, caused by older versions of BearShare and Shareaza.
talk to john lindh. he apparently (read the bearshare forum thread) DID determine that limewire is being confused by a shareaza (x-available-ranges) bug. later, we realized that there was a similar bearshare bug (modifying a file that's already being shared can fail to change the file's advertised hash on SOME versions of bearshare - but not the version i'm running).

in other words, one or more (buggy) bearshare sources may be advertising the same hash even though the file is different (longer) on those sources than on my source. limewire should know both the hash and size advertised by all sources. if hash1 == hash2, but size1 != size2, they're obviously not the same file. limewire should realize that. the hash CANNOT uniquely identify files - you need the size. of course, even then, it's possible to have hash1 == hash2 and size1 == size2 and still have different content, because the hash contains less info than the file itself - but different sizes obviously means different files, regardless of hash.

or it could simply be some other kind of limewire bug, where when there are exactly 10 bytes left in the source, limewire comes up with some weird-*** end-of-last-chunk value. the limewire request/bearshare response pairs captured and posted in the bearshare forum thread seem to support this theory.

please understand the problem before considering or rejecting potential solutions.

Last edited by Scott Drysdale; May 24th, 2004 at 07:33 PM.
  #6 (permalink)  
Old May 24th, 2004
verdyp's Avatar
LimeWire is International
 
Join Date: January 13th, 2002
Location: Nantes, FR; Rennes, FR
Posts: 306
verdyp is flying high
Default

You say: please understand the problem(...)

I have understood the problem...

You continue: (...) before considering or rejecting potential solutions.

I have NOT rejected potential solutions. But keep us looking on real issues and what is wrong in what LimeWire does and why it does that. We won't break a code that has proven to be extremely stable across all Limewires and with most other servents, just because of a few old Bearshares or some Shareazas that send wrong SHA1 values.

The downloader code is constantly unders scrutiny in Limewire, and it is the one that is taking the longest test time and the most complex test suite for handling variious cases (including ensuring that we can cope with detecting many bugs and weirdness in other servents). The 10-bytes overhead is needed in order to detect such weirdness from some sources.

But please keep your calm. Correcting a bug which has not been reported to us before will take some days at least. Don't flame against Limewire: you admit that BearShare has its own bugs wiith which it must still cope with. It's really difficult to have to manage the case of possible bogous sources, simply because we have to imagine all possible errors or wrong assumptions that some others may have done in a code that we can't see ourself.

Limewire publishes its sources so it's easy for others to check what Limewire does. LimeWire on the opposite has no access to BearShare sources.

OK you signal a problem, but this is only a symptom, not a cure and not the cause. What LimeWire does with a source that it has detected (from query hits) as matching the size and hash for a searched file is not illogical. I certainly causes Limewire hammering some BearShares, but it was not detected before.

One final note: I am not a LimeWire employee. I contribute to LimeWire, and audit and test the code, and propose solutions. It's so easy to start a flame with offensive insults and send critics than trying to help to find solutions. Limewire is not Shareaza and has many internal and external developers working constantly to solve problems and improve the network performance, and contribute with innovative solutions: look at the most useful contributions that BearShare can also use now. Limewire has been very active in describing them, documenting them, discussing them with other developers on the GDF forum.

LimeWire has always considered bug reports carefully and planned them in the development agenda even before adding new features (there are lots of pending features that will come later because solving bugs comes first.)
__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml
  #7 (permalink)  
Old May 25th, 2004
zab zab is offline
Connoisseur
 
Join Date: May 16th, 2004
Location: Big Apple
Posts: 266
zab is a great assister to others; your light through the dark tunnel
Default

Scott,

could you give us a request-response log of the problem with a limewire 4.0.x version? The code in question has changed significantly between 3.8.10 and 4.0.x, so this should not be happening.
  #8 (permalink)  
Old May 12th, 2005
Disciple
 
Join Date: April 21st, 2003
Posts: 17
Scott Drysdale is flying high
Default "10-bytes-forever" redux

i'm running bearshare (currently 4.8.0b47, same problem with earlier bears). i don't know HOW many times i've reported this.

limewire apparently gets confused about file sizes. when downloading the last chunk of a file, it will do goofy things. currently seeing this with limewire 4.0.10 & 4.8.1, and 360share/4.2.6 (of course, i've seen this or some variation of it since lw 2.8.x).


example: file size = 5,968,335

while (power on)
{
limewire requests: 5,968,325 - 5,970,621 (2,297 bytes, 2,287 bytes past EOF)
bearshare responds with: 5,968,325 - 5,968,334 (10 bytes)
}

FIX THIS ALREADY! DAMMIT!
  #9 (permalink)  
Old May 12th, 2005
Software Developer
 
Join Date: November 4th, 2002
Location: New York
Posts: 1,366
sberlin is flying high
Default

That shouldn't be happening with 4.8.1, but for what it's worth, pretty much all of downloading (from THEX to requesting to verifying to selection strategy to method names to variable names to serialization to godknowswhatelse) has been rewritten for the next release.
  #10 (permalink)  
Old May 12th, 2005
Disciple
 
Join Date: April 21st, 2003
Posts: 17
Scott Drysdale is flying high
Default

Quote:
Originally posted by sberlin
That shouldn't be happening with 4.8.1
it shouldn't be happening on ANY version

Quote:
but for what it's worth, pretty much all of downloading (from THEX to requesting to verifying to selection strategy to method names to variable names to serialization to godknowswhatelse) has been rewritten for the next release.
i've heard that song before, and the problem persists.

i'm really tired of waking up to find several limewires stuck there downloading the same 10 bytes over and over again. asking bearshare to abort the upload usually stops them, but some are quite persistent and immediately come back and do it again.

i recently went from 768/128 DSL to 5M/2M fiber, so:

1) i have more upload slots open. this means more stuck limewires (bad).

2) i have more upload bandwidth. this means stuck limewires don't take such a big bite out of my outgoing bandwidth (good).

it's looking like the only fix is to prevent limewire from downloading. you cannot begin to understand how tired i am of this stupid, easy to fix bug hanging around for years.
 

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Limewire or Bearshare urin4aloss General P2P Network Discussion 4 September 18th, 2005 04:37 AM
BS forums on bearshare.com ? - A NEW Temporary Address For BearShare.net !!! kevver Open Discussion 6 July 13th, 2005 08:09 PM
Bearshare or Limewire Layziebone Open Discussion topics 1 April 2nd, 2005 07:57 PM
limewire downloading from bearshare Scott Drysdale Download/Upload Problems 20 April 28th, 2003 07:54 AM
Limewire vs. Bearshare pc911 Download/Upload Problems 0 January 29th, 2002 10:02 PM


All times are GMT -7. The time now is 05:19 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
SEO by vBSEO 3.6.0 ©2011, Crawlability, Inc.

Copyright © 2015 Gnutella Forums.
All Rights Reserved.