P2P-Zone - View Single Post - Search List for Kazaa

SA_Dave · 29-05-02, 03:17 PM

I like this idea, but it needs improvement!

It would be convenient to schedule unattended searches.

Time-zone differences play a large role in the availability of certain files. However, even with filters enabled, the results would be overwhelming in some cases. How are you going to avoid the 'the file you selected is currently downloading...' message, as well as poorly-renamed duplicates and junk files?

It should be up to each user as to what is queued, so I'd prefer that a database of UUHash data (little disk space needed) was maintained locally, so that startfiles of specified results could be created later.

I don't believe that too much slowdown of the network would occur, as Wanker suggested. The FT network was designed to accomodate this : more sources are constantly being searched for as you download and this is why the use of MorpheusX hasn't caused total bogdown (as was the case with eDonkey and the bot). Especially now that Kazaa 1.7's 'search more' feature has been introduced, even if you do 10 searches a day, you may in reality be doing 50-1000 searches in total (depending on the size of the files, availablity, bandwidth etc.) I don't believe Kazaa would've implemented this if it would impact network performance (not that I'm using that version anyway.

)

The search function of FT clients is fundamentally FLAWED IMO.

This proposed bot could alleviate some current issues, but ideally the entire experience needs to be altered. Here are my desired improvements :
[list=1][*]Improved Options For Customisable Searches : I want to be able to create new categories or add file-types to previously defined categories. For example, I could add .rm to the video search. This feature would be particularly useful for rarer file-types. It's really frustrating when you get no results for a specific search, but get 100+ irrelevant/offensive results in a general search, even with filters enabled!

I hate then having to add 20 or more keywords to be filtered in order to even catch a glimpse

of a relevant result.

[*]Improved Search Engine : The current search engine is far too limiting! It only returns results for exact matches, with the exception of '_' which represents a space or underscore (but this is logical!) Boolean searches would be nice. It would also be nice if some sort of relevancy algorithm were used (like on internet search engines) to account for misspellings etc.

Wildcard characters shouldn't necessarily be supported, as this could increase search traffic & cpu use of supernodes. Another nice feature would be auto-sorting of search results by category, much like the ability to categorise files in many download managers.

[*]Ability To Queue Offline Files : This feature would make me go

I started using Napster in September '99 and ditched that buggy, overrated piece of bloatware in early December. Why? I found an obscure link on Lycos to a site that changed my life! In case you didn't know, AG is a great place for rare music, because it maintains a db of all files shared in a 30 day period. This eliminates the need for repetitive, all-day/all-night searches and greatly decreases search traffic. The only disadvantage is that queues are server-based and self-refreshing every 30 days. It would be great if supernodes could maintain a quasi-database of all files shared by the peers that connected to it in a certain timespan. How could this be done? The SN could maintain a db of sigs, each requiring about 1Kb of disk space. About 1000 sigs per Mb, so superpeers with little disk space would need a greater refresh rate or the ability to disable this feature. However, each SN has a maximum number of peers, which are also limited by geographical location. This limits the db size and as hard drives get bigger and cheaper it should be easier to implement. An added benefit is that since each peer connects to 2 or more SNs, this provides a rudimentary RAID structure to the database if a SN goes offline or doesn't have enough hdd space to maintain an accurate db. This database might not be as readable as AG, but as hosting websites via p2p becomes more common it might be possible for the supernode/s to serve a site for a web-style search. The 'qeueud' files are peer, not server/SN, based in this model. The search results should preferably display different icons for offline/online files.[*]Improvements To Interface : Like in iMesh, it would be nice to switch to search or traffic views while offline. I like to see what's downloaded overnight and I sometimes do a search before bedtime, to queue at my leisure in the morning. It would save bandwidth if I could preview files while offline from within Kazaa and perhaps cancel transfers without opening each .dat file in my favourite hex editor & deleting them manually.

[*]Increased Incentives To Share : The 'disable sharing' option has to go!

The option is too easy for even Newbies to find and people use it because it's there! Again using Audiogalaxy as an example, you cannot download more than 1 file at a time unless you're sharing at least 25. Also, many of its users don't know how to use explorer or even what .mp3 files are! Making the program easy to use for newbies (i.e. media capabilities, having to share to download a lot etc.), while transparently sharing as much as possible, is how file-sharing should be. Perhaps a more intelligent bandwidth control is needed, to encourage those with caps to share. See also next point.[*]Prioritisation Of Transfers : This might be difficult to implement & would probably have to be written to the .dat file itself (like the "paused" status). The reasons are clear : you want the rare files to be downloaded ASAP (d/l priority), but the uploader might also have spent ages getting the file. The uploader should have the choice to give queue priority to the person whose sharing (u/l priority). If some sort of db was maintained (point 3), you might be able to prioritise based on quality, rather than quantity of shares, according to your own criteria. This is related to above point.

[*]Giving "SuperPeers" More Control : The ability to deny users sharing specific content, send messages to users about viruses for example, maintain themed db's (point 3) or user bases in Direct Connect fashion etc. This would allow SNs, not a parent company, to control the network while maintaining the ease-of-use and transparent features for standard peers.

[/list=1]

Sorry for the long post, but these are the features that I believe would make a FT (or OpenFT) client almost perfect.

