eChanblard nous sort une version en BETA test d'une mule intégrant un cache. Ceci est une idée totalement nouvelle sur notre réseau. Nous vous encourageons à la tester.

Charte régissant l'utilisatioin de cette version

Si vous voulez tester le version BetaTest de eChanblard vous devez accepter ceci :
- vous vous engagez à signaler les bugs ou erreurs sur le forum d'eChanblard
- vous vous engagez à ne pas publier ce fichier sur un autre site sans l'accord d'eChanblard en personne
- ne pas assimiler eChanblard version publique et cette version Beta ( en clair ne pas dire , j'ai echanblard 3.2!!! mais j'ai la version 3.2 Beta test qui a sûrement des bugs).
- cette version est en beta test et comporte sûrement des bugs, peut être plus que la 3.1
- ne pas donner ce fichier à une autre personne , elle doit aussi accepter cette "charte"
- la version finale sera certainement sous emule 0.30b donc il y a une forte probalité de changements.

Bon si vous acceptez voici le lien :
Lien vers le fichier compressé emule.rar ne contenant qu'emule.exe

Note : si une de ces regles n'est pas respectée, eChanblard ne publiera plus de version en beta-test publique


Nouveautés intégrées
Cette version nous intéresse plus particulièrement pour une raison, elle intègre le cache emule dont nous parlions dans le post "Propostions d'amélioration du réseau eDonkey".

La partie du serveur n'a toutefois pas encore été réalisée par Lugdunum, nous attendons encore de savoir si il accepte de gérer la liste des chunks rares publièes par les clients. Cette nouvelle option fonctionne donc sans serveur, le résultat est moins fiable et efficace, mais ca fonctionne quand meme :-)

Ce cache permet le stockage de chunks rares et ainsi d'améliorer leur distribution en augmentant le nombre de sources disponibles.


Explications techniques
Je vous laisse allez lire ICI le fonctionnement de ce cache


Si vous avez des questions ou remarques sur le fonctionnement de ce cache (pas d'annonces de bugs ici svp), vous pouvez laisser un message dans ce post sur notre forum.

Si j'ai bien compris, en fait, le log telecharge des chunks rares et les partage tout seul
c'est bien, mais est-ce que çà fait rallentir la connection? ou est-ce que çà upload ces chunks en restant dans la limite upload definie
si çà ne fait pas ramer la connection, çà peut etre interessant à tester

moi, j'ai une remarque sur le fonctionnement meme du log
si je remplace l'exe de l'archive à la place de celui de ma muleplus1h, çà ne marche plus pasque j'ai pas la bonne dll, faut surement remplacer à partir de la version 0.30a (ou
donc pour l'instant, je ne teste pas cette beta

Pour répondre à tes requetes , le cache respecte les regles de base quand aux ratios et aux paramètres de emule et j'ai mis le dll qui te manque dans le fichier ( je l'ai réul à 15:40h) Voila++

finalement, j'ai opté pour faire un test de cette beta
çà a l'air de bien marcher, mais je ne sais pas si le cache fonctionne
et si j'ai une reproche à faire à cette version, c'est que on ne peut pas avoir plusieurs repertoires temp en meme temps alors que eMule plus le fait, c'est dommage
et puis eMule plus est plus joli, je trouve
et j'ai aussi l'autoupload(gamerv2) qui s'affole, je ne sais pas si je l'ai bien configuré
j'ai mis l'upload entre 5 et 16 avec l'option gamerv2 et mon upload est souvent à 5, c'est dommage, je vais remonter la limite minimum d'upload à 8

Moi je la teste tout de suite

P.S eChamblard, pourrait tu m'expliquer ton code??? pour que je progresse en visual c++???
Enfin si tu a un peut de temps....
Merci d'avance...

En tout cas, chez moi, l'auto-update n'avait pas l'air de fonctionner correctement, donc je l'ai desactivé, meme avec une limite upload minimum à 10, j'uploadais à 4 de moyenne!

Bon, apres quelques heures, voilà les comportements que j'ai relevé:
tres bon download, jamais vu çà!
mais l'upload est tres mal géré sur ma machine, meme sans l'upload automatique, avec une limite d'upload à 12, j'uploadais à 2~3 et çà me ponpait ma BP, je ne comprends pas pourquoi
sur ce, je suis donc repassé à ma bonne vieille mule plus qui fonctiionne correctement, mais à la sortie finale de la version 3.2, rien ne dit que je ne retourne pas sous chamblard

