aMule Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're back! (IN POG FORM)

Pages: [1] 2 3 4

Author Topic: aMule-mod Xtreme  (Read 23282 times)

FreeToGo

  • Jr. Member
  • **
  • Karma: 3
  • Offline Offline
  • Posts: 65
aMule-mod Xtreme
« on: April 13, 2007, 01:05:16 PM »

Is there any chance to have amule-mod Xtreme? eMule-mod Xtreme is very popular. Is there any chance to port it to amule?

http://www.emule-mods.de/?mods=xtreme


 
« Last Edit: April 13, 2007, 01:06:50 PM by FreeToGo »
Logged
You can mock me. I can take it.

wuischke

  • Developer
  • Hero Member
  • *****
  • Karma: 183
  • Offline Offline
  • Posts: 4292
Re: aMule-mod Xtreme
« Reply #1 on: April 13, 2007, 02:33:14 PM »

Xtreme will never be ported to Linux/Multiplatform. And I doubt there are any features _really_ worth to be included in aMule.

Prove me wrong - request features which ou miss in aMule which Xtreme has.
Logged

FreeToGo

  • Jr. Member
  • **
  • Karma: 3
  • Offline Offline
  • Posts: 65
Re: aMule-mod Xtreme
« Reply #2 on: April 15, 2007, 06:31:58 PM »

Reask sources after IP change
- after emule detected a new client-IP, it inform all you sources immediately of your new IP. So you don't loose any waiting position
- remark: it only works if you connect to a server after IP-change!


http://www.emule-mods.de/?mods=xtreme&show=details

Logged
You can mock me. I can take it.

gav616

  • Guest
Re: aMule-mod Xtreme
« Reply #3 on: April 15, 2007, 07:50:26 PM »

xtreme mod splits the emule dev community, who believe its a bad mod with bad features
i agree with this...bad mod.

IMO, features aMule needs:

ClientAnalyzer CS-
New-Age Leecher Protection - punish only real bad users and not randomly whoever you might not like! (unlike xtreme mod which bands hundreds of mods without knowing if there good to the network or not... bad system!!)

Better upload tuning-
you can enter a desired datarate per slot or use slotfocus to concentrate your upload on as few clients as possible (better support for releasers and better optimization for diffrent upload speeds)

IP2Country-
In nearly every window a flag will show where the ip originates. (not a must, but very informative)

IntelliFlush-
An enhancement of the filebuffer system. Once activated you can raise the filebuffer up to 30MB per file and adjust the time after which a flush will be forced. IntelliFlush will flush automatically whenever you complete a chunk so you can share it ASAP. (makes the buffer fairer/faster and takes load of your I/O)

Auto Hard Limit-
Automatically sets a file's hard limit to the highest needed value. This denies a file which has only 10 sources from getting a HL of 250; the other 240 sources can now be swapped to other files.

SafeKAD+KADHelper-
Additional security checks for Kademlia including anti-fragmentation of KAD packets improve the security and functionality of the Kademlia network.

Save/load sources-
Automatically save found sources which are immediately available after a restart.