29-05-02, 03:17 PM	#14
SA_Dave Guardian of the Maturation Chamber Join Date: May 2002 Location: Unimatrix Zero, Area 25 Posts: 462	Regarding original suggestion... I like this idea, but it needs improvement! It would be convenient to schedule unattended searches. Time-zone differences play a large role in the availability of certain files. However, even with filters enabled, the results would be overwhelming in some cases. How are you going to avoid the 'the file you selected is currently downloading...' message, as well as poorly-renamed duplicates and junk files? It should be up to each user as to what is queued, so I'd prefer that a database of UUHash data (little disk space needed) was maintained locally, so that startfiles of specified results could be created later. I don't believe that too much slowdown of the network would occur, as Wanker suggested. The FT network was designed to accomodate this : more sources are constantly being searched for as you download and this is why the use of MorpheusX hasn't caused total bogdown (as was the case with eDonkey and the bot). Especially now that Kazaa 1.7's 'search more' feature has been introduced, even if you do 10 searches a day, you may in reality be doing 50-1000 searches in total (depending on the size of the files, availablity, bandwidth etc.) I don't believe Kazaa would've implemented this if it would impact network performance (not that I'm using that version anyway. ) The search function of FT clients is fundamentally FLAWED IMO. This proposed bot could alleviate some current issues, but ideally the entire experience needs to be altered. Here are my desired improvements : [list=1][]Improved Options For Customisable Searches : I want to be able to create new categories* or add file-types to previously defined categories. For example, I could add .rm to the video search. This feature would be particularly useful for rarer file-types. It's really frustrating when you get no results for a specific search, but get 100+ irrelevant/offensive results in a general search, even with filters enabled! I hate then having to add 20 or more keywords to be filtered in order to even catch a glimpse of a relevant result. []Improved Search Engine : The current search engine is far too limiting! It only returns results for exact matches, with the exception of '_' which represents a space or underscore (but this is logical!) Boolean searches would be nice. It would also be nice if some sort of relevancy algorithm were used (like on internet search engines) to account for misspellings etc. Wildcard characters shouldn't necessarily be supported, as this could increase search traffic & cpu use of supernodes. Another nice feature would be auto-sorting of search results by category, much like the ability to categorise files in many download managers. []Ability To Queue Offline Files : This feature would make me go I started using Napster in September '99 and ditched that buggy, overrated piece of bloatware in early December. Why? I found an obscure link on Lycos to a site that changed my life! In case you didn't know, AG is a great place for rare music, because it maintains a db of all files shared in a 30 day period. This eliminates the need for repetitive, all-day/all-night searches and greatly decreases search traffic. The only disadvantage is that queues are server-based and self-refreshing every 30 days. It would be great if supernodes could maintain a quasi-database of all files shared by the peers that connected to it in a certain timespan. How could this be done? The SN could maintain a db of sigs, each requiring about 1Kb of disk space. About 1000 sigs per Mb, so superpeers with little disk space would need a greater refresh rate or the ability to disable this feature. However, each SN has a maximum number of peers, which are also limited by geographical location. This limits the db size and as hard drives get bigger and cheaper it should be easier to implement. An added benefit is that since each peer connects to 2 or more SNs, this provides a rudimentary RAID structure to the database if a SN goes offline or doesn't have enough hdd space to maintain an accurate db. This database might not be as readable as AG, but as hosting websites via p2p becomes more common it might be possible for the supernode/s to serve a site for a web-style search. The 'qeueud' files are peer, not server/SN, based in this model. The search results should preferably display different icons for offline/online files.[]Improvements To Interface : Like in iMesh, it would be nice to switch to search or traffic views while offline. I like to see what's downloaded overnight and I sometimes do a search before bedtime, to queue at my leisure in the morning. It would save bandwidth if I could preview files while offline from within Kazaa and perhaps cancel transfers without opening each .dat file in my favourite hex editor & deleting them manually. []Increased Incentives To Share : The 'disable sharing' option has to go! The option is too easy for even Newbies to find and people use it because it's there! Again using Audiogalaxy as an example, you cannot download more than 1 file at a time unless you're sharing at least 25. Also, many of its users don't know how to use explorer or even what .mp3 files are! Making the program easy to use for newbies (i.e. media capabilities, having to share to download a lot etc.), while transparently sharing as much as possible, is how file-sharing should be. Perhaps a more intelligent bandwidth control is needed, to encourage those with caps to share. See also next point.[]Prioritisation Of Transfers : This might be difficult to implement* & would probably have to be written to the .dat file itself (like the "paused" status). The reasons are clear : you want the rare files to be downloaded ASAP (d/l priority), but the uploader might also have spent ages getting the file. The uploader should have the choice to give queue priority to the person whose sharing (u/l priority). If some sort of db was maintained (point 3), you might be able to prioritise based on quality, rather than quantity of shares, according to your own criteria. This is related to above point. []Giving "SuperPeers" More Control : The ability to deny users sharing specific content, send messages to users about viruses for example, maintain themed db's (point 3) or user bases in Direct Connect fashion etc. This would allow SNs, not a parent company, to control the network while maintaining the ease-of-use and transparent features for standard peers. [/list=1] Sorry for the long* post, but these are the features that I believe would make a FT (or OpenFT) client almost perfect.