Official LimeWire 4.1 requests thread
 

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 :p 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

--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

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

--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. :D

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

Not to mention the shortcuts for the Menu Items.

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!:rolleyes: 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)

--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

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!

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.

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....:D

Ciao

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

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...

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

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).

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...

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. :p

Ciao

:D My behaviour at startup to!

I don't want requeries... that's a difference. However it could be useful for the "looking for more sources" search after a download fails. Querying with a full URN may not be necessary, when we can simply look for sources with truncated URNs. However the problem is how to route such queries: QRP table contents would need to be changed... So I wonder if instead, we couldn't search by lists of precomputed QRP hash values (instead of strings). This would not fit in a classic search string due to its 32-bit binary values (where the least significant bits are cleared depending on QRP table sizes). In this case a search would be non-empty if just looking for these QRP hashes without any search string, which could as well be a QRP hash of the full SHA-1 URN (acting like a truncated SHA-1). This would go into a Query GGEP extension (search by keyword hash). It would be interesting mostly for long QRP keywords like URNs. If the query contains two hashes, it is exactly like two keywords and should match with the same policy (AND). With queries containing 4 hashes or more, 2 hash values on 3 should be enough to match.

Although I don't like requiries, there's a way to handle the number of keywords in queries, to look for alternative subsets of keywords in separate queries.

You know Philippe I'm wary of requierys too, they could destroy the network :( But since LW are clustered together it diminishes the impact of other bad behaving clients. Yes, QRP content would have to be changed to match to trunketed sha1. I'm thinking: once a leave requery, why wouldn't the UP keep it in mind and say send those accumulated hashes from all leaves in a big search twice an hour (this way UP could control requieries and the UP could struture those hashes in a way it could save bandwidth)? I'm proposing here as I'm not a protocol guru like you Philippe;)

The requieries I want are also automated not manual but they happen only when an host needs more sources (one query by hour per client max)

Also without them Gnutella will never be a good place to look for rare big files like videos, requieries would induce diversity in big files an advantage of emule and overnet.

If you want to contribute, there's a Chord subproject in LimeWire, which is stale since long and experimental, but can be the base of such search architecture for unique IDs.
In Chord, some hosts are responsible of managing routes for some "fingerbits". Those hosts should better be UltraPeers (they need to have long availability to minimize the cost of structure updates), but for now we don't have enough UltraPeers with the latest version to allow deploying this parallel network.
Now that LimeWire 4.0 will be officially released and that it will clearly demonstrate an advance of efficiency in Gnutella searches with a much reduced bandwidth usage, the LimeWire cluster of UltraPeers could become a good candidate to start experimenting with Chord (or other structured topologies).
Before that we need to see the impact on Gnutella of the deployement of LimeWire 4.0. The next weeks will be used to monitor the evolution of traffic and see how much we can gain on the overall network (and as well take the time to correct or fine tune some statistical or usage policy parameters).
For now, I'm not inclined to change the QRP algorithm and routing. It's probably better to think about a parallel topology with separate routing tables for such searches by URNs.
QRP has been done and tuned mostly for keyword searches, with a very weak distribution of keywords.
Including URNs in QRP had a negative impact on routing efficiency (but it has been compensated by the introduction of the low-TTL/high-degree topology in association with dynamic querying).
My opinion is that, if we can remove URNs from QRP tables, the network will be better, but we can't do that before a new more appropriate routing topology is made and tested for URNs, and then deployed, tuned and scaled.

Any chance someone can start up a new thread with the requery/DHT discussion, and/or copy the already-requested features in this thread to a new thread that I'll make sticky?...

It'd be very useful to _just_ have feature requests in a thread.

Sam you are the one well placed to create a new thread:)

-I'd like a bandwidth status down/up ie 12KB/s down 10KB/s somewhere in the GUI always diplayed (maybe in the bottom at the connection quality level) or it could be included in the icon (in osx dock) or in the application instance (windows bar) à la overnet.