Allez hop c'est parti pour le test :-)

je m' y met aussi...

Bêta, bêta... :-o :-o
Je sais que je ne suis pas très rapide, mais ce n'est pas une raison pour être grossier !

;-) eChanblard

Bon apres une nuit pas de problème :-)
up stable
Par contre que 3 fichiers en Dl donc un ratio de 3,3 ul pour 1dl

Sans quoi nickel

Bon me voilà aussi dans le test. Ca tourne depuis hier soir, pas de prob d'upload. J'up à 3kos à chaque demandeur et j'ai désactivé les fonctions de gestion d'upload, je n'en ai jamais besoin :-)

Par contre dans les stats c'est marqué ceci :
Données envoyées par le cache : 0 Octets
Données reçues par le cache : 0 Octets

est-ce que ces stats fonctionnent ?

Est-ce que qqun qui est devant sa mule beta peut éditer le fichier du cache, il est situé dans emule temp, et dire si on peut identifier les fichiers que l'on met en cache ?

pour l'instant j'ai ça dans mon fichier cache.dat :

comment on sait si notre mule a mis des chunks rares dans notre cache ?

Tu dois le voir dans le log debug, onglet serveur. Si tu le vois pas, c'est que tu dois l'activer dans les préférences.

J'avais ça.

Autre question : ces 5 chunks, ils viennent de fichiers rares que j'ai ?

Moi j'ai ça dans le cache
<

et pour un fichier de 51201 Ko


Voila voila pour les infos du cache

j'avais deja fouillé le fichier cache hier lors de mes tests, et en l'ouvrant avec un editeur hexadecimal, je pouvais voir :
00 00 00 00 00 00 00 00 00..... pendant 50mo
le cache etait vide, mais si j'ai bien compris, c'est pasque le serveur n'envoyait pas de liste de chunks rares à cacheter

Les mules beta peuvent communiquer entre elles les chunks rares, cette version peut donc se passer du serveur mais l'efficacité est moindre.

Là on test la stabilité de la version et une fois le test effectué j'espère que lugdunum aura rendu sa décision concernant l'intégration de la gestion du cache au server.

Je viens dee l'installer pour tester ... ;-)

moi je la quitte et la relance et hoooooooooo malheur. les 2/3 de mes DL ont disparus !!!
qui peux me dire comment les récuperer? (les .part et .met sont bien là pourtant)
j'ai bien essayé de changer le dossier TEMP de place, mais c' est tjrs pareil. Le pire c'est qu'il a perdu des Dl de mon MOD précédent et des fichiers mis en télé sous eChanblard
bon c pas grave je suis pas pressé, mais j'ai quand même 20 gigas quis scouattent

bon apres reboot, j ai perdu tout les .part et les .met et il me reste 3 serveurs.
Je relance echanblard et là pus aucuns DL! je kitte.
je lance LSD là j'ai la moitié de mes DL

sniffffffffffffff

je comprend plus rien :-? :-?

Mon DD a grossit mais le dossier temp est vide ( a part le cache, 51 megs). eChanlard ne voit rien mais mon Mod lsd trouve 1/3 de mes DL (sur les 2/3 perdus)

Bizzare j'ai fait des tests entre emule-cache et emule officielle 0.30b et 0.30a, j'ai pas perdu un seul down et pourtant j'en ai 40 en cours.

Je me demande si ca vient pas de la lsd ce problème.

sur + de 70 fichiers, j'en ai perdu 2 ou 3, mais rien d'important :-)

sinon l'auto-up fonctionne nickel chez moi (min:5 max:7)
l'up est stable avec ou sans l'auto-up activée
dl quasi instantané

bonne bête

mais tjs rien de transferé par cache :-?

Comme il manque encore la gestion des chunks rares par le serveur, notre mule-cache doit s'en passer. Pour ce faire elle dialogue avec d'autres mule-cache, mais faut-il encore en trouver car pour l'instant on est pas nombreux.

comment on pourrait faire pour accélérer ces tests du cache ?

Bon, version mise en place.
Onglet Verbose : demande 5 chunks au serveur. Rien de plus.
Pas de Dl perdus.
J'ai monté la taille du cache à 250 Mo (je suis généreux ) mais pour le moment, le fichier reste avec une taille de 50 Mo.

