AMule Project FAQ - User contributions [en]

Backtraces

2005-07-01T12:13:09Z

87.74.0.220:

== Introduction ==

Well, not hard to guess, this is about backtraces.

Usually, it should not be necessary for the normal user to do this. However, we might have a bad day and release a somewhat buggy version or you are running [http://www.gnu.org/software/cvs CVS] which can also be unstable sometimes.
This is where the backtraces come in: if [[aMule]] crashes, and you get an "OOPS - aMule crashed" and so on, we'd like to know. The backtrace [[aMule]] provides is not always very usefull as it contains little information, but, as usual, there's a better way: A *real* backtrace.

== The GNU Debugger ==

First of all, you need the [http://www.gnu.org/software/gdb/gdb.html GNU Debugger] installed. It's called ''gdb'' and you could check for that by typing ''which gdb'' in a console window. You should see something like this:

''<pre>
$ which gdb
/usr/bin/gdb
</pre>''

If you don't have [http://www.gnu.org/software/gdb/gdb.html GDB] installed, you will get a message like this: 

''<pre>
$ which gdb
which: no gdb in (/bin:/usr/bin:[etc])
</pre>''

If that is the case, the [http://www.gnu.org/software/gdb/gdb.html GNU Debugger] is most likely not installed on your system and you should install it before you proceed.

If your OS is [http://www.gentoo.org Gentoo Linux] you have just to type this:
''<pre>
# emerge -av gdb
</pre>''

== Compiling [[aMule]] ==

Then, compile [[aMule]] with debugging information:

''<pre>
$ ./configure --enable-debug --disable-optimise --prefix=/where/to/install/aMule
$ make
$ make install
</pre>''

If you do not want to overwrite you old copy of [[aMule]], simply do this instead:

''<pre>
$ ./configure --enable-debug --disable-optimise
$ make
</pre>''

[[aMule]] can then be run by going into the dir ''src'' and typing ''./amule''

If you are unable or unwilling to recompile, or are running a RPM version, proceed anyway, but be aware that backtraces from debugging enabled builds are much more useful to us.

== Create a backtrace ==

Now create in your home directory the file ''.gdbinit'' and put these lines into it (or you can type them in at the ''(gdb)'' prompt later):
''<pre>
ha SIGPIPE nostop noprint pass
ha SIG32 nostop noprint pass
</pre>''

For those who want to know the meaning of the previous lines:
the first one avoid [http://www.gnu.org/software/gdb/gdb.html GDB] stopping at broken pipes;
the second one avoid [http://www.gnu.org/software/gdb/gdb.html GDB] stopping at new thread.

To create a backtrace, open a console and do the following:

''<pre>
$ gdb /where/to/install/aMule/bin/amule
(gdb) run
</pre>''

Now use [[aMule]] normally until it crashes. If it crashes do the following:

''<pre>
(gdb) bt
(gdb) bt full
</pre>''

Post the output of the last two commands in the [http://www.amule.org/amule/board.php?boardid=33 backtraces forum] with some additional comment about the circumstances the segfault happened and what [[aMule]] version you used (or checkout time for [http://www.gnu.org/software/cvs CVS]).

== The core file ==

If your [[aMule]] executable has been compiled with debug information (''--enable-debug'' configure flag), but you were not running it from within [http://www.gnu.org/software/gdb/gdb.html GDB], there is still a way to generate a backtrace, if your system was configured to generate '''core files'''.

Core files are the full memory image of a process that crashed. Your session must be properly configured, so that the system generates core files. Add the following command to ''~/.bashrc'':

''ulimit -c unlimited''

Now, when a program crashes, suppose it generate the file ''core.1234'' (this name can be different, but usually will start with 'core') you can enter [http://www.gnu.org/software/gdb/gdb.html GDB] like that:

''$ gdb /path/to/amule /path/to/core/file/core.1234''

and then proceed as in the last session and issue 'bt' and 'bt full'.

So, that's it, have fun with [[aMule]]

Greetings, [[User:Citroklar|Citroklar]] & [[User:Phoenix|Phoenix]]

(Most of the above shamelessly stolen from pure_ascii's post in backtraces forum, thanks, pure!)

Please read [[Using_gdb_and_valgrind|this]] to learn more about [http://www.gnu.org/software/gdb/gdb.html GDB] and [http://valgrind.kde.org Valgrind].

Shortcut

2005-06-17T13:54:53Z

87.74.0.220:

Apparently Hot keys can be currently (as of 2.0.2) defined in the GTK1 version, but not the GTK2 version.

They cannot currently be saved.

Shortcut

2005-06-17T13:54:38Z

87.74.0.220:

Apparently Hot keys can be currently (as of 2.0.2) defined in the GTK1 version, but not the GTK2 version.

HowTo Compile In Debian/Ubuntu

2005-05-19T07:25:28Z

87.74.0.220: /* Preparing the system */ You were clobbering their input file! (and changing "unstable" to "untesting") :-| - sed can't write to its input file.

<center><h2>HowTo compile aMule in [[Debian]]</h2> 
<h2>by [[User:Jacobo221|Jacobo221]]</h2> 

<h3>Very special thanks to darknox, Arathornz, guest234, parasito, maya and klando for their tests!</h3></center> 
 

'''NOTE:''' This howto will also work for [http://www.ubuntulinux.com Ubuntu Linux].

== Are you sure you want to compile? ==

You can just install latest [[aMule CVS]] through debs adding the following lines into your ''/etc/apt/sources.list'' file:

deb http://www.vollstreckernet.de/debian/ testing amule
deb http://www.vollstreckernet.de/debian/ testing wx

'''NOTE:''' The second line is necessary for Sarge users and strongly recommended for Sid users.

Now run ''apt-get update && apt-get install amule''

You might also want to take a look at the other available [[aMule]] utilities:
*amule
*amule-common
*amuled
*amule-remote-gui
*amuleweb
*amulewebdlg
*amule-cas
*amule-wxcas
*amule-xas
*amule-utils

If you still want to compile aMule instead of just installing a binary, keep reading...

== <h4>Notes before starting</h4> ==
Important: Have in mind that this HowTo was done having in mind aMule 2.0.0 or greater in [[Debian]] 3.0 (Woody/Sarge/Sid). 
 
This HowTo is based on using the apt-get package installer tool, which means you'll have to be able to get super-user (root) access. Also, apt-get requires a perfect packet dependencies installed system. If you usually use apt-get for installing any application, skip this and go to the next section. If you rarely use apt-get but, instead, use dpkg, you can 
 
A) (Recommended) Solve all the dependencies problems on your system. This can be done by taking a look at the <code>"dpkg -C"</code> output and installing/removing/updating the packages it mentions depending on what's required. This option is the recommended since it will not only ensure your aMule compilation will be most surely correct, but it will also make your system the most stable it can possibly be and from now on you'll be able to use apt-get to not only make easier installations, but also to easily upgrade your system. 
 
B) Force apt-get to ignore the dependencies problems using the -f or --fix-broken switches (just one of them, since they're exactly the same, so that'd be, for example, <code>"apt-get install -f ..."</code>). This option may cause a corrupt installation of some packages which may cause the apps not to work. Also have in mind that using this switch in a system with dependencies problems may cause the system to completely break if the package being installed is a base package (although this is not the case). 
 
C) Follow this instructions but, instead of using <code>"apt-get install foo"</code>, use <code>"dpkg -i foo"</code> where foo is the package to install. Remember the packages must be already on the system when installing packages with dpkg. Remember also to download any "Depends" package since it most-surely will be necessary for successfully compiling [[aMule]]. Avoid using whichever of the following dpkg switches: --force-all --force-depends-version --force-depends --force-conflicts 
 
If you usually install applications from source, read deltaHF's [[Compilation_Installation|"aMule compilation / installation HowTo"]] since your system might not be complying the Debian aMule package dependencies although <code>"dpkg -C"</code> shows no errors. 
 
 
== <h4>The easiest: Preparing the system</h4> ==
Once you decided to use apt-get, you must make sure you'll be downloading the latest versions of the packages (aMule team has discovered bugs in some deb packages that would make aMule impossible to compile on Debian without compiling some other libraries too. This bugs have been mostly fixed in those affected debian packages, so it is very important to be sure to have the packages up to date). This is done by 
 
<code>apt-get update && apt-get dist-upgrade</code> 
 
Note 1: You must be root user to do this. Log in as root or <code>"su"</code> or use <code>"sudo"</code> (<code>"sudo"</code> must be specified on both apt-get commands, that is <code>"sudo apt-get update && sudo apt-get dist-upgrade"</code>). <code>"sudo"</code> is not a base command, so it may not be installed on your system, although it most probably will. Be aware that following this HowTo entirely as root may bring some problems later such as being unable to delete certain files as a normal user, so please only use tooy priviledges when necessary. 
Note 2: Woody users (that is, people stuck in the stable Debian 3.0 branch) will be unable to install the wxGTK, wxbase and Crypto++ libraries since they were not available in the current minimum compatible versions (2.4.2 and 2.5.1 respectively) when Woody was released. 
The best for Woody users is to switch to the Sarge or Sid branch.
That can be done with the following command (again, you must be root)
<code>perl -pi.$$ -e "s/(\bstable|woody)/testing/g" /etc/apt/sources.list</code>
or
<code>perl -pi.$$ -e "s/(\bstable|woody)/sarge/g" /etc/apt/sources.list</code>
to switch to the Sarge/testing branch, or with
<code>perl -pi.$$ -e "s/(\bstable|woody)/unstable/g" /etc/apt/sources.list</code>
or
<code>perl -pi.$$ -e "s/(\bstable|woody)/sid/g" /etc/apt/sources.list</code>
to switch to the Sid/unstable branch. 
If Woody users are not be interested in switching to Sarge they will have to download Woody-backported debian packages by adding the following line to /etc/apt/sources.list (remember to <code>"apt-get update"</code> after adding this line): 
<code>deb http://debian.thermoman.de/ woody wxwindows2.4 libcrypto++</code> 
What's more, [http://www.thermoman.de thermoman] stopped working on the [[aMule]] backports for [http://www.debian.org Woody] on the [[aMule]] 2.0.0-rc5 release, so newer [[aMule]] releases backports are unavailable. Sorry. 
Note 3: Sarge users won't have any dependecy problems any longer, sicne both crypto++ and wxWidgets are both in Sarge since some time ago. So, there's no longer any need to update ''sources.list'' on Debian Sarge distributions. 
Note 4: Sid users (that is, people holding the cutting-edge unstable Debian 3.0 branch) could suffer problems from packages not completely implemented or with broken dependencies (both are normal issues in the unstable branch). It is very important to keep this in mind since a compiler (g++) will be installed so it could also be broken and, with it, most applications compiled with it (once upgraded, of course). If a package was broken, to downgrade you can use the --force-downgrade switch with dpkg. 
 
If for whatever reason you think this is too much of a complication, you can just wait a few days until the aMule binary version comes out for your architecture (that is, a .deb file). 
 
 

== <h4>The fastest: Installing the necessary packages</h4> ==
Remember you need to be root to install applications using apt-get, since apt-get installs system-wide applications. So, log in as root, use "su" or add "sudo" before every command shown here. 
 
The following are the packages which must be installed: 
 
1) Install the latest stable g++ compiler and the C++ Standard Library 
 
<code>apt-get install g++</code> 
 
the required libraries for compiling [[aMule]] (wxbase is not really a requiered packet to compile aMule but, unless you know what you're doing, be sure you install it. I won't show in this this guide how to force aMule's compilation without wxbase): 
 
<code>apt-get install libwxbase2.4-dev libcurl3-dev libgtk1.2-dev libwxgtk2.4-dev</code> 
Alternatively you can use <code>apt-get build-dep amule</code> to get all the required depencies for compilation. Anyway, this last method is not sure to work, since it will depend on the latest version on the Debian repository and later versions or CVS versions might have different dependencies.
 
and the required utilities for compiling [[aMule]], at the moment only gettext (necessary for internationalization support): 
 
<code>apt-get install gettext</code> 
 
Note 5: This can all be done in a single command line, which might be more handy for users using <code>"sudo"</code> to gain root priviledges: <code>apt-get install g++ libwxbase2.4-dev libcurl3-dev libgtk1.2-dev gettext</code> 
Note 6: From aMule 2.0.0-rc1 to aMule 2.0.0-rc5 (inclusive) the package ''libcrypto++-dev'' is was necessary for compiling aMule, so if you are compiling any of such versions, apt-get libcrypto++-dev too. 
Also, you might be interested in installing libgd2-noxpm-dev if you plan to compile CAS. It is not a required library for compiling CAS, this library is only used by CAS for creating images (since v2.0.0-rc3) on the current aMule status (by running <code>cas -o</code>). If you plan to use this feature of CAS, you need to install LibGD2. Anyway, CAS will compile perfectly well even if LibGD2 isn't installed, since it detects, on compilation time, if this library is installed. 
Note 7: Woody users will most probably be unable to get libgd2-xpm-dev and libcurl3-dev since those packages aren't available for Woody. For libcurl3-dev you can just install libcurl2-dev and go on, everything will be ok For libgd2-xpm, at the moment there is no backport available but, since this library is only used by CAS (and suggested, not even required), it won't give any problems on compilation time. Just be aware that <code>cas -o</code> won't work. 
 
2) Download the latest released [[aMule]] source code from [http://www.amule.org/files/files.php?cat=6 here] (or look [[AMule_CVS|here]] for an up-to-date link). 
 
Note 8: From now on, I will suppose we are installing aMule 2.0.0-rc3 
 
3) Fix Crypto++ Library 5.1 if using it 
From [[aMule]] 2.0.0-rc1 to a aMule 1.0.0-rc5 (inclusive) this library is required because [[aMule]] is now supporting SecureIdent (remember, since aMule 2.0.0-rc6, libcrypto++ is optional and not needed by default), but the [[Libcrypto|Crypto++]] [[Debian]] package has had lots of compiling bugs and still has one (although the rest have been fixed after aMule team's reports). Remember you should have update and dist-upgraded apt-get before installing any [[Debian]] package in this HowTo, otherwise, you could be installing (or already have installed) a buggy Crypto++ package and this fix will not suit your needs. To fix the latest [[Libcrypto|crypto++]] [[Debian]] package only a symbolic link is needed: 
 
<code>ln -s /usr/include/crypto++/cryptopp_config.h /usr/include/crypto++/config.h</code> 
 
If you still can't compile crypto++, try compiling it after running the following command: 
 
<code>ln -s /usr/include/crypto++ /usr/include/cryptopp''</code> 
 
Note 9: Since this link needs write permissions in /usr/lib, super-user (root) priviledges are needed. Again, this can be done easily with <code>"su"</code> or <code>"sudo"</code>. 
 
 

== <h4>The hardest: Compiling [[aMule]]</h4> ==
4) Extract the sources. The following will create a folder on your user's home directory where it will extract the sources with the -C switch into it (the following command understands that [[aMule]]'s sources are on the current directory): 
 
<code>mkdir ~/aMule-compilation/ && tar xzfv aMule-2.0.0rc3.tar.gz -C ~/aMule-compilation/ && cd ~/aMule-compilation/</code> 
 
Note 10: Remember I'm supposing you are extracting [[aMule]] 2.0.0-rc3. Change the file name if it doesn't correspond to the actual packed source code filename. 
 
5) Compile [[aMule]]! The following command will actually switch to the directory containing [[aMule]] 2.0.0rc3 and compile it: 
 
<code>cd ~/aMule-compilation/aMule-2.0.0rc3/ && ./configure && make</code> 
 
Note 11: Please take a look at the [[configure|configure article]]. 
Note 12: You should check <code>"./configure --help | more"</code> to see if there is any configure switch which might be of your interest, such as --disable-debug --enable-optimise or --bindir= 
Note 13: if you get an error message, while compiling, similar to: "In file included from /usr/include/wx/***:***, [...] /usr/include/wx/******:***: internal compiler error: Segmentation fault", then you most probably have problems with wxWidgets. Try with <code>"apt-get install --reinstall wxwin2.4-headers libwxbase2.4 libwxgtk2.4-dev"</code>, which will reinstall wxWidgets and will most probably fix the compilation error.
 
 
== <h4>Meeting satisfaction: Installing aMule!</h4> ==
8) What's left? Install aMule (remember you must be root, so log in as root or use <code>"su"</code> or <code>"sudo"</code>): 
 
<code>make install</code> 
 
Now you can remove the sources so you free up space in your hard disk by running: 
 
<code>rm -rf ~/aMule-compilation/</code> 
 
 
== <h4>The end: Final checks</h4> ==
If you have sometime installed aMule from the Debian packages (no matter if the package came from http://gunnm.org/~soda ), you will have aMule binaries installed in /usr/bin. But <code>"make install"</code> installs binnaries in /usr/local/bin (unless --prefix= is set in configure). This leads us to the point that when typing "amule" anyone of the two installed aMule versions might be invoked (which one is executed will depend on the $PATH environment variable. You can check it by typing <code>"type amule"</code>). The walk around is very easy: remove the aMule installed through [[Debian]] package. You can do this with the command "apt-get remove amule" (do not use <code>"apt-get remove --purge"</code> or you might loose your [[aMule]] settings) or with <code>"dpkg --remove amule"</code> (again, never ever use <code>"dpkg --purge"</code> or you might loose your [[aMule]] settings). apt-get will remove aMule-utils if you have them installed (only available as a separate package in Sid, in Sarge and Woody aMule utils are included in the base aMule package) while dpkg will leave aMule-utils installed on the system (which, in general, is a bad idea). 
Also, if you installed xmule sometime or you are planing to install it, have in mind that the [[ed2k command]] exists both in [[aMule]] and [[xMule]]. You might want to run `type ed2k` to see which [[ed2k command]] will be executed and rename the other so you make sure it's never executed by mistake. 
 
 
== <h4>You're done...</h4> ==
That's it! Your own compiled [[aMule]] is installed on your system and ready to go. 
To run [[aMule]], just type <code>"amule"</code>. You can check if everything worked by typing <code>"amule -v"</code> and check if the displayed version corresponds with the one you were compiling/installing. 
If this HowTo didn't help, you have a rare problem on your system ;-) Take a look at http://www.amule.org ([http://www.amule.org/amule aMule Forums] at http://forum.amule.org ) or visit us in #amule on irc.freenode.net and (don't doubt) we'll try to do our best to help you. 

== Final notes ==

If you are in one of those rare cases when you wish to compile [[aMule]] statically, install also ''libtiff4-dev'' (through ''apt-get install libtiff4-dev''). Anyway, this is '''NOT''' recommended and, in fact, will probably not do any better or even, not work at all.

FAQ network

2005-05-17T00:13:57Z

87.74.0.220:

= Network speed: what you should know before asking questions =
by Froenchenko Leonid, lfroen@gmail.com

== Preface ==
The purpose of this document is to clarify different issues regarding network
speed that pop up from time to time in the [[aMule]] [[forum]]. Generally speaking, there are several reasons for questions about "[[FAQ_ed2k|aMule network]]":

* The speed reported by [[aMule]] doesn't match your provider's given rate
* Poor performance of [[aMule]] itself or another network application on the same computer
* The key factors influencing network performance while [[aMule]] is running

The intended audience for this document is users who want to get a better understanding of network functionality in general and in particular its implications for [[aMule]] functionality.

This page, however, is not to be seen as comprehensive general purpose "[[FAQ_ed2k|Network FAQ]]". If you were expecting something else, you might be interested in the [[aMule is slow|aMule is slow FAQ]].

== Network speed - how much is it? ==
When talking about network speed, people use the unit "bps" which means
"bits per second". The reason that a ''bit'' is used rather than a ''byte'' is pretty much historical, but also has an engineering motivation behind it.

This motivation comes from the fact that not all networks in the world transfer their traffic in bytes.

There is a convention to use a capital "B" in "Bps" when speed is marked
in "bytes per second". However, this convention is not widely accepted. In particular, organizations like the [http://www.ietf.org/ IETF] and [http://www.ieee.org/ IEEE] stick to the original "bps".

== Prefixes ==
Since their invention, networks have made a lot of progress. Today we have networks that transfer thousands of millions of bits per second. For measuring these speeds the prefixes ''"kilo"'', ''"mega"'', ''"giga"'', ''"tera"'' etc. are used.

It is a common mistake to think that values with those prefixes are the same as in computer science, i.e. powers of 2. The truth is that, for historical reasons, prefixes in networking have a decimal base, and not a binary one.

{| cellpadding="2" cellspacing="2" border="1" width="100%" title="Table 1"
| valign="middle" title="Table 1" align="center" bgcolor="#33ff33" | Prefix
| valign="middle" align="center" bgcolor="#33ff33" | meaning in computers
| valign="middle" title="Table 1" align="center" bgcolor="#33ff33" | meaning in networks
| valign="middle" align="center" bgcolor="#33ff33" | difference, %%
|-
| valign="top" | K (kilo)
| valign="top" | 2^10 = 1024
| valign="top" | 10^3 = 1000
| valign="top" | 2%
|-
| valign="top" | M (mega)
| valign="top" | 2^20 = 1,048,576
| valign="top" | 10^6 = 1,000,000
| valign="top" | 5%
|-
| valign="top" | G (giga)
| valign="top" | 2^30 = 1,073,741,624
| valign="top" | 10^9 = 1,000,000,000
| valign="top" | 7%
|-
| valign="top" | T (tera)
| valign="top" | 2^40 = 1,099,511,627,776
| valign="top" | 10^12 = 1,000,000,000,000
| valign="top" | 9%
|}

As you can see from the table above the error in calculation is about 5% when the prefix is incorrectly interpreted. Please note that the speed your provider quotes you is the "speed in network units", i.e. calculated on a decimal basis.

For example when your provider tells you that your link is "ADSL 256/128" you
should understand that they mean 256000/128000 bps (bits). Which means, that the speed of your connection is 32000/16000 bps (bytes).

== Protocol overhead - what is it about? ==
When [[aMule]] is running, it constantly "talks" with other [[client]]s and [[server]]s.
This data exchange is needed to identify itself, request information about
available [[FAQ_eD2k-Kademlia#What_is_a_source?|source]]s and [[file]]s, to perform [[search]]es and so on.

Since this information has no direct use to the user itself, it is called "overhead" i.e. an inevitable addition to the data you actually want to [[upload]] or [[download]].

[[aMule]] calls this "''connection overhead''". However the number that [[aMule]] presents includes only the size of the actual data that [[aMule]] itself sends to the network stack. Later, this data is sent out on the network with even more overhead - that of the network protocols.
How much is it? - let's see that in the next section.

== Network overhead ==
First of all - we're talking about the [[IPv4]] network. Once upon a time, there
was only one type of [[IP]] network. Now there are two - [[IPv4|IP version 4]], the old we all know; and [[IPv6|IP version 6]] - the new protocol made to fix the limitations of [[IPv4]].

[[FAQ ed2k|ED2K protocol]] by design, is unable to talk over [[IPv6]] network, so users who have it (in Japan and China for example) will not be able to connect "as is". Using [[IPv4]] means, that each packet ([http://www.ietf.org/rfc/rfc793.txt TCP], [http://www.ietf.org/rfc/rfc768.txt UDP], [http://www.ietf.org/rfc/rfc792.txt ICMP]) will have an [[IPv4]] header.

The minimum size of this header is 20 bytes. The header can have optional parts (each of 4 bytes) and that is up to your provider - for example, mine adds an optional [dword].

When talking to other clients and servers on [[FAQ ed2k|ed2k network]], [[aMule]] uses the widely known [http://www.ietf.org/rfc/rfc793.txt TCP] protocol. [http://www.ietf.org/rfc/rfc768.txt UDP] is also used, but on a much smaller scale. As the reader might know, [http://www.ietf.org/rfc/rfc793.txt TCP] is a reliable protocol, i.e. it guarantees that data which is sent from one side will arrive on the other or an error will be reported.

In order to achieve this, [http://www.ietf.org/rfc/rfc793.txt TCP] sends its own data in addition to the actual "payload" data being transfered. This data includes [http://www.ietf.org/rfc/rfc793.txt TCP] client initial negotiation, checksums, sequence numbers and acknowledgments. All of this is in the ''[http://www.ietf.org/rfc/rfc793.txt TCP] header'' which is added to each packet sent. The size of this header is a minimum of 20 bytes.

While being only a small overhead for a large bulk transfer, it can take significant part of bandwidth when small amounts of data are being exchanged. This is exactly what happens on [[FAQ_ed2k#What_is_a_source?|source]] discovery part of [[aMule]].

Our [[client]] is trying to establish a connection and negotiate with a large number of other [[client]]s. Doing this, [[aMule]] opens new [http://www.ietf.org/rfc/rfc793.txt TCP] connections ''all the time''. The amount of connections opened is controlled by the ''"Maximum number of connections in 5 seconds"'' setting in the preferences.

A typical number is about 100. Each [http://www.ietf.org/rfc/rfc793.txt TCP] connection results in at least 3 packets traveling the net - one is a SYN packet, i.e. connection request, and one an ACK or a RST when the connection is accepted or refused, and SYN+ACK to establish the session.

There's more overhead of [http://www.ietf.org/rfc/rfc1034.txt DNS] queries when an address is resolved, retries when a host doesn't reply and so on.

=== At low level ===
After passing [http://www.ietf.org/rfc/rfc793.txt TCP] and [[IP]] layers packets go down to the network interface driver. What kind of driver this is depends on the way your computer is connected to the internet. For simplicity sake we will assume that this computer is connected to the ISP directly, i.e. you have no LAN (or switch or router) between.

Common setups that I'm aware of:

* Analog modem, connected to telephone line (ISDN modem falls in this category too).
* Cable modem, connected through ethernet, ISP gives you an [[IP]] address through [http://www.ietf.org/rfc/rfc2131.txt DHCP].
* Cable modem, connected through ethernet, ISP requires you to configure PPPoE or PPTP tunnel.
* ADSL modem, connected through ethernet. You must have a PPPoE or PPTP tunnel
* Variation of above - modem connected to PC by USB.

In each of the above setups there are different protocols in use, and different headers are added to transmitted packets. But there's one important thing to note: ''ethernet frames traveling between cable/ADSL modem and PC, and don't reach the ISP''.

And consequently they are not counted in rate calculations. [http://www.ietf.org/rfc/rfc2516.txt PPPoE] and
[http://www.ietf.org/rfc/rfc2637.txt PPTP] headers, on the contrary ''do reach the ISP''. I obviously have no idea whether or not your particular provider chooses to include them in their rate calculations. For this reason I will exclude those headers from my calculations.

If you think that your ISP includes it, add 4 bytes to the size of each packet.

=== Example ===
Let's see how much network overhead we have on a typical network. Our connection is a cable modem connected via an ethernet link to a PC directly (no router between them).

In this setup we have [[IPv4]] packets sent over ethernet.

Lets say we have 10 new connections opened each second, and all are being accepted (successfully established [http://www.ietf.org/rfc/rfc793.txt TCP] session). This alone sums up to (I'm counting data going up - from my computer to the net):

''10 connection * 2 packets * (20 bytes of TCP + 20 bytes of [[IPv4]]) = 800 bytes of overhead.''

This means that we are starting with 1.16*8 Kbps of "''invisible"''
overhead caused by the very way the network works. Now, let's assume that
after each connection is established our amule sends something to the other side and waits to receive an answer.

''Total of 800 bytes + 800 bytes = 1600 bytes per second = 6400 bps = 6.4 Kbps''

What we have here is 6.4 Kbps of network overhead alone. Taking into account
that amule has other data to send (uploads) and it is not the only network
application running we will have the following picture:

Most likely the link to your provider is not that fast. [[aMule]] will ''try'' to open 10 connections per second and will ''try'' to upload on the specified speed.

Your operating system will share all available bandwidth between those and between [[aMule]] and other network applications (browser for example). Actual results will vary depending on specific OS settings.

== ACK bottleneck ==
In all calculations above there was one assumption - zero download. But downloading is what amule was built for. So let's examine how the overhead
above affects your downloading speed. The answer is in [http://www.ietf.org/rfc/rfc793.txt TCP] protocol.

When [http://www.ietf.org/rfc/rfc793.txt TCP] is sending data, it requires that the other side acknowledge the reception. So if client A is sending data to [[client]] B by [http://www.ietf.org/rfc/rfc793.txt TCP], B has to send a special ACK packets to A which tells B "ok, I got it". If, however, A doesn't receive the ACK packets in time, he will assume that either packet is lost.

So, without going deeply into [http://www.ietf.org/rfc/rfc793.txt TCP] specification: ''if B fails to send ACK to A, as a result A will transmit slower''.

Now let's see the situation in [[aMule]]. We saw in the previous chapter, that the uplink stream is congested by connection requests and uploads. As a result, there's a good chance that ACK packets for a file we are downloading ''will not be sent on time''.

The remote party will notice this and slow down. This is one more reason why the upstream should better not be too congested.

== Is there anything I can do? ==
OK, now that you understood why your network is so slow while [[aMule]] is
running you will maybe look for a way to fix this. The answer in 2 words: "rate limit".

The first thing you should do is to assign realistic rate limits in [[aMule]]
itself. If you have a uplink rate of 128 Kbps don't set [[aMule]]'s [[upload]] limit to 16 (kilobytes per second) just because 128/8 = 16.

A better, but far more complicated solution is to use the QoS and packet scheduling services of your OS. For example, you can give a higher priority to ACK packets to solve the above mentioned "ACK bottleneck" problem.

The QoS topic, however, is beyond the scope of this article.

== Router (switch, home network): is there any difference? ==
When the cable coming from your ISP is connected to some switching or routing
device, which in turn is connected to several PC's, bandwidth is shared between
them.

So, having N computers connected, an ideal device would simply provide
each one of them with 1/N of the total bandwidth. The situation may vary in real life, and your particular device may have different idea about fairness.

Since you're not going to have the hardware specs of your router chipset the only advice here is "try and see yourself".

== Multiple links ==
Until now, we talked about computers that are connected to the network through
single interface. While being most frequent, this is not mandatory. A user
may choose to connect via 2 (or more links) provided by different ISP's.
There're 2 reasons for this decision that I know about: link redundancy and
load balancing.

=== Link redundancy ===
In a case of link redundancy second link becomes operational when primary
link fails. This can be done automatically, or by explicit user command.
When this setup used, [[aMule]] along with other network applications must be
restarted when links are being switched. This will allow to bind new address,
reconnect to server and receive new ID. If [[aMule]] is connected via  [http://www.ietf.org/rfc/rfc3022.txt NAT]]
enabled router (it doesn't matter if you have [[FAQ_ed2k#What_is_LowID_and_HighID?|low or high ID]]), and links
are switched ''on the router'', restart not needed.

=== Load balancing ===
This is a far more complicated case. Both (all) links are simultaneously active,
and traffic is being distributed between them. The problem is that [[aMule]]
binds to ''all interfaces on the system'' i.e. 0.0.0.0. But, on [[FAQ ed2k|ed2k]]
your ID is your [[IP]] address, ''and you can not have two''. 
So the problem is that [[aMule]] does not explicitly choose the source
address for ''outgoing'' [http://www.ietf.org/rfc/rfc793.txt TCP] connections. Note, that it ''doesn't
matter'' on which interface it listens. This is exactly ''opposite''
to ''server'' applications like FTP or HTTP. When a client
tries to connect to a server it discovers its IP address by resolving DNS. Resolver
replies will contain all [[IP]] addresses of the specified host and a client should try them all. The server, in turn, may choose not to listen on
one of them and thus prevent the client from using this interface. In our case
[[aMule]] ''is a [[client]]'', and the [[server|ed2k server]] discovers its address from the
[[FAQ_ed2k#What_is_a_source?|source]] [[IP]] in the connection request. That's where the [[server|ed2k server]] will try to connect.
If the connection succeeds the client is [[client]] assigned a [[FAQ_ed2k#What_is_LowID_and_HighID?|high ID]], if it doesn't the client gets a Low ID.
The only solution in this situation (until [[aMule]] will have an ability to
bind to specific address) is to use [[aMule]] on your "primary" link. 
You can, however, cause [http://www.kernel.org Linux] to send packet through interface of your choice.
But, most probably they will be dropped by your ISP's router as "spoofed" because the source [[IP]] address doesn't match the address the ISP assigned to that interface.

FAQ network

2005-05-17T00:12:54Z

87.74.0.220:

= Network speed: what you should know before asking questions =
by Froenchenko Leonid, lfroen@gmail.com

== Preface ==
The purpose of this document is to clarify different issues regarding network
speed that pops up from time to time in [[aMule]] [[forum]]. Generally speaking, there are several reasons for questions about "[[FAQ_ed2k|aMule network]]":

* The speed reported by [[aMule]] doesn't match your provider's given rate
* Poor performance of [[aMule]] itself or another network application on the same computer
* The key factors influencing network performance while [[aMule]] is running

The intended audience for this document is users who want to get a better understanding of network functionality in general and in particular its implications for [[aMule]] functionality.

This page, however, is not to be seen as comprehensive general purpose "[[FAQ_ed2k|Network FAQ]]". If you were expecting something else, you might be interested in the [[aMule is slow|aMule is slow FAQ]].

== Network speed - how much is it? ==
When talking about network speed, people use the unit "bps" which means
"bits per second". The reason that a ''bit'' is used rather than a ''byte'' is pretty much historical, but also has an engineering motivation behind it.

This motivation comes from the fact that not all networks in the world transfer their traffic in bytes.

There is a convention to use a capital "B" in "Bps" when speed is marked
in "bytes per second". However, this convention is not widely accepted. In particular, organizations like the [http://www.ietf.org/ IETF] and [http://www.ieee.org/ IEEE] stick to the original "bps".

== Prefixes ==
Since their invention, networks have made a lot of progress. Today we have networks that transfer thousands of millions of bits per second. For measuring these speeds the prefixes ''"kilo"'', ''"mega"'', ''"giga"'', ''"tera"'' etc. are used.

It is a common mistake to think that values with those prefixes are the same as in computer science, i.e. powers of 2. The truth is that, for historical reasons, prefixes in networking have a decimal base, and not a binary one.

{| cellpadding="2" cellspacing="2" border="1" width="100%" title="Table 1"
| valign="middle" title="Table 1" align="center" bgcolor="#33ff33" | Prefix
| valign="middle" align="center" bgcolor="#33ff33" | meaning in computers
| valign="middle" title="Table 1" align="center" bgcolor="#33ff33" | meaning in networks
| valign="middle" align="center" bgcolor="#33ff33" | difference, %%
|-
| valign="top" | K (kilo)
| valign="top" | 2^10 = 1024
| valign="top" | 10^3 = 1000
| valign="top" | 2%
|-
| valign="top" | M (mega)
| valign="top" | 2^20 = 1,048,576
| valign="top" | 10^6 = 1,000,000
| valign="top" | 5%
|-
| valign="top" | G (giga)
| valign="top" | 2^30 = 1,073,741,624
| valign="top" | 10^9 = 1,000,000,000
| valign="top" | 7%
|-
| valign="top" | T (tera)
| valign="top" | 2^40 = 1,099,511,627,776
| valign="top" | 10^12 = 1,000,000,000,000
| valign="top" | 9%
|}

As you can see from the table above the error in calculation is about 5% when the prefix is incorrectly interpreted. Please note that the speed your provider quotes you is the "speed in network units", i.e. calculated on a decimal basis.

For example when your provider tells you that your link is "ADSL 256/128" you
should understand that they mean 256000/128000 bps (bits). Which means, that the speed of your connection is 32000/16000 bps (bytes).

== Protocol overhead - what is it about? ==
When [[aMule]] is running, it constantly "talks" with other [[client]]s and [[server]]s.
This data exchange is needed to identify itself, request information about
available [[FAQ_eD2k-Kademlia#What_is_a_source?|source]]s and [[file]]s, to perform [[search]]es and so on.

Since this information has no direct use to the user itself, it is called "overhead" i.e. an inevitable addition to the data you actually want to [[upload]] or [[download]].

[[aMule]] calls this "''connection overhead''". However the number that [[aMule]] presents includes only the size of the actual data that [[aMule]] itself sends to the network stack. Later, this data is sent out on the network with even more overhead - that of the network protocols.
How much is it? - let's see that in the next section.

== Network overhead ==
First of all - we're talking about the [[IPv4]] network. Once upon a time, there
was only one type of [[IP]] network. Now there are two - [[IPv4|IP version 4]], the old we all know; and [[IPv6|IP version 6]] - the new protocol made to fix the limitations of [[IPv4]].

[[FAQ ed2k|ED2K protocol]] by design, is unable to talk over [[IPv6]] network, so users who have it (in Japan and China for example) will not be able to connect "as is". Using [[IPv4]] means, that each packet ([http://www.ietf.org/rfc/rfc793.txt TCP], [http://www.ietf.org/rfc/rfc768.txt UDP], [http://www.ietf.org/rfc/rfc792.txt ICMP]) will have an [[IPv4]] header.

The minimum size of this header is 20 bytes. The header can have optional parts (each of 4 bytes) and that is up to your provider - for example, mine adds an optional [dword].

When talking to other clients and servers on [[FAQ ed2k|ed2k network]], [[aMule]] uses the widely known [http://www.ietf.org/rfc/rfc793.txt TCP] protocol. [http://www.ietf.org/rfc/rfc768.txt UDP] is also used, but on a much smaller scale. As the reader might know, [http://www.ietf.org/rfc/rfc793.txt TCP] is a reliable protocol, i.e. it guarantees that data which is sent from one side will arrive on the other or an error will be reported.

In order to achieve this, [http://www.ietf.org/rfc/rfc793.txt TCP] sends its own data in addition to the actual "payload" data being transfered. This data includes [http://www.ietf.org/rfc/rfc793.txt TCP] client initial negotiation, checksums, sequence numbers and acknowledgments. All of this is in the ''[http://www.ietf.org/rfc/rfc793.txt TCP] header'' which is added to each packet sent. The size of this header is a minimum of 20 bytes.

While being only a small overhead for a large bulk transfer, it can take significant part of bandwidth when small amounts of data are being exchanged. This is exactly what happens on [[FAQ_ed2k#What_is_a_source?|source]] discovery part of [[aMule]].

Our [[client]] is trying to establish a connection and negotiate with a large number of other [[client]]s. Doing this, [[aMule]] opens new [http://www.ietf.org/rfc/rfc793.txt TCP] connections ''all the time''. The amount of connections opened is controlled by the ''"Maximum number of connections in 5 seconds"'' setting in the preferences.

A typical number is about 100. Each [http://www.ietf.org/rfc/rfc793.txt TCP] connection results in at least 3 packets traveling the net - one is a SYN packet, i.e. connection request, and one an ACK or a RST when the connection is accepted or refused, and SYN+ACK to establish the session.

There's more overhead of [http://www.ietf.org/rfc/rfc1034.txt DNS] queries when an address is resolved, retries when a host doesn't reply and so on.

=== At low level ===
After passing [http://www.ietf.org/rfc/rfc793.txt TCP] and [[IP]] layers packets go down to the network interface driver. What kind of driver this is depends on the way your computer is connected to the internet. For simplicity sake we will assume that this computer is connected to the ISP directly, i.e. you have no LAN (or switch or router) between.

Common setups that I'm aware of:

* Analog modem, connected to telephone line (ISDN modem falls in this category too).
* Cable modem, connected through ethernet, ISP gives you an [[IP]] address through [http://www.ietf.org/rfc/rfc2131.txt DHCP].
* Cable modem, connected through ethernet, ISP requires you to configure PPPoE or PPTP tunnel.
* ADSL modem, connected through ethernet. You must have a PPPoE or PPTP tunnel
* Variation of above - modem connected to PC by USB.

In each of the above setups there are different protocols in use, and different headers are added to transmitted packets. But there's one important thing to note: ''ethernet frames traveling between cable/ADSL modem and PC, and don't reach the ISP''.

And consequently they are not counted in rate calculations. [http://www.ietf.org/rfc/rfc2516.txt PPPoE] and
[http://www.ietf.org/rfc/rfc2637.txt PPTP] headers, on the contrary ''do reach the ISP''. I obviously have no idea whether or not your particular provider chooses to include them in their rate calculations. For this reason I will exclude those headers from my calculations.

If you think that your ISP includes it, add 4 bytes to the size of each packet.

=== Example ===
Let's see how much network overhead we have on a typical network. Our connection is a cable modem connected via an ethernet link to a PC directly (no router between them).

In this setup we have [[IPv4]] packets sent over ethernet.

Lets say we have 10 new connections opened each second, and all are being accepted (successfully established [http://www.ietf.org/rfc/rfc793.txt TCP] session). This alone sums up to (I'm counting data going up - from my computer to the net):

''10 connection * 2 packets * (20 bytes of TCP + 20 bytes of [[IPv4]]) = 800 bytes of overhead.''

This means that we are starting with 1.16*8 Kbps of "''invisible"''
overhead caused by the very way the network works. Now, let's assume that
after each connection is established our amule sends something to the other side and waits to receive an answer.

''Total of 800 bytes + 800 bytes = 1600 bytes per second = 6400 bps = 6.4 Kbps''

What we have here is 6.4 Kbps of network overhead alone. Taking into account
that amule has other data to send (uploads) and it is not the only network
application running we will have the following picture:

Most likely the link to your provider is not that fast. [[aMule]] will ''try'' to open 10 connections per second and will ''try'' to upload on the specified speed.

Your operating system will share all available bandwidth between those and between [[aMule]] and other network applications (browser for example). Actual results will vary depending on specific OS settings.

== ACK bottleneck ==
In all calculations above there was one assumption - zero download. But downloading is what amule was built for. So let's examine how the overhead
above affects your downloading speed. The answer is in [http://www.ietf.org/rfc/rfc793.txt TCP] protocol.

When [http://www.ietf.org/rfc/rfc793.txt TCP] is sending data, it requires that the other side acknowledge the reception. So if client A is sending data to [[client]] B by [http://www.ietf.org/rfc/rfc793.txt TCP], B has to send a special ACK packets to A which tells B "ok, I got it". If, however, A doesn't receive the ACK packets in time, he will assume that either packet is lost.

So, without going deeply into [http://www.ietf.org/rfc/rfc793.txt TCP] specification: ''if B fails to send ACK to A, as a result A will transmit slower''.

Now let's see the situation in [[aMule]]. We saw in the previous chapter, that the uplink stream is congested by connection requests and uploads. As a result, there's a good chance that ACK packets for a file we are downloading ''will not be sent on time''.

The remote party will notice this and slow down. This is one more reason why the upstream should better not be too congested.

== Is there anything I can do? ==
OK, now that you understood why your network is so slow while [[aMule]] is
running you will maybe look for a way to fix this. The answer in 2 words: "rate limit".

The first thing you should do is to assign realistic rate limits in [[aMule]]
itself. If you have a uplink rate of 128 Kbps don't set [[aMule]]'s [[upload]] limit to 16 (kilobytes per second) just because 128/8 = 16.

A better, but far more complicated solution is to use the QoS and packet scheduling services of your OS. For example, you can give a higher priority to ACK packets to solve the above mentioned "ACK bottleneck" problem.

The QoS topic, however, is beyond the scope of this article.

== Router (switch, home network): is there any difference? ==
When the cable coming from your ISP is connected to some switching or routing
device, which in turn is connected to several PC's, bandwidth is shared between
them.

So, having N computers connected, an ideal device would simply provide
each one of them with 1/N of the total bandwidth. The situation may vary in real life, and your particular device may have different idea about fairness.

Since you're not going to have the hardware specs of your router chipset the only advice here is "try and see yourself".

== Multiple links ==
Until now, we talked about computers that are connected to the network through
single interface. While being most frequent, this is not mandatory. A user
may choose to connect via 2 (or more links) provided by different ISP's.
There're 2 reasons for this decision that I know about: link redundancy and
load balancing.

=== Link redundancy ===
In a case of link redundancy second link becomes operational when primary
link fails. This can be done automatically, or by explicit user command.
When this setup used, [[aMule]] along with other network applications must be
restarted when links are being switched. This will allow to bind new address,
reconnect to server and receive new ID. If [[aMule]] is connected via  [http://www.ietf.org/rfc/rfc3022.txt NAT]]
enabled router (it doesn't matter if you have [[FAQ_ed2k#What_is_LowID_and_HighID?|low or high ID]]), and links
are switched ''on the router'', restart not needed.

=== Load balancing ===
This is a far more complicated case. Both (all) links are simultaneously active,
and traffic is being distributed between them. The problem is that [[aMule]]
binds to ''all interfaces on the system'' i.e. 0.0.0.0. But, on [[FAQ ed2k|ed2k]]
your ID is your [[IP]] address, ''and you can not have two''. 
So the problem is that [[aMule]] does not explicitly choose the source
address for ''outgoing'' [http://www.ietf.org/rfc/rfc793.txt TCP] connections. Note, that it ''doesn't
matter'' on which interface it listens. This is exactly ''opposite''
to ''server'' applications like FTP or HTTP. When a client
tries to connect to a server it discovers its IP address by resolving DNS. Resolver
replies will contain all [[IP]] addresses of the specified host and a client should try them all. The server, in turn, may choose not to listen on
one of them and thus prevent the client from using this interface. In our case
[[aMule]] ''is a [[client]]'', and the [[server|ed2k server]] discovers its address from the
[[FAQ_ed2k#What_is_a_source?|source]] [[IP]] in the connection request. That's where the [[server|ed2k server]] will try to connect.
If the connection succeeds the client is [[client]] assigned a [[FAQ_ed2k#What_is_LowID_and_HighID?|high ID]], if it doesn't the client gets a Low ID.
The only solution in this situation (until [[aMule]] will have an ability to
bind to specific address) is to use [[aMule]] on your "primary" link. 
You can, however, cause [http://www.kernel.org Linux] to send packet through interface of your choice.
But, most probably they will be dropped by your ISP's router as "spoofed" because the source [[IP]] address doesn't match the address the ISP assigned to that interface.

FAQ eD2k-Kademlia

2005-05-16T19:31:51Z

87.74.0.220:

<center>
<h4>F.A.Q. on eD2k-Kademlia</h4>

'''English''' | [[FAQ_eD2k-Kademlia-es|Español]] | [[FAQ_eD2k-Kademlia-it|Italiano]] | [[FAQ_eD2k-Kademlia-de|Deutsche]] | [[FAQ_ed2k-fr|Français]] | [[FAQ_eD2k-Kademlia-nl|Nederlands]]
</center>

== What is ED2K? ==
ED2K is a protocol originally used by the P2P (Peer-to-Peer) client [[eDonkey2000]], which is where the name comes from. It is a server-client based protocol, with the ability to exchange sources between clients.

The ED2K network is server based like many other P2P networks such as [[Kazaa]] (Kazaa is server based, but hides the server connection from the user), which means that the first thing you do when you run [[aMule]] is to connect to a server (either manually or automatically).

Once successfully connected to a server, the client can search, either locally (the connected server) or globally (all servers), for any file and the servers asked will provide the client with a list of all the files which match search parameters.

If the user starts a download, the client will then ask the server for sources, which the server will return in the form of IP addresses for the clients that have told the server that they have the specific file.

Then the remote client will begin to upload a whole chunk to your client as soon as you are the first in the queue, read [[FAQ_eD2k-Kademlia#What_is_all_that_credits,_rate_and_score_stuff_about?|What_is_all_that_credits,_rate_and_score_stuff_about?]] and, when the chunk has been completly sent, you will be taken back to it's upload queue. This way different chunks get spread around the ED2K network, so that, although no-one may have at a same given moment the complete file, it may be completed by downloading the different chunks from different people (it is well known that users tend to stop sharing a file once it has been completed). 
Note that clients upload only '''one''' chunk at a time to another client. Even if a client is in the upload queue of two different files of a same user and gets to the top of both, that user will only upload one of the files to that client (the other upload, depending on the ED2K application the client uses, will probably remain as a maximum priority upload, but will not begin until the other chunk has been successfully uploaded).

If both users have HighID (see [[FAQ_eD2k-Kademlia#What_is_LowID_and_HighID?|What is LowID and HighID?]]) the transfer will be done directly from client to client (Peer-to-Peer), but if one of the clients have LowID, the connection will be established through the server, since LowID cannot accept incoming connections. As a result, two LowID clients '''cannot''' connect to each other.

== What is Kademlia? ==
Kademlia is a natural evolution of the ED2K network. Kademlia is the future. See [[FAQ_eD2k-Kademlia#Are_there_any_limitations_on_the_ED2K_network?|Are there any limitations on the ED2K network?]] for more information on why Kademlia is necessary.

Since Kademlia is a decentralized network, it removes the bottleneck that was previously caused by the need for servers (though [[Lugdunum]] has done great work in reducing this bottleneck). Now, instead of connecting to a server, you just connect to a client (with a known IP-address and port), which supports the network [[Kademlia]]. This is called the Boot Strapping.

Once connected, depending on your ability to accept incoming connections, you are given either "open" or "firewalled" status, which is similar to the HighID and LowID of the ED2K network. Then you are given an ID.

At the moment, "firewalled" users aren’t supported by the Kademlia network, and therefore won’t be given an ID and will be unable to connect. Firewalled support will be added later.

When searching, each client acts as a small server and is given responsibility for certain keywords or sources. This adds to the complexity of finding sources, as you no longer have a central server to ask, but instead will have to propagate the query through the network.

Currently, Kademlia isn't supported by aMule, but it will be soon.

TODO: Does Kademlia remove the 4 GB file size limit ?

== Is Kademlia the same as Overnet? ==
Short and clear: No. Overnet is the natural serverless evolution of the eDonkey software, while Kademlia is the natural serverless evolution of *Mule clients. SO, it's the same philosophy, but different rules. To learn about how Overnet works, refer to http://www.edonkey2000.com/documentation/how_on.html but, have in mind, Overnet's development is closed untill it reaches version 1.0, while Kademlia's development is completly open from the very beginning.

== What is a chunk? ==
In the ED2K protocol, to avoid sharing corrupt files, each file is divided into various parts, which are known as chunks, and then each chunk is hashed (read below to know what a [[FAQ_eD2k-Kademlia#What_is_a_hash?|hash]] is). Each chunk is 9.28MB in size, so a 15MB file will be divided into two chunks (9.28MB + 5.72MB), a 315KB file will be a single chunk and a 100MB file will be divided into 11 chunks (10x9.28MB + 7.2MB).

== What is a hash? ==
Dividing each file into chunks (see [[FAQ_eD2k-Kademlia#What_is_a_chunk?|What is a chunk?]]) will avoid the problem of downloading a whole corrupted file since only the corrupted chunk will have to be downloaded again, but a method to identify corrupted chunks is needed. This is done by using MD4 hashes.

A [[MD4 hash]] is a unique value each chunk is given and is the result of a mathematical operation on every single bit on the chunk. This means that modifying a single bit in a chunk would result in a completely different hash. That means that the client needs to verify the integrity of each part of a file as it is downloaded.

Not only are the chunks hashed but also, in order to get a file-hash, all chunks's hashes are concatenated one after the other in their file order (that is: chunk1's_hash+chunk2's_hash+chunk3's_hash+...) and the resulting string is hashed. This way, each file on the ED2K network has a unique identifier. The file hash isn't taken from hashing the whole file, but from hashing the value of the the chunk's hashes.

In reality, you need both the hash of a file and its size. These pieces of information is embedded in the ED2k URLs found in many places.

Take this for example: 
ed2k://|file|eMule0.42f-Sources.zip|2407949|CC8C3B104AD58678F69858F1F9B736E9|/

The interesting parts are the fifth part, "2407949", which is the size of the file in bytes and the last part, "CC8C3B104AD58678F69858F1F9B736E9", which is the hash itself, stored as hex-decimals, 32 letters long.

The filename itself is irrelevant in the process of identifying the file.

== Why after searching, some files which are the same appear as a different file in the results, although they even have the same name? ==
If you understood "What is a hash" you will understand this quickly. When a search is started, the server tells the ED2K client the filename of the found file and the hash of the complete file for each file which matches the search. If two files, although being the same, have some difference in their content, no matter if it's big or small, the hash is different, so they are considered as a different file. That's also the reason why two file with different file name appear as the same file: on the ED2K network, the filename isn't important, the hash is.

== What is LowID and HighID? ==
Each client is assigned an identifying number, an ID, which will be unique and will distinguish him from any other client on the server. If this ID is below 16777216 (16 million) then you have a LowID. If it's over, then you have a HighID. To be given a high or low ID will only depend on having TCP port 4662 (or the one set up in Preferences) opened. If you understood "What is ED2K" you might understand that chances are that clients on LowID may be unable to connect to many other clients (all those on LowID) so will have a lower transfer rate. That's why having port 4662 TCP (or the one set in Preferences) is so important. Also, some big servers refuse clients on LowID to connect to them since LowID clients have data transfered through the server and so, those big servers could be overcharged. 
For HighID clients, their ID is the result of a mathematical operation with their IP which corresponds to A + 256*B + 256*256*C + 256*256*256*D, where the IP is A.B.C.D. Also have in mind that this ID has identification purposes, nothing else, so apart from having and ID over or under the 16777216 number, it does not matter if the ID is bigger or smaller. This means a client with an ID like 50000000 isn't better than a client with an ID like 49999999. 
There's still an exception. Sometimes badly configured or very busy servers give LowID to some clients although the 4662 TCP port is opened. This are rare exceptions, but it might happen sometime. 
Check [http://www.amule.org/testport.php here] if you have your ports opened.

== Which ports do I have to configure in a firewall or router to run aMule? ==
aMule works even with no specific ports opened, but you won't get a HighID in this case. As mentioned above, to be given a HighID, port 4662 TCP (or the one set in the Preferences) must be listening (i.e. opened in your firewall and forwarded in your router). 
Apart from that port, to have an optimal ED2K experience, two more ports should be enabled as well. First, the UDP port 4672 (which can also be changed to any other number in the Preferences) and secondly, the secondary UDP port which can't be set in the Preferences. This UDP port is your TCP port + 3 (e.g.: TCP=4662 then UDP=4665).

== What does each port do? ==
Well, since most ports can be configured to be set to any other number, the defaults will be listed:

; 4662 TCP: Client to client transfers.
; 4665 UDP: Opened on client, used for global server searches and global source queries. This is always Client TCP port + 3.
; 4672 UDP: Extended eMule protocol, Queue Rating, File Reask Ping
; 4661 TCP: Opened on server. Allows connection to server.
; 4665 UDP: Opened on server. Allows asking for sources. It is always Server TCP port + 4.
; 4711 TCP: WebServer listening port.
; 4712 TCP: External Connection port. Used to communicate aMule with other applications such as aMule WebServer or aMuleCMD.

== Are there any limitations on the ED2K network? ==
Not much, but yes, there are: two natural limits and a "forced" limitation. The two natural limits have already been mentioned before. First, the issues on LowID users (their transfers involve data through the server and two LowID clients can't share between them). The second, although ED2K is a p2p protocol, it needs servers to establish the p2p connection. This latter one is solved in the Kademlia protocol. 
About the "forced" limitation, it's only a limit to make sure that clients share so that the ED2K network will not disappear: clients which have an upload limit of X KBps, where X is between 0 and 3.99 (both included) can download at a maximum of X*3 KBps. Clients which have an upload limit of Y KBps, where Y is Between 4 and 9.99 (both included) can download at a maximum of Y*4 KBps. Clients with an upload limit of 10KBps or more have no downloading limitations. This restriction is set in the client application so it could be by-passed by hacking the code, but that would probably result in being banned from the servers you connect to. 
Also, any client is forced to allow at least three upload slots, so it's not possible to allow more than upload_limit/3 KBps per slot. 
There is one last limit: Network file limit is 4GB. 
Additionally, this is not an eD2k limitation but a server limitation, servers will only send 300 results for your searches, so don't expect any more results.

== In search window, what filter stands for which filetype? ==
Have in mind that the filters in the search window don't depend on the file type, but on the extensions of the filenames, in the following way: 
Archive: .ace .arj .rar .tar.bz2 .tar.gz .zip .Z 
Audio: .aac .ape .au .mp2 .mp3 .mp4 .mpc .ogg .wav .wma 
CDImage: .bin .ccd .cue .img .iso .nrg .sub 
Picture: .bmp .gif .jpeg .jpg .png .tif 
Program: .com .exe 
Video: .avi .divx .mov .mpeg .mpg .ogg .ram .rm .vivo .vob 
So, a movie which's filename is "Birthday.zip" will appear in the Archive filter, but not in the Video filter.

== What is a source? ==
A source is a client which is sharing some chunk in some file you have in your downloading queue which you still have not completed. Obviously, the more sources you can get for a given file, the more possibilities you have to download the file and the quicker you'll download it. Have in mind that there's a difference between "sources" and "available sources" if you're on LowID, since "sources"s stands for clients sharing a chunk or file you still haven't completed, while "available sources" stands for clients sharing a chunk or file you still haven't completed and from who you can download (that is, a source who is on HighID).

== What is all that credits, rate and score stuff about? ==
All three concepts have to do with the way in which the ED2K network establishes the uploading queues preferences. 
The score is the most important value: the client with the higher score will be the next client which you'll provide a slot to. The way in the score value is set is this: score = rate x time_waiting_in_seconds / 100
So, to understand this, we must known what rate is. 
Rate is can be understood as an objective preference. This is, the preference which a client is given without caring how much time it's been waiting. When a client is added to the uploading queue, it gets a rate of 100. This value is modified following according to this: 
According to the amount of credits, the rate will be multiplied by 1x to 10x.
Depending on the file priority, it will be multiplied by 0.2x to 1.8x (Release 1.8x, High 0.9x, Normal 0.7x, Low 0.6x, Very Low: 0.2x). 
Users on specific old clients which load too much the network traffic will get penalized by multiplying their rate by 0.5x. 
Banned clients will instantly get no rate (that is, their rate will by multiplied by 0). 
This multiplying values are known as "modifiers". Clients with a modifier value strictly bigger than 1 will be marked as yellow in the icon. 
So we only have credits left to known. Credits are a prize you get for uploading files to a specific user. Credits are exchanged between two specific clients, they are not global, so your own credits can't be viewed, although you can know the credits any other user has on you (that is, the credits you owe that client). Since credits are managed by the uploading client, you might be uploading to some client with no credits support, so you will gain no credits on him, although that client will actually get credits on you if it uploads to you, since you do have credits support. This credits are stored in clients.met file. 
The credits modifier used by rate is the lower between these two: (upload_total x 2)/download_total or sqrt(upload_total+2) where both upload_total and download_total are measured in MBs. 
If the result is lower than 1, then it is set to 1 and if it is bigger than 10, it is set to 10. In addition, if the uploaded total is less than 1MB, the modifier is set to 1 and if the downloaded total is equal to 0, then the modifier is set to 10. 

== What is a slot? ==
When uploading files, your upload bandwidth (which may vary depending on the upload limit or the natural connection-type upload limit) will be divided into slots. So, each slot is an amount of KBps which will be assigned to each client who tries to download from you.