|
| |||||||
| Register | FAQ | 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. Registration is fast, simple and absolutely free so please, join our community today! (click here) If you have any problems with the registration process or your account login, please contact us. 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. Once registered but before posting, members MUST READ the FORUM RULES (click here) and LimeWire/FrostWire users 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 . Uw e-mailadres moet wettig zijn en verifiërde alvorens een volwaardig lid van de forums te worden. Gelieve te zijn zeker om om het even welke spamfilters onbruikbaar te maken u voor onze website kunt hebben, zodat de e-mailberichten u kunnen bereiken . Votre email address doit être légitime et vérifié avant d'aller bien à un membre à part entière des forum. Veuillez être sûr de désactiver tous les filtres de Spam que vous pouvez prendre pour notre site Web, de sorte que les messages électroniques puissent vous atteindre . Ihr email address muss gesetzmäßig und überprüft sein, bevor es ein vollwertiges Mitglied der Foren wird. Seien Sie bitte sicher, alle mögliche Spamfilter zu sperren, die Sie für unsere Web site haben können, damit E-Mail-Nachrichten Sie erreichen können . Su email address debe ser legítimo y verificado antes de sentir bien a un miembro de pleno derecho de los foros. Esté por favor seguro de inhabilitar cualquier filtro del Spam que usted pueda tener para nuestro Web site, de modo que los correos electrónicos puedan alcanzarle . Seu email address deve ser legítimo e verific antes de assentar bem em um membro integral dos fóruns. Seja por favor certo incapacitar todos os filtros que do Spam você puder ter para nosso Web site, de modo que os mensagens de correio electrónico possam o alcangar. . Din e-post tilltalar måste vara legitim och verifierat för passande en full medlem av forumen. Behaga är säkert att inaktivera någon spam filtrerar dig kan ha för vår website, så att e-postmeddelanden kan ne dig. . Il vostro email address deve essere legittimo e verificato prima di stare bene ad un membro titolare delle tribune. Sia prego sicuro rendere invalidi tutti i filtri che dallo Spam potete avere per il nostro Web site, di modo che i messaggi di posta elettronica possono raggiungerli. . Η διεύθυνση ηλεκτρονικού ταχυδρομείου σας πρέπει να είναι νόμιμη και ελεγγμένη πρίν γίνεται πλήρες μέλος των φόρουμ. Παρακαλώ να είστε βέβαιος να θέσει εκτός λειτουργίας οποιωνδήποτε φίλτρα spam που μπορείτε να έχετε για τον ιστοχώρο μας, έτσι ώστε τα μηνύματα ηλεκτρονικού ταχυδρομείου μπορούν να φθάσουν σε σας. . Ваш адрес электронной почты должен быть правомерен и подтвержен перед идти действительным членом форумов. Пожалуйста уверен вывести все фильтры из строя спам вы можете иметь для нашего вебсайта, так, что сообщения по электронной почте смогут достигнуть вас. . 您的电子邮件必须是合法和核实在适合论坛的一个正式成员之前。 请务必使您可以为我们的网站有的所有发送同样的消息到多个新闻组过滤器失去能力，因此电子邮件可能到达您 . あなたの電子メールアドレスはフォーラムのフールメンバーに似合う前に正当、確認されなければならない。 電子メールメッセージが達することができるようにあなたが私達のウェブサイトのために持つかもしれないスパムフィルターを不具にすること確実がありなさい。 Hilfe in Deutsch, Ayuda en español, Aide 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 ....... 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 LimeWire and FrostWire users 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. 2. Spamming and excessive advertising will not be tolerated. 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. 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. 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. 10. Posts should have descriptive subjects. 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. 12. Signatures may be used as long as they are not offensive or sexually explicit. 13. 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 |
May 24th, 2004
| |||
| |||
 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
__________________ amigas and panheads and guns, oh my! |
|
May 24th, 2004
| ||||
| ||||
| 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 05:54 PM. |
|
May 24th, 2004
| |||
| |||
| 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?
__________________ amigas and panheads and guns, oh my! |
|
May 24th, 2004
| ||||
| ||||
| 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 |
|
May 24th, 2004
| |||
| |||
| Quote:
Quote:
"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:
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.
__________________ amigas and panheads and guns, oh my! Last edited by Scott Drysdale : May 24th, 2004 at 08:33 PM. |
|
May 24th, 2004
| ||||
| ||||
| 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 |
|
May 25th, 2004
| |||
| |||
| 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.
__________________ The more you debug it, the more it bugs |
|
May 12th, 2005
| |||
| |||
| "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!
__________________ amigas and panheads and guns, oh my! |
|
May 12th, 2005
| |||
| |||
| 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. |
|
May 12th, 2005
| |||
| |||
| Quote:
 Quote:
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.
__________________ amigas and panheads and guns, oh my! |
|
May 12th, 2005
| ||||
| ||||
| Just as a side note: Over the past week I've noticed I was able to both browse & direct connect to several Bearshare clients. Made me realise that BS is finally becoming more Gnutella user friendly & compliant for other Gnut clients. But I just tried it with you & no go. Surprising considering you've upped your upld bandwidth over 15 times. Perhaps it's a bug in your particular beta version. I have 0 up & down at moment. Perhaps you don't have BS open at this moment. |
|
May 12th, 2005
| |||
| |||
| It should be happening with earlier versions, because it was a bug. If it isn't happening with earlier versions, find me the person who developed a time machine. It shouldn't be happening with 4.8.1, because the bug was fixed. It doesn't happen when downloading from LimeWire, so the problem probably has something to do with some weird way that BearShare responds. BearShare does do strange things fairly often. I can't do much if you're going to be fatalistic about being told it's fixed. It's fixed. EOS. |
|
May 12th, 2005
| |||
| |||
| Quote:
bearshare's running 24/7 (except the brief "stop/download latest beta/start", or brief "windows wants restart" events). currently, a 4.0.10 is stuck on "hayseed dixie - walk this way".
__________________ amigas and panheads and guns, oh my! |
|
May 12th, 2005
| ||||
| ||||
| Quote:
Quote:
Quote:
the "strange thing" that's happening, if you read the posts on the subject, is that limewire is requesting BEYOND the EOF, and bearshare is politely truncating the request to what's available, which, for some reason, ALWAYS happens to be 10 bytes. limewire then repeats the too-large request, and round we go forever. note that the victim bearshare source has never reported to the misbehaving limewire downloader the wrong file size that limewire is requesting. Quote:
i've half a mind to buy a pallet of dramamine, several barf pails, learn java, and fix the damn thing myself.
__________________ amigas and panheads and guns, oh my! |
| Thread Tools | |
| Display Modes | |
| |
Similar Threads | ||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Limewire or Bearshare | urin4aloss | General P2P Network Discussion | 4 | September 18th, 2005 05:37 AM |
| BS forums on bearshare.com ? - A NEW Temporary Address For BearShare.net !!! | kevver | Open Discussion | 6 | July 13th, 2005 09:09 PM |
| Bearshare or Limewire | Layziebone | Open Discussion topics | 1 | April 2nd, 2005 08:57 PM |
| limewire downloading from bearshare | Scott Drysdale | Download/Upload Problems | 20 | April 28th, 2003 08:54 AM |
| Limewire vs. Bearshare | pc911 | Download/Upload Problems | 0 | January 29th, 2002 11:02 PM |
Linear Mode
