AMule Project FAQ - User contributions [en]

Signature

2006-09-13T19:32:14Z

82.66.21.14: a typo error (s/singature/signature)

Online Signature is a ''mono-directional'' way [[aMule]] has to communicate with external utilities (such as [[CAS]], [[wxCAS]], [[AMPS]], etc...).

It consists of a file [[aMule]] writes on disc from-time-to-time (by default, every 5 seconds, but this can be changed in "Preferences" -> "Online Signature") to inform about it's current status.

[[aMule]] currently supports two signature files formats:
*[[amulesig.dat_file|aMule signature file (''amulesig.dat'')]]
*[[onlinesig.dat_file|eMule signature file (''onlinesig.dat'')]]

More information about this can be found at [[FAQ_aMule#What_is_all_that_stuff_in_amulesig.dat_and_onlinesig.dat?|aMule's FAQ]].

Talk:Firewall

2005-07-22T16:04:44Z

82.66.21.14:

I think that think page should also contain basic Linksys and Dlink router information since you're also trying to attract windows users.
[[User:Ateo|-- Juan]] 21:28, 27 May 2005 (CEST)

'''Yap. fine now, who's gonna provide that info? ;-P'''

I'll add linksys information soon. Anyone with a DLink router should also contribute.. =) [[User:Ateo|-- Juan]] 19:41, 28 May 2005 (CEST)

Um. I thought the == before and after a section automatically creates a menu for the page? Am I wrong?

'''You're not. But only if there are at least four == sections in the article. Otherwise no menu will be created'''

I just threw some D-Link info in there, based on what I did on my DI-624 to get aMule to show High ID. I have to admit though that I don't quite get how the Applications page settings relate to the port forwarding in Virtual Servers, unless you do an entry in Virtual Servers for each port in the 4662-4672 range for UDP. Any thoughts? -Sharakan

''':-) Thanks for your tips!'''

The instructions do not work with my Dlink DI-604. When I try and add the Application rule I get a notice saying that there is a conflict with the Virtual Server rule I've just set up. HTH

----

Cleaning the iptables rules :
I think the basic rules (section 2 : IPTables Configuration) are not really good.
If you use (as said in the wiki) :

iptables -A INPUT -p tcp --dport XX -j ACCEPT

it works but to my mind the other lign :

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

does nothing because the first lign accept all state packets (NEW,ESTABLISHED,RELATED,UNTRACKED and INVALID). So the first line accept more the second (but only for the amule ports).

I think we could increase the security by using :

iptables -P INPUT DROP

iptables -A INPUT -p tcp --dport XX -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT

The first line is the global policy : we drop all.
The second line is the strategy for amule.
The third line is the strategy for the other ports.

For aMule,we need the 'ESTABLISHED' and 'RELATED' states to allow the answer to our requests. We need the 'NEW' state to allow the request of the others p2p clients. If we don't allow 'NEW', we are on low ID. (that's the result of my test.)

Perhaps, it's even possible to delete ESTABLISHED or RELATED (only one). It depends on how the answer request are done. (? I don't know. Need further research.)

Of course, you need to add modified lines if XX+3 or UDP are needed.

I don't made direct change on the wiki because I think several persons should test my change to check if I have made an error.

stephane.

---