Voila, quoi.

Extrait d'un tuto sur http://www.echanblard.org

Oui oui, j'ai vu cela après, merci Franfrou.
Bah, maintenant, on laisse courir ;-)

bile, des nouvelles de Lug' voir si les serveurs vont suivre ?

Dommage que ces 5 chunks ne soient pas encore téléchargés...

okai merci ;-)

sinon depuis que j'ai désactivé l'auto-up, mes dl montent en fleches :yes3:

Bon je viens de m'apercevoir que j'avais enlevé la partie qui ajoutait arbitrairement les chunks rares ( il n'y as pas le serveur mais il faut quand meme pouvoir le tester) , je l'ai donc réuploader et il ajoute les chunks suivants à la création du fichier cache (ceux qui en ont d'ajà un devront le supprimer manuellement dans leur répertoire temporaire):

1) D6C3E1FB658704A0A8F847E8904CC0BD
Partie n°1
taille fichier complet : 657287624 octets


2) 2D6DD7F4724420FDD0D517DBF878835F
Partie n°2
taille : 674582528

3) 519DD324C364EE10F013C8A7906B987A
Partie n°5
taille : 732071936

4) 670864CE2242CAD0D93351F6D2E68D88
Partie n°3
Taile : 809492544

Toutes les infos concernant le cache sont dans la fenetre debug (verbose)

Voila je vous rappele le liens :
Fichier .rar
et je vous rappelle que vous devez respecter la chartre ;-)

Suite aux reponses des tests d'autres utilisateurs, et suite à la nouvelle version de la beta, j'ai décidé de renouveler mon test eChamblard
j'install, je lance, parfait
je regarde le fichier cache en exadecimal, et je constate avec saisfaction que le tout debut du fichier n'est pas que des 00 00 00, j'en conclut qu'il a bel et bien essayé de mettre en cache des fichiers
je posterai plus tard l'avancement du cache

Je suis désolé d'arriver comme un cheveu dans la soupe, mais mon propos à la base est d'essayer d'apporter ma pierre à l'"édifice".

Non, je n'ai pas (encore :-) ) la version eChanblard, mais je viens de voir passer aujourd'hui sur ma Mule un utilisateur bile666, en Suisse d'après l'IP, avec une version eChanblard 3.2 (il y a derrière le nom un nolistsrv et un | avec des caractères cryptiques dont "Çh" dedans). Est-ce bien la personne à laquelle je pense ? Si ce n'est pas le cas, ignorez la suite de mon post et veuillez m'excuser pour cette mini-intrusion ...

Le problème est qu'en relançant ma mule, cet utilisateur s'est retouvé blacklisté dès les débuts. Je n'avais pas activé le log donc je n'ai pas pu savoir pourquoi. J'ai donc réactivé l'utilisateur pour voir si cela se reproduisait: apparamment non, jusqu'à maintenant. :-?

De plus, cet utilisateur se retrouve pratiquement systématiquement avec un score très bas dans ma file d'attente, sans raisons apparentes !? Et-ce malgré deux relances successives.

Enfin, les sessions échouent à chaque fois (2 fois je crois mais je ne suis pas devant) avec cet utilisateur.

Je sais bien que je n'utilise pas la version officielle puisque c'est le mod eMule Plus en version 1h (avec identification compatible eMule 0.30). Mais ce mod n'est pas réputé pour être éloigné des standards d'eMule. D'autre part, le nombre d'utilisateurs blacklistés chez moi est en général très faible; j'en déduis donc que ses critères d'exclusion ne sont pas trop "drastiques".

Tout cela pour dire:
Y a t-il quelque chose qui fait que cette version eChanblard ne "cause" pas avec ma version ? avec d'autres versions ?
Ceux qui testent actuellement ont-ils des problèmes avec d'autres sources ? Ce n'est pas toujours facile à savoir; par défaut les versions des Mules actuellement sont souvent configurées pour ne pas envoyer de messages en cas de blacklistage (ce que je trouve parfaitement logique pour le bien du réseau).

Encore, une fois désolé si tout ceci ne concerne pas cette version. Je trouve juste le comportement de ma Mule avec ce client un peu "bizarre", alors que ce n'est normalement pas le cas pour les autres.