Infinite queue-
Infinite upload queue (when a clients upload queue is full, there is a massive amount of overhead to tell them your full then to disconnect them,  also, they will keep reasking you untill there is a free slot, this causes pointless overheads.
Quote
A larger queue does not result in a larger overhead for managing this queue. Neither the number of connections nor the connection overhead will be increased by a larger queue.

PowerShare-
Quote
You can set files to be powershared by right clicking them in the shared files list and selecting "Powershare" -> "Set powersharing". Files that have powershare activated will be uploaded a 100% of the time, if there are people trying to download them. It doesn't matter how many other files you share or download. This makes it possible for you to release files efficiently, and still download files normally. If the files with release priority doesn't use all the bandwidth, normal shared files are uploaded. This means that you won't have to unshare everything that you are not releasing. This gives more sources for files on the network, and make sure the allotted upload bandwidth are always used a 100% efficiently to release your files.

Download/Upload/Connections Wizard-
better settings, better upload, lower overhead, better overallnetwork.

Remove auto dropping of source-
in fact remove manual dropping!!! this creates extra reask overhead of sources you have already dropped which adds more overhead to the network, bad bad feature.. go away!!
« Last Edit: April 15, 2007, 08:14:07 PM by gav616 »
Logged

wuischke

  • Developer
  • Hero Member
  • *****
  • Karma: 183
  • Offline Offline
  • Posts: 4292
Re: aMule-mod Xtreme
« Reply #4 on: April 15, 2007, 08:37:42 PM »

As long as you reask within ~ an hour, you will not loose your position in the queue. aMule will reask within about 30 minutes.

30min < 60min -> you keep your position in the queue -> feature is not needed and causes unnecessary overhead.

---

Wizard's Tombstone was very interesting, but no matter how good an anti-leecher system is in the end: You'll accomplish very little and in most cases you create an unfair client. (As Xtreme might be.)
Won't be included. (Anti-Leecher systems have been requested before, hence I know this answer for sure.)

---

desired upload rate per slot is default in aMule

---

I think IP2Country might be included - as long as someone codes it and so far no one did it.

---

I don't know about the current buffer system nor about Kad.

---

In aMule release priority is similar to PowerShare.

---

There's nothing you can do against user stupi... inexperience. An assistant won't help someone who doesn't know what internet connection he uses.

---

I strongly agree to removing source dropping. I'll request this in the bug tracker.
Logged

FreeToGo

  • Jr. Member
  • **
  • Karma: 3
  • Offline Offline
  • Posts: 65
Re: aMule-mod Xtreme
« Reply #5 on: April 15, 2007, 11:59:34 PM »

« Last Edit: April 16, 2007, 03:18:02 PM by wuischke »
Logged
You can mock me. I can take it.

gav616

  • Guest
Re: aMule-mod Xtreme
« Reply #6 on: April 16, 2007, 12:11:26 AM »

on the upload tuning i was maining on about using 'slot focus', instead of using set KB's slots (which doesn't really work for high speed uploaders i.e. over 300kb)
but yeah... having a tickable 'Use slot focus' which disables the 'per slot control' thats in amule now, would be super..

from ZZUL's eMule mod...
Quote
ZZ SlotFocus: Focus the upload bandwidth to as few upload slots as possible!
(only one, if the top slot wants it all). Transfers files to fewer people at a time, but faster to each. Faster transfers makes chunks complete sooner, making it possible for other clients to share the chunks sooner. This gives more sources in shorter time, sharing the upload demands on several computers sooner. At 76 Kbytes/s ZZUL opens ca 6-10 slots, when official eMule opens 24 slots. ZZUL only opens new slots if necessary to use the configured bandwidth. Upload slot focusing version 2 is available in this patch. Version 1 is used in eMule Plus (and others?). You can see which upload that has the highest priority by checking the number in the "Slot #" column. Slot #1 get all bandwidth it can handle. Slot #2 gets any leftovers after slot #1 has taken what it wants, etc.

When you download a file, it is good for you to give all chunks you already have of that file to other clients as soon as possible. As soon as you have spread your chunks, the other clients will actually help you to download the chunks you are missing. Then you can get those chunks from them (and fast, since you now have good credits with them). It will also be easier for you to get the chunks from the original source, now that is no longer busy uploading chunks that you already have, to other clients. So set your upload speed as high as possible!


I agree, there should not be too many 'choices' because too many options equal too many varibles to those options, which harms the overall network, which is happerning currently in the official emule mod releases. i.e. options like 'hideOS' some mods like Stulle bring out 'anti-hideOS'.. soo its a never ending battle.
Mods can be great but the fact of the matter is, if everyone used default client no one could complain about bad features because every1 would be the same.


ohh thank you 'FreeToGo' for spamming the board.
« Last Edit: April 16, 2007, 12:21:26 AM by gav616 »
Logged

FreeToGo

  • Jr. Member
  • **
  • Karma: 3
  • Offline Offline
  • Posts: 65
Re: aMule-mod Xtreme
« Reply #7 on: April 16, 2007, 07:51:06 AM »

Sorry for spamming the board in case anyone think that I am
Anyhow, I found a good sources of information that might be of interests for those seriously want to pursue their features' quest.

 
http://en.wikipedia.org/wiki/Comparison_of_eDonkey_software
Logged
You can mock me. I can take it.

lfroen

  • Guest
Re: aMule-mod Xtreme
« Reply #8 on: April 16, 2007, 10:09:14 AM »

I would like to add my 5cent to "upload bandwidth" discussion.

