Official LimeWire 4.1 requests thread

[et voilà]

Note 1: can some mod make that sticky?
Note 2: This is not already may 18th, but I thought we might begin to discuss about new features already Just be sure to download the latest beta of 3.9.x before making any requests http://www.limewire.com/english/content/beta.shtml

Allons-y!!!
This is the feature request for the LW 4.1 development branch that will end up in the final version of LW 4.2. Contribute to LW advancement!!!

Please make your requests clear, please try the latest version (beta if any) before posting something that might be already included.

Merci beaucoup.

MY feature requests:
1) max simultaneous transfers of the same file option (very important when you share a popular big file, it takes all uploads slots then you can't share anything else)

2) reorganisation of preferences:
a) no more firewall option (rename port option to firewall? IPs should be forced no matter what, like other P2P, this option was confusing users and me, I might add...)
b) the search option (limit, quality and speed) should be eliminated (with recent protocol enhancements it serves nothing)
c) in advanced no more compression option (default proved to be ok)
d) port (rename it firewall) should get out of advanced
e) no more out of band option (default proved to be ok, LW ajusts automatically if host is firewalled)

3) New system of requieries with the 6 first digits of sha1 (more than 2 billions possibilities, à la kazaa), dynamic querying for 1 result by UP BUT a max of TTL=3. ie urn:sha1:RPXYFG The time of the requery should be like it was in LW 2.8.6 (one requery per hour MAXIMUM period, when a file needs more sources) When LW receives a result (with the complete sha1 of 32 digits) it compares the complete sha1 of the two files, if it is the same, the transfer begins... This should allow more transfers with LW unattended and make newbies and pro alike happy

4) a file rating system, you rate the files you download or share in terms of quality, this way fakes and garbage files will be less displayed, this idea is taken from Shareaza.

5) browse other clients in upload window (Bearshare and ACQX support the protocol but LW doesn't try to browse them)

6) proxy browse hosts so we can tell who is really leeching, not who in behind firewall

7) nio technology so LW takes less ram on my old computer...

Ciao

[stief]

--Client side queuing of multiple requests to a single source
--remember advanced stats checkbox between sessions
--remember preferred sort orders between sessions
--be able to clear all sort orders
--explore button on download page
--a private folder that can be accessed only by trusted users
--allow certain upload folders to get preferred status in upload slots (reserving upload slots for certain folder access). i.e., anyone requesting myprecious.jpg never has to wait for an upload slot.
--an option to connect to fewer ultrapeers when acting as a leaf
--a 'mailto' button for formatting and sending magnet links
--multiple download folders organized by file type
--sharing of portions of iTunes selections by choosing a playlist
--an Edit menu! (and ability to select and copy any displayed text.)
--ability to send a download filename to the search box

[sberlin]

Whew! These are enough suggestions to last a couple of versions! They all look good though.... keep'm coming.

[rkapsi]

--allow certain upload folders to get preferred status in upload slots (reserving upload slots for certain folder access). i.e., anyone requesting myprecious.jpg never has to wait for an upload slot.
--sharing of portions of iTunes selections by choosing a playlist
--multiple download folders organized by file type

Sam, as we talked recently about a needed killer feature for XYZ, this is IMO one.

--an Edit menu! (and ability to select and copy any displayed text.)

Not to mention the shortcuts for the Menu Items.

[stief]

great thread et voilà (especially the requery idea)

re the "mailto" button (LIMELINE?)
-- a "mini" LW to handle the magnet. A disposable LimeWire? small enough to be a hotmail attatchment, and just large enough to securely download the magnet and advertise the full LW. I could send my mother a picture without having to talk her through a full LW install or explaining all the files she'd see when she'd accidently hit the what's new button! Goodbye ftp, iDisk, gigabyte googlemail, and attachments!

--a window menu to bring chat, options, stats and the main window to the foreground.

--browse host that would display results with directory structure like in the Library (or have the option to show the directory structure for any search result)

[rkapsi]

--LIMELINE
Interresting. I don't know if LimeWire can be made small enough to be a hotmail attachment but... One word: WebStart! A slim version of LimeWire hosted at limewire.com which cannot search etc. and regular LimeWire (maybe only for Pro?) clients can create .jnlp files similar to magnet links.

http://java.sun.com/products/javawebstart/demos.html

-- java.awt.dnd support for the Library.

http://java.sun.com/j2se/1.4.2/docs/...e-summary.html

[et voilà]

Salut, I just wanted to pust more pressure on the automatic find more sources feature, you know rare files don't maintain a download mesh
This feature is standard in other apps and people using LW are expecting it.
In it's defense, the bearshare labs also proved in their tests that the network was more efficient with it on if it doesn't limit search horizons.
So now I'm asking to LW team (everybody too): what do you believe is the most easy and efficient way to implement requieries (not putting too much stress on UPs)?

1) a DHT like hashes system (or a kamdelia one like emule which works great is open source) with some ultraleaves storing hashes (new kind of network topology)

2) hash searches like in my suggestion above (same network topology)

Merci pour le bon travail!

[rkapsi]

I've made a short test if it's worth to truncate the SHA1 URNs to 6 digits.

The raw string length saving is 81% but with compression is the saving only ~50% compared to a complete and compressed SHA1 URN (or other way around; for only 50% extra you get the real deal with 100% accuracy) and we're talking here about 26 vs. 52 bytes. I cannot estimate if it makes a big difference for UPs as it sums up over time and load.