PS. Mon nom d'utilisateur sur eMule n'est pas Sabel. Ne me cherchez donc pas...

Ah c'est bien moi, c'est donc chez toi que je charge tous ces films de cul :yes3:

j'en profite pour te dire merci . enfin disons que j'essaie de charger.....

J'utilise eChanblard depuis quelques mois, et c'est avec plaisir que je vais tester la nouvelle mouture!
L'idée du caghe parrait très bien!

He non, ce n'est pas chez moi !

Je n'ai qu'un seul fichier de ce type en cours chez moi, et ce n'est pas un film. C'est un fichier compressé que tu ne pourras pas décompresser car il est protégé par un mot de passe, que manifestement personne ne connait, y compris la personne qui m'a demandé de regarder cela. D'où mon intérêt pour ce fichier... :ange2:

Par ailleurs, ce n'est pas la peine de me remercier, car tu peux rien télécharger chez moi (1 seul chunk chez moi te concernant, que je n'ais jamais pu t'envoyer et pour cause).

Plus sérieusement, est-ce que par exemple ton taux de sessions échouées a augmenté depuis ton passage à la version eChanblard ? Est-ce que ta progression dans les files d'attentes des sources te paraît correcte ?

Je m'interroge sur le comportement de cette nouvelle version eChanblard. Ceci dit, cela n'a peut-être rien à voir; ou pire c'est peut-être ma version qui est cause. C'est dernière solution me paraît peu probable, car le comportement avec ce client est encore une fois un peut particulier.

j'sais pas pour vous, mais pour moi, c'est bon signe tout çà!

oula j'ai eu 1 bug.
j'avais au moins deux fichiers términés d'être téléchargés. j'ai fermé ma mule, l'ai redémarrée et pis les fichiers téléchargés ne sont plus dans la liste et il n'y a qu'un seul fichier dans mon repertoire incoming. et d'autre fichiers de ma liste on disparus (pas beaucoup juste 3 ou 4 mais des trucs plus important cette fois :-x )
bizarre..., à surveiller

[edit]:fautes

_def_, c'est normal que les fichiers terminés n'apparaissent plus dans ta liste au moment ou tu relances ta mule car les .part ont disparu du repertoire temp, c'est normal, mais de là, à ce que tes fishiers ne soient pas dans incoming, c'est bizarre, si t'as eMule+, tu peus choisir le repertoire de destination de chaque fichiers, fais rechercher le nom du fichier, tu verra bien

et pour ma beta, j'ai un Up stable à 10, un Dl stable à 10 (pour la session) donc tout va bien
et le cache a l'air d'etre en partie rempli, mais je ne sais pas si il upload ou pas, comment peut-on voir çà?

Kan un chunk est terminé , il est mis en partage et tu peux voir dans ton onglet transferts "cache" dans la partie ul , sinon tu as aussi les stats.... Sinon je vous annonce que je vais bientot mettre en ligne la meme version mais sous emule0.30b..... je posterais à cette occasion

@bile666:

Je remarque que concernant ce fameux fichier, tu es toujours en attente d'un chunk (chez moi et chez au moins une bonne centaine d'autres personnes).

Je ne sais pas pour les autres, mais...

Ne téléchargeant actuellement qu'un fichier (celui-ci) et ayant très peu de fichiers en upload, ma file d'attente est très réduite (entre 20 et 40 utilisateurs). Mon upload étant à 12 ko, les gens passent environ après 1 à 3 heures d'attente dans la file du même nom.

Cependant, après environ 24 heures, je remarque que tu n'as toujours pas obtenu ce chunk (ni chez moi, ni chez quelqu'un d'autre).

Tout ceci ne me paraît pas très normal. Je viens d'activer le log complet pour essayer de voir quelquechose.

EDIT:
Oui je viens de voir passer cela :
04/10/2003 14:30:46: bile666 nolistsrv|¤ÇhÞ\Ìlìf: Upload session ended due to a canceled transfer.
Et hop, de retour dans la file d'attente. Cela peut durer longtemps... :-P

J'ai ul la version 0.30b de cette beta , elle est tjs soumise à la chartre .
Lien

sabel , si tu pouvais etre plus clair ca m'aiderais

Je ne demande que cela ! :-)