Quote
All applications that need to regulate their upload bandwidth face the same problems.
True, and solution is known. Actually, there's several solutions.
* OS lets application know when data is passed to protocol layer. Either thru blocking send() or thru select() interface. So, theoretically speaking, application have an idea about rate of data going from transport layer into protocol (from TCP to IP). Which means that there's no need to "measure" rate in any bizarre way proposed here (pings, Ethernet stats etc). They all wrong, no exceptions.
* In Linux OS user can turn on packet queueing and classification (see man tc). In this case, OS itself may limit traffic of particular type. And yet again, rate which application "see" will be affected and therefore noticed.

Conclusion: aMule need to measure how fast outgoing socket becomes writable (in Linux terms) in order to know it's actual upload capacity. IIRC this is already implemented.

Logged

FreeToGo

  • Jr. Member
  • **
  • Karma: 3
  • Offline Offline
  • Posts: 65
Re: aMule-mod Xtreme
« Reply #9 on: April 16, 2007, 12:07:59 PM »

Quote
Conclusion: aMule need to measure how fast outgoing socket becomes writable (in Linux terms) in order to know it's actual upload capacity. IIRC this is already implemented.

Once aMule could measure how fast outgoing socket becomes, aMule should only opens new slots if necessary to use the configured bandwidth.

 

Logged
You can mock me. I can take it.

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: aMule-mod Xtreme
« Reply #10 on: April 16, 2007, 01:04:07 PM »

... which is what it does.
Logged

Lame_azz

  • Approved Newbie
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 15
Re: aMule-mod Xtreme
« Reply #11 on: April 17, 2007, 04:23:54 AM »

aMule does bandwith management quite poorly up to date.
1) Channel can be variable-bandwith.Is this case handled properly?
2) Some channels, even with static bandwith, have high ping latency when saturated.This suxx since www browsing drops to speeds of dialup when this happens.Now imagine the following: aMule set up to use 80% of channel capacity.To keep ping good.Now, we're sending file through IM client, uploading to FTP, etc "out of band" for aMule.Let's assume this eats 50% of bandwith.Now what?My channel will not become 130% faster of course, but rather will become overloaded and 100% used.Ping will get quite high, making even WWW browsing as slow as dialup, loss of sources, worse Kad maintenance, etc.Preferred scenario is that aMule is to detect high ping and temporarily drop upload (and maybe download) speeds to keep ping low, then resume on full allowed speed when channel no longer used.But now this is not a case.This works quite well with eMule mods implementing pinging.As for aMule, I can only lower aMule's TCP packets priority on router but it is pain in the ass to configure (average Joe will 100% fail to do so) and it's still quite poor solution (what an ugly hack!) anyway.

P.S. I have to admit that internet channels are differ greatly on their behavior depending on technology, settings, etc... so this is not too smart to assume that if something works OK for you will work greatly for everyone else.Same applies to Kad.Instead of dumb mumblings that Kad code is "the sacred cow" why not to discuss things with eMule dev's? Sorry, just an opinition, please do not treat this as offence.
Logged

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: aMule-mod Xtreme
« Reply #12 on: April 17, 2007, 09:12:06 AM »

I do discuss things with the eMule devs. Kad is still sacred.

As for the scenario you propose up, why is your FTP client not doing the bandwith control?
Logged

FreeToGo

  • Jr. Member
  • **
  • Karma: 3
  • Offline Offline
  • Posts: 65
Re: aMule-mod Xtreme
« Reply #13 on: April 17, 2007, 09:51:25 AM »

As for the scenario you propose up, why is your FTP client not doing the bandwith control?

I guess aMule though coined as a client is running more like a "service". It is better to let aMule play nice so as to encourage people to leave it "on" all the time.

Talking of playing nice, linux got a command called nice to schedule process priority. I wonder if there is anything similar but to schedule bandwidth priority.

Logged
You can mock me. I can take it.

Kry

  • Ex-developer
  • Retired admin
  • Hero Member
  • *****
  • Karma: -665
  • Offline Offline
  • Posts: 5795
Re: aMule-mod Xtreme
« Reply #14 on: April 17, 2007, 10:32:56 AM »

lfroen told you to check tc.

Also, there is no way for aMule to actually control congestion, more than it already does.
Logged
Pages: [1] 2 3 4