Note: the calculations include a fixed gzip header. Without this header are the numbers a bit better (up to 70%) but it's still less than what you save by truncating the string. String compression is quite effective.

[et voilà]

Danke Roger, so it might only save 50% bandwidth over a normal requery... but substract the number of searches I do to maintain a download alive, we sure save bandwidth in my case Maybe we could add a definite number of find more sources for one download: ie after three -consecutive- no more sources after a requery, the download state change to "failed to download, try another file". I know users that build list of incomplete downloads in the hundreds, so they'd always be requerying once an hour....

Ciao

[cmcnulty]

The one thing that prevents me from installing LimeWire on more computers (my Mom's, for instance) is the *easy* ability to monitor incoming searches. Who uses this? I know it tried to filter the worst smut, but plenty still slips through. Why can't this be moved to the stats page? I know you can search for the items that appear here, but does anyone actually do that?

-Cm

[verdyp]

Originally posted by rkapsi
I've made a short test if it's worth to truncate the SHA1 URNs to 6 digits.

I vote against it: do you know the "birthday paradox" and is effect on strong hashes? (The birthday paradox is born from the fact that any classroom of only 24 children will have at least 1 pair of children with the same date of birthday; this is a proven mathematical effect).

It says that a cryptographically strong hash algorithm that can produce 2^n distinct values will happen to produce two identical hashes with a 50% chance by only hashing 2^(n/2) distinct files.

With 6 hex-digits, such hash would generate only 2^24 possible values, with a 50% chance of collision when hashing only 2^12 files (and provided that the hash algorithm is really cryptographically strong). That would mean hashing only... 4096 files before getting a collision.

If we say that there are about 200,000 hosts reachable at one time, and that each share a very modest average of 40 files, this means that we will need 200,000*40 possible distinct values, i.e. 4 millions (or 23 bits) with at most one pair of colliding files.

Add the connection time and the fact that there are millions of users of Gnutella which can introduce new files at any time, the need of distinct values goes over 2^32 possible hash values, and the hash must be twice larger (so at least 64 bits).

The cryptographic strength of SHA-1 is not 128 bits as you think but just above 64 bits (2 years ago it was estimated at about 96 bits, but cryptanalysis has shown that the strength was a bit lower). SHA-1 has still no been cracked, but it's one good reason why the European Union launched the NESSIE evaluation project and as well as the US government. An agreement was found with SHA-256 and Whirlpool... whose estimated cryptographic strength for now is at 192 bits. Tiger-160 was eliminated due to the evaluation time and implementation delay (its estimated 128 bits strength is not enough for the ten years that are coming). 128+160 bits "Bitprints" have a strength of about 192 bits, roughly identical to SHA-256.

Conclusion: we must not reduce the size of SHA-1 hashes to less than 128 bits...

[et voilà]

Philippe you didn't understand... the Sha1 is normal at 32 digits but once it is computed we cut it to the first 6 digits to requery using less bandwidth. Yes there are more chances of collision, but the search result contains the 32 digits sha1 that the downloader can compare to the complete sha1 of the file he is downloading, so no downloads of collisions, only possible in search results. But in the end users get more chances to complete rare files and the network isn't under pressure as it would be with the complete sha1 requiery.

Do I have to understand that you are more for the kamdelia approach?? I'm feeling too that it is a less quick and dirty way to deal with requieries...

Ciao

[verdyp]

Originally posted by et voilà
Do I have to understand that you are more for the kamdelia approach??
I'm feeling too that it is a less quick and dirty way to deal with requieries...

There was no reference to Kademlia in my message, which just explains why 6-bytes hashes (24 bits) are very weak to identify files (some users may think that the 16 millions possible values it allows should be enough to identify all files available on Gnutella, when I just explain that it will be enough only to manage very small subsets of files)

OK I had not understood that you added the verification step after finding a reference. That's a good idea which is statistically correct. The fact that a 6-byte hash will produce collisions 50% of the time every 4096 randomly found files, means that the total risk of collision when querying a source will be below 1% (but it will not be null, and that's why the verification step is required!). So the overhead of veryifying the source with the complete hash will be extremely small face to the gain in bandwidth for locating the candidate sources.

This statistic optimization is similar to the statistic optimization performed in QRP with 16-bit hash values (64K tables) whose cryptographic strengh is about 6-bit (64 average values, enough to divide the traffic to 2% for moderately filled QRP tables; if QRP tables are filled at 25%, the collision risk is evaluated to roughly 80%, and QRP will be loosing its capacity to filter searches efficiently; however, for more than 80% of leaf nodes that have QRP tables filled below 10%, the collision risk for non-matching keywords falls under 25%, which means that QRP can filter 75% of queries sent to shielded leaf nodes, saving much bandwidth on UltraPeers, and allowing them to support more leaf nodes).

[Matamoros]

Originally posted by cmcnulty
The one thing that prevents me from installing LimeWire on more computers (my Mom's, for instance) is the *easy* ability to monitor incoming searches. Who uses this? I know it tried to filter the worst smut, but plenty still slips through. Why can't this be moved to the stats page?
-Cm

Usually one of the first things I do when I startup LW is shut this pane. I wouldn't miss it if it was moved somewhere else...

[et voilà]

ok Philippe, glad you got my idea I was referring to kamdelia as it is the other alternative to the sheme I made as a proposal for requieries... ie I want LW to ABSOLUTLY include requieries. I just want to discuss with folks what way is the best.

Ciao