Author Topic: Feature Requests  (Read 17035 times)

0 Members and 1 Guest are viewing this topic.

Offline Markus

  • Administrator
  • Elite
  • *****
  • Posts: 5740
  • Karma: +25/-8
    • View Profile
    • http://www.planetpeer.de
Feature Requests
« on: September 01, 2004, 06:18:07 AM »
If you have reasonable suggestions for further MUTE development or you have feature requests please feel free to post it here 8)


Cheers,
Markus

Offline submarine

  • Regular
  • **
  • Posts: 69
  • Karma: +0/-0
    • View Profile
Feature Requests
« Reply #1 on: September 01, 2004, 10:19:05 AM »
request:

settings for the max. up-/downlaod bandwith, the mute client is allowed to use

Offline nglwarcry

  • Advanced
  • ***
  • Posts: 190
  • Karma: +2/-0
    • View Profile
Feature Requests
« Reply #2 on: September 12, 2004, 11:17:31 AM »
1: Multiple shared directories; there could be one Main shared directory, and other directories out from the Main.
2: file type to search : Video, Audio, Document, Program ...
3: Chat.
nglwarcry

Offline submarine

  • Regular
  • **
  • Posts: 69
  • Karma: +0/-0
    • View Profile
Feature Requests
« Reply #3 on: September 12, 2004, 12:45:28 PM »
multisource download

Offline noigeaR

  • Regular
  • **
  • Posts: 62
  • Karma: +1/-0
    • View Profile
Feature Requests
« Reply #4 on: September 14, 2004, 08:27:47 AM »
automatically resume unfinished downloads after program restart.
this could be implemented by saving the hash of partial downloads when mute is closed and when mute is started the next time, search in the background for the hash. if found, resume the download, otherwise periodically search again for the hash.
the way it is now is very uncomfortable, because you can only see the filename of partial downloads in the incoming directory and you have to search for those files yourself. when you find it, you can't even be sure it's the same file or if it's a different file with the same name, because the hash of partial downloads is not saved anywhere. mute will simply resume with the wrong file and delete it when it's finished because the file is corrupt. that's very user unfriendly...

Offline startail

  • Posts: 2
  • Karma: +0/-0
    • View Profile
Feature Requests
« Reply #5 on: November 19, 2004, 10:35:42 PM »
* Search Tabs (More than one search at a time)
* Search Type (Audio, Video, Images etc)
* Sort search lists ASC/DESC for eatch.
* Ability to clear Upload List (or every x minutes)
* Shared files Tab.

Just a few things I can think of that I would love to see in MUTE :)

Offline skittl

  • Newbie
  • *
  • Posts: 7
  • Karma: +0/-0
    • View Profile
Feature Requests
« Reply #6 on: December 01, 2004, 04:50:02 PM »
A kick/ban function for host IPs would be pretty useful.

Offline JKL

  • Posts: 4
  • Karma: +0/-0
  • Planet Peer Community
    • View Profile
Re: Feature Requests
« Reply #7 on: December 22, 2004, 12:50:17 PM »
I'd like to have a new help file. At least i would like to have info about all features of MUTE. It would be nice to have a complete info about the way Mute works and so on. Its pretty hard to serach those infos from various web sites and forums. For example I would like to know more about that connections page: how does that add host work and why (for me) it doesnt work at all. Also what that maintain at least x neighbors do cos i can search and dl files when im having just 1 neighbor.Also is there a way to make neighbors stable what i meen by this: can i at the beginning connect to neighbors i choose to and stay connected with them. Also i want info about searching why the results are different almost every time and why i cant find every file that are in MUTE network. I think this is because the neighbors change but can i make them not to.  These are just examples but i would like to have a more complete info for MUTE.
« Last Edit: December 22, 2004, 01:06:58 PM by JKL »

Offline JKL

  • Posts: 4
  • Karma: +0/-0
  • Planet Peer Community
    • View Profile
Re: Feature Requests
« Reply #8 on: December 22, 2004, 12:59:12 PM »
If you could find a way to separate those bottle neck users with slow connections from high speed users. Because now every download is slow cos it goes through those bottle necks.

Offline MainBrain

  • Posts: 1
  • Karma: +0/-0
  • Planet Peer Community
    • View Profile