Je ne sais pas si tu as lu mes 3 posts précédents, mais il semblerait que ma Mule ait une "incompatibilité" de caractère avec la version beta d'eChanblard en cours de test au moins avec bile666.

Qu'est-ce que je peut te fournir comme infos pour faire avancer les choses ?

Actuellement, toutes les deux heures environ, bile666 passe en "connexion" après une attente dans ma file d'attente et se fait sortir immédiatement (avec un retour en file d'attente):

04/10/2003 14:30:46: bile666 nolistsrv|¤ÇhÞ\Ìlìf: Upload session ended due to a canceled transfer.
04/10/2003 16:07:04: bile666 nolistsrv|¤ÇhÞ\Ìlìf: Upload session ended due to a canceled transfer.

N'hésite pas à me demander toutes les infos dont tu as besoin... :-)

Bon, désolé, mais bile666 ayant acquis (mystérieusement ?) le seul chunk que je pouvais lui fournir, je n'ai plus vraiment d'infos à fournir.

Je supppose que cette correction est liée au passage à la nouvelle version (??), car depuis quelques temps:
- le "petit" nom derrière le caractère "|" change constamment
- je reçois régulièrement des tags inconnus (0xff - liés à la fonctionnalité cache je suppose ?).

Nouvel extrait de mon log:
04/10/2003 17:22:30: Process: Unknown eMule tag: 0xff, Intvalue: 1 Stringvalue: User: bile666 nolistsrv|¤ÇhÞ\Ìlìf(eMule v0.30 [eChanblardv3.2])
04/10/2003 17:38:07: Process: Unknown eMule tag: 0xff, Intvalue: 1 Stringvalue: User: bile666 nolistsrv|ðÉc…·™£8(eMule v0.30 [eChanblardv3.2])
04/10/2003 17:38:08: bile666 nolistsrv|?nºê¶+JŸÄ: Upload session ended due to a canceled transfer.
04/10/2003 17:49:10: Process: Unknown eMule tag: 0xff, Intvalue: 1 Stringvalue: User: bile666 nolistsrv|DiÄ„Ä…ä–(eMule v0.30 [eChanblardv3.2])
04/10/2003 17:56:19: Process: Unknown eMule tag: 0xff, Intvalue: 1 Stringvalue: User: bile666 nolistsrv|úR¢ùzƒŸ¥(eMule v0.30 [eChanblardv3.2])
04/10/2003 18:05:51: Process: Unknown eMule tag: 0xff, Intvalue: 1 Stringvalue: User: bile666 nolistsrv|úR¢ùzƒŸ¥(eMule v0.30 [eChanblardv3.2])


Bon , j'arrête le log pour le moment.

04.10.2003 18:56:58: Unknown exception in CClientReqSocket::PacketReceived; IP=80.139.202.62 protocol=0xc5 opcode=0x81 size=16
04.10.2003 18:56:58: Structured exception c0000005 in CClientReqSocket::PacketReceived at 0043e563
04.10.2003 18:58:29: Unknown exception in CClientReqSocket::PacketReceived; IP=80.13.209.182 protocol=0xc5 opcode=0x81 size=16
04.10.2003 18:58:29: Structured exception c0000005 in CClientReqSocket::PacketReceived at 0043e563
04.10.2003 18:58:30: Unknown exception in CClientReqSocket::PacketReceived; IP=80.13.209.182 protocol=0xc5 opcode=0x81 size=16
04.10.2003 18:58:30: Structured exception c0000005 in CClientReqSocket::PacketReceived at 0043e563
04.10.2003 18:58:31: Unknown exception in CClientReqSocket::PacketReceived; IP=80.13.209.182 protocol=0xc5 opcode=0x81 size=16
04.10.2003 18:58:31: Structured exception c0000005 in CClientReqSocket::PacketReceived at 0043e563
04.10.2003 18:58:31: Unknown exception in CClientReqSocket::PacketReceived; IP=80.13.209.182 protocol=0xc5 opcode=0x81 size=16
04.10.2003 18:58:31: Structured exception c0000005 in CClientReqSocket::PacketReceived at 0043e563

J'ai bcp d'erreurs comme ca de mon coté.

Si vous aviez installé une précédente version de cette béta (la dernière date d'aujourd'hui 18h00) vous devez avant d'exécuter la mule supprimer le cache (qui est dans le rép temp).