I use the following rules (well, [http://www.netfilter.org/ iptables] 1.2.7a):

iptables -A INPUT -p tcp -m tcp --dport 4662 --tcp-flags SYN,RST,ACK SYN -j ACCEPT

iptables -A INPUT -p udp -m udp --dport 4665 -j ACCEPT

iptables -A INPUT -p udp -m udp --dport 4672 -j ACCEPT

and [[aMule]] works great with them. I don't how much are these the same as yours, stephane. (Policy rule is not included intentionally)

[[User:GonoszTopi|GonoszTopi]]

---

My rule for aMule is (iptables v1.2.11) :

iptables -A INPUT -i eth0 -p tcp -m state --state NEW,ESTABLISHED,RELATED --dport 4662 -j ACCEPT

I have disabled the udp port in aMule so I don't need to open them. However, if I had keep them open, I would have these lines too :

iptables -A INPUT -i eth0 -p udp -m state --state NEW,ESTABLISHED,RELATED --dport 4665 -j ACCEPT

iptables -A INPUT -i eth0 -p udp -m state --state NEW,ESTABLISHED,RELATED --dport 4672 -j ACCEPT

I have tested with 'netstat -taupe' and the clients connected to me use the ESTABLISHED state so it seems that I could delete the RELATED state (further tests needed). If it's true, my rule becomes :

iptables -A INPUT -i eth0 -p tcp -m state --state NEW,ESTABLISHED --dport 4662 -j ACCEPT

Your rules check different thing than mine. Perhaps it could be interresting to mix them.

stephane.

Talk:Firewall

2005-07-19T00:11:09Z

82.66.21.14:

FAQ ed2k-fr

2005-07-05T19:42:02Z

82.66.21.14:

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

== ED2K, c'est quoi ? ==
A la base ED2K est un protocol pour le client P2P (pair-à-pair) [[eDonkey2000]], c'est de là que vient son nom. C'est un protocol basé sur une interraction serveur-client, avec la capacité d'échanger les sources entre les clients.

Le réseau ED2K est basé sur les serveurs à la différence des réseaux de P2P tels que [[Kazaa]], ce qui signifie que la première chose que vous faites lorsque vous lancez [[aMule]] est de vous connecter à un serveur (manuellement ou automatiquement).

Une fois connecté avec succès à un serveur, le client peut chercher, soit localement (au serveur connecté) soit globalement (tout les serveurs), n'importe quel fichier et le serveur questionné fournira au client une liste de tout les fichiers qui répondent aux paramètres de recherche.

Si l'utilisateur démarre un téléchargement, le client demandera alors au serveur des sources et le serveur va renvoyer le nom (sous la forme d'adresse IP) des clients qui ont répondu qu'ils avaient bien le fichier demandé.

Ensuite le client distant va commencer à envoyer un chunk entier à votre client aussitôt que vous serrez le premier dans la file d'attente. Et, quand le chunk à été envoyé en entier, vous serez effacé de sa file des envois. Cette façon qu'on les différents chunks de se répendre autour du réseau ED2K fait que même si personne n'a à un instant donné le fichier complet, he bien il peut être complété en téléchargeant les différents chunks à partir de différentes personne ( c'est bien connu que les gens arrêtent de partager un fichier une fois qu'il à été complété).

Remarquez que les client n'envoient que '''un''' chunk à la fois à un autre client. Même si un client est à la fois dans la file d'attente des envois pour deux fichiers différents chez un même utilisateur, et arrive en premier pour ses deux fichiers alors cet utilisateur ne lui enverra que un fichier à la fois (selon l'application ED2K que le client utilise, l'autre envoi restera probablement à une priorité maximale dans la file des envois, mais il ne commencera pas tant que l'autre chunk n'a pas été envoyé complètement).

Si les deux utilisateurs ont un HighID le transfert sera effectué directement de client à client (Pair-à-Pair), mais si un des clients à un LowID, la connection sera établie par l'intermédiaire du serveur parceque les LowID ne peuvent pas accepter une connection entrante. A cause de ca, deux client ayant un LowID '''ne peuvent pas''' se connecter entre eux.

== Kademlia c'est quoi ? ==
Kademlia est l'évolution naturelle du réseau ED2K. Kademlia est le futur. Regardez [[FAQ_eD2k-Kademlia#Are_there_any_limitations_on_the_ED2K_network?|Y a t il des limitation au réseau ED2K?]] pour plus d'information sur la necessité de Kademlia.

Parceque Kademlia est un réseau décentralisé, il évite le goulet d'étranglement qui était précédemment causé par le besoin de serveurs (bien que [[Lugdunum]] ait accompli un grand travail dans la réduction de ce goulet détranglement). Maintenant au lieu de vous connecter à un serveur vous ne faites que de vous connecter à un client (avec un port et une adresse IP connus), qui supporte le réseau Kademlia. C'est appellé le "Boot Strapping".

Une fois connecté, et selon votre capacité à accepter des connections entrente, on vous donne le status de "ouvert" ou "derrière un firewall", ce qui est similaire au HighID et LowID du réseau ED2K. Ensuite on vous donne une identification.

Pour le moment, le utilisateurs "derrière un firewall" ne sont pas supporté par le réseau kademlia, et ne recevrons donc pas un identification et serons incapable de se connecter. Le support des gens "derrière un firewall" sera ajouté plus tard.

Pendant la recherche chaque client agit comme un petit serveur et recoit la responsabilité de certaines sources ou mots clés. Cela ajoute à la complexité de trouver des sources parcequ'il n'y a plus un serveur central à questionner, mais au lieu de ca il faut propager les requêtes à travers le réseau.

Actuellement Kademlia n'est pas supporté par aMule, mais il le sera bientôt.

== Est ce que Kademlia c'est la même chose que Overnet? ==
En un mot : non. Overnet est l'évolution sans serveur naturelle du logiciel eDonkey, alors que Kademlia est l'évolution sans serveur naturelle des clients *Mule. DONC, c'est le même principe, mais suivant des règles différentes. Pour aprendre le fonctionnement de Overnet, réferrez vous à http://www.edonkey2000.com/documentation/how_on.html mais gardez à l'esprit que le dévellopement de Overnet sera fermé jusqu'a ce qu'il atteigne la version 1.0 alors que le dévellopement de Kademlia est totalement ouvers depuis le début.

== Qu'est ce qu'un chunk? ==
Pour éviter de partager des fichiers corompus, le protocol ED2K divise chaque fichier en un certain nombre de morceaux, qui sont appelés ''chunk'', et ensuite chacun des chunks est réduit à son tour en petits morceaux (lisez plus bas pour savoir ce que sont ces petits morceaux). Chaque chunk a une taille de 9.28MB, ainsi un fichier de 15MB sera divisé en deux chunks (9.28MB + 5.72MB), un fichier de 315KB sera un seul chunk et un fichier de 100MB sera divisé en 11 chunks (10x9.28MB + 7.2MB).