Re: Feature Requests
« Reply #9 on: December 27, 2004, 03:37:28 PM »
No idea how MUTE handles file transfer on lower levels but you might want to check this out anyways... forward error correction with tornado codes.

Lets say A sends a file to Z through nodes B,C,...,X,Y
Now split the file in 'n' parts and compute an overhead of 'k' parts. Now A begins to send the (n+k) parts in any order to Z. Now if Z receives ANY 'n' parts of the file or the overhead then erasure codes can rebuild the complete file.
This adresses the problem of lost packets but it has more advantages. In large scale p2p networks like edonkey it often happens that 90-95% of the parts are downloaded pretty fast because they are common but you have to wait ages for the last few percent. Using erasure codes and distributing the (n+k) packets randomly and by chance up to 'k' of those packets are uncommon then the file can still be downloaded fast because 'n' packets are common and the file can be rebuilt using those packets.

Erasure codes are used in usenet's .par files. As far as I know they use Reed-Solomon but it takes hours to rebuild larger files. The solution: Tornado Codes. Much faster and only little more then 'n' parts are neccesery to rebuild the file.
Benchmarks available here: http://www.icsi.berkeley.edu/~luby/erasure.html

Tornado codes are explained here:
http://www.icsi.berkeley.edu/~luby/PAPERS/losscode.ps

Check the researchers website for in depth information on forward error correction with tornado codes you might also want to check out "digital fountain":
http://www.icsi.berkeley.edu/~luby/index.html

As far as I know digital fountain and tornado codes are patented but that does not apply on european laws right? O_o

Offline Gemma

  • Posts: 1
  • Karma: +0/-0
  • Planet Peer Community
    • View Profile
Re: Feature Requests
« Reply #10 on: January 25, 2005, 07:22:48 PM »
All things said before:

1. multisource download. (The one I think it needs the most)

2. resume unfinished downloads.

3. ability to limit upload and download

Offline crypton

  • Elite
  • *****
  • Posts: 1699
  • Karma: +10/-0
    • View Profile
Re: Feature Requests
« Reply #11 on: January 25, 2005, 07:40:27 PM »
1. Multisource Download ( must need)

2. crypted chatsystem

3.
« Last Edit: January 26, 2005, 04:05:46 PM by defnax »

Offline noigeaR

  • Regular
  • **
  • Posts: 62
  • Karma: +1/-0
    • View Profile
Re: Feature Requests
« Reply #12 on: January 26, 2005, 07:21:20 AM »

2. resume unfinished downloads.


mute does resume downloads. if you download an unfinished file again, it will continue with the partially downloaded file. it's just very uncomfortable to have to search for the files again every time you restart the client. that's not very user-friendly, so i've contacted jason about this and he told me he doesn't like programs that do things automatically in the background...  :-\
if you want more comfort, try mfc mute or napshare, they save partial downloads in a queue and automatically resume them when you restart the client!

Offline Borky

  • Posts: 4
  • Karma: +0/-0
  • Planet Peer Community
    • View Profile
Download que
« Reply #13 on: February 12, 2005, 07:55:57 PM »
A download que would be useful.  In searching for file, its possible that one virtual address will have many files that you wish to download.  It would be great if all of them could be added to a que rather then try to download them all at once, or have to manually download them individually.

EDIT: It would also be cool if downloads that fail would automatically retry.  I imagine this might be problematic to the network if clients were continuously requesting inaccessible files, but maybe it could be done on an appropriate delay.  Combining this with a download que, and one could trully "set it and forget it" :)
« Last Edit: February 15, 2005, 02:02:42 PM by Borky »

Offline ncunuclear718

  • Posts: 1
  • Karma: +0/-0
  • Planet Peer Community
    • View Profile
Re: Feature Requests
« Reply #14 on: March 04, 2005, 10:30:22 AM »
"Multisource download" is most important.

My second suggestion is about search function
Maybe some bad-man will corrode this system by send many  search requestion to system. Obviously too many search requestion in system will be slow the download/upload speed. 
Now I don't have exact solution of this problem. But may be "KAD(a function in Emule)" is a good example for this trouble,maybe we can try to restrict some unreasonble key words search.
for example : the search word is too short(less than three just like: "as"  "in"  "av"  )

I think the function of "Multisource Download" is most important, Is possible contain this function into next version??
 
 
« Last Edit: March 05, 2005, 05:27:11 AM by ncunuclear718 »