whole word searches
 

I would like to see whole word searching (does Gnutella support this?). Why?

One example: searching for "Irene Kral" returns many hits for "Diana Krall". No problem if the filename includes the name of the singer or even the ID3 tag, but many many files lack both -- apparently on many peoples' systems only the pathname indicates the artist. It is a nightmare!

Another: "Yo-Yo Ma". Any idea how many names and titles include these strings??? Give it a try yourself :(

Keep it non-denominational please
 

I'd thought of this as well; good suggestion.

Ummm, LimeWire and Java are cross-platform, no? Can we talk about things in cross-platform terms please?

Re: Keep it non-denominational please
 

Yes it's portable, but Windows and Mac users benefit of a notification icon that can display a tooltip or text message.
This feature is not incompatible with Unix/Linux that can provide such information also in its status bar.

I've mentioned this before but the devs just seem to be confused when i say anything about it.

A Seekable media player, where you can drag across the Limewire Media player and move to diff spots in a song...it is possible, for MamiyaOtaru has done it with his last version of Aqualime. 3.8.6.2 (yea hes kinda lazy at releasing)

I've never had a direct response...can this be added?

For more info try out teh program it is up for download either at UTC or my site. This would be a milestone addition seeings how LW has has the had the original play right through no options to fast forward media player for it seems forever.

Although Limewire integrates a player, the main purpose of its presence is to allow easy preview of audio files downloaded. For best performance, there are tons of other players available. LimeWire has integrated an open-sourced Java player which is upgraded each time it gives additional performance benefits or reduced memory stress, but its development focus is not in adding CPU-intensive operations to detect spots in songs.
In some future, Limewire may include interfaces to interoperate with platform native players (that was done with iTunes on MacOS, but Windows Media Player or Real Player ot WinAmp interfaces may be possible, if there are some open-sourced interfaces that complies with the Limewire GPL.

Developing player components requires very specific and complex knowledge on codecs, and hardware acceleration support. This would be too much work for now for the LimeWire developers.

If AquaLime developers want to help LimeWire, they can contribute within the open-source project and share their experience with their component integration (but LimeWire requires now many compatibility and performance tests, and active support by the contributors to help solve issues, before such new code can be finally integrated into LimeWire and released; we don't want to include unstable and poorly tested components).

Some contributions (including my own ones) will not pass the tests phase or will be integrated in a unscheduled future release once the current planned priorities have advanced, and Limewire has understood how to support this new code.

In some future, my next works in Limewire will be to find the performance bottlenecks in the downloader classes (this part is one of the most complex classes with lots of cases to support interoperability with various servents, so I did not invest my time in optimizing it as development was quite complex; the automated tests suite for this part in the code is the longest one in LimeWire, and I prefer let LimeWire work on it), or to reduce again the memory footprint and VM stress when handling incoming Gnutella messages.

On MacOSX it would be nice if the file-vault (Dateisammlung) would be less intrusive on the filenames. Every time I open it, some name gets highlightesd even though I only wanted to see what is inside the folder, and when i click on another folder, the names are switched.

IMO you should have to click space, enter or something similar (or click a second time on an already selected file) to change the name. I nearly lost fiels though this...

fox's list
 

I'm glad to see someone else's whining about the edit menu besides me.

1. edit menu

2. symbol next to the X on the tab to pull down the tab menu. the apple button + mouse clic sucks.

3. re-search a corrupt file automatically. when a new on is found, replace it. put in the status section "replacing bad file"

4. IF user desires, let them use a name instead of the long host numbers. this would also take up less tag ************.

5. recently searched terms drop down.

My List
 

First off, I'd like to vote against defaulting compression to "on". It slows my machine, I don't need it, and I don't use it. I'd love to see an effective adult filter on the incoming searches page.

Maybe also something that'll slow the scrolling to less than realtime so I can read it without having to constantly toggle the on/off checkbox.

And I don't mind the discussion on the thread, I do however find it kinda sad that there are less suggestion posts than discussion posts. I suspect there are mor like me who've been building a list and haven't yet submitted here.

Here's what I've been wanting since I decided to take notes.

I'd like to be able to click on something other than a file in the list to clear the highlight off the file thats currently highllighted

The buttons at the bottom of the screen disappear when there are 9 tiers of search tabs at the top.

I've noticed while using the LW Pro skin that every hour or so the entire contents of the Java window blanks out to grey for a few seconds, and re-appears just as it was. It reminds me of when the taskbar crashes & comes back.

In the Incomplete folder- I'd like to see the status icons refresh themselves like they do in the search window. I'd also like to be able to select more than one file at a time, and to stay in the incomplete folder window after choosing resume, having the icon change instead of being sent to the download window.

I'd like the current search results to come back up when the app restarts, just as the downloads in progress do.

A warning dialog as the search limit is approached reminding that searches will be rolled off into oblivion if this one proceeds.

How about numbers along the left side of each file line?

In the incomplete folder, I'd like to see a date/time the download was started

When I highlight a page of Need More Sources, unhighlight the selection after I press the Find Sources button so I don't get sent down to the "w's".

I'd like a button that says Place selected file at end of queue, for those connections that sit at 0Kb/s for a long time and only
intermittently speed up, so that faster files in the queue can use the available download slot. Or maybe a user-defined timeout that determines how long a transfer can sit at zero before being automatically placed at the end of the queue. Or maybe give the intermittent low-speed connections a temp slot exempt from download slot limits.

Search option checkboxes, so we can do except searches.

The Tools>Options choices available for each individual search.

Commonly used Tools>Options controls available within their respective section, or maybe a slide out window, or even an airplane cockpit-like all controls on one page layout. Or direct-click access to user-defined options "favorites"

HOTKEYS!!!- Available regardless of window focus.

Exit after (User-Defined) transfers option in system tray context menu.

How about a search button where the chat button used to be which toggles the opening/closing of the left & top panes.

Add ".ape" to the default displayed filetype list.

Oops.
 

I just read my post & can't think of why I ever felt the need for hotkeys...

Re: My List
 

Very bad idea. You do use it, and others do, because compression vastly reduces the network traffic for staying in the Gnutella Net.
If you disable compression, not only you have more network traffic, but the hosts you are connected to as well.
So I'd suggest you leave it on (and besides: Some time to come other clients might refuse to connect to clients without comressin, because they want to save bandwidth for down and uploads).

Wouldn't be effective, because the hosts you found with that search are likely do be offline by the time you start again, so the results wouldn't be that useful. Better to restart the search.

this should be taken care of by LimeWire internally, because it simply allows one more slot, when the upload bandwidth you allow isn't maxed out.

And add smd;smc;gba;xcf;sitx;ppt;
These are:
Genesis-Rom, SNES-Rom, Game Boy Advance Rom, GIMP-Graphics-file, New StuffIt-Format, PowerPoint.

As soon as the MAGMAv0.2-spec is ready, adding .magma would also be nice.

new feature requests
 

Limewire requested features

-choose which download is currently active (when you only have 2 connections and many downloads you should be able to set others to awaiting sources (paused) or qued (lower priority)) and in the same context i would like to be able to set the download order.

- hide a selections in the search results. ie, eliminate the clutter

- Find or show search words in search results. For example, if my search is "King" and i get hundreds of hits but i only am interested in the ones with Martin and or Luther in the found set i want to see just those results.

Show CreativeCommons Metadata
 

Show Creative-Commons MetaData, so every User can see, which Music he/she can definitely share and download without any legal harrassment.

You can find images to use for the Licenses on the creativecommons website: http://www.creativecommons.org

Here is information, what is included in that MetaData:
For OGG-Files:
http://creativecommons.org/technology/ogg

For MP3s:
http://creativecommons.org/technology/mp3

Infos for MP3s quoted: