DCTC – Client pour hubs Direct connect

Je rédige cet article dans l’espoir qu’il soit correctement indexé par les moteurs de recherche afin qu’il puisse aider les rares utilisateurs de client Direct Connect en ligne de commande. Car en effet très peu de pages traite du sujet et il faut se débrouiller avec les moyens du bord.

Pour commencer un petit rappel qui contentera et permettra aux néophytes de découvrir le système Direct Connect:

Direct Connect est un protocole de pair-à-pair (P2P) au même rang que le bittorent, relativement plus accès sur l’utilisateur que sur le fichier. Une fois connecté a un hub, vous pourrez pour chaque utilisateur qui y est connecté récupérer sa liste de fichiers partagés et par la suite demander la téléchargement d’un ou de ces fichiers.

Pour en savoir plus, un site français dédié aux client graphique existe: www.directconnect.free.fr

Attaquons maintenant le vif du sujet: le client en ligne de commande. J’ai découvert il y a un moment dctc (sous licence gpl) qui permet de lancer une instance cliente a l’aide de tout plein de paramètres fort utiles.

Les sources sont disponibles: ici.

Pour l’installation, comme dit le fichier INSTALL:

Just do as usual. ./autogen.sh ; make ; make install

Ca ne va pas plus loin.

Je vous renvoie naturellement vers le manuel de dctc (man dctc) une fois celui-ci installé (ou ici). Ceci dit voilà pour exemple une ligne de commande permettant de lancer le client:

dctc -n identifiant -i "comment" -d 5 -a xx.xxx.xxx.xxx -p xxxx -g 127.0.0.1:411 -s /var/share/dcpp

Où:

  • -n: Pseudonyme du client
  • -i: Commentaire
  • -d: Nombre de slots
  • -a: IP a laquelle est accessible votre client
  • -p: Port de communication utilisé par le client
  • -g: Adresse du serveur
  • -s: Répértoire a partager

Avec ça vous aurez de quoi faire tourner un client Direct Connect en ligne de commande.

Pour contrôler ce client vous devrez utiliser la commander dctc_cmd

dctc_cmd unix_udp_socket_path DCTC_command

L’utilisation de dctc_cmd étant un peu complexe, je vous redirige vers le logiciel cccp (Red Connect Console Program) qui rajoute une couche d’abstraction entre dctc et vous.

Un tour sur le manuel de cccp et vous comprendrez rapidement son utilisation.

Si vous rencontre l’erreur suivante lorsque vous tentez de commander dctc:

connect: Connection refused

C’est que le socket utilisé par cccp (ou par vous même lorsque vous utilisez dctc_cmd) n’est pas le bon.
Exemple:

dctc_cmd /home/bux/.dctc/running/dctc-000024D3-127.0.0.1:411 "/FORCEQUIT"

Ici vous devrez pointer sur le bon socket, car si vous avez reçu ce message d’erreur: /home/bux/.dctc/running/dctc-000024D3-127.0.0.1:411 c’est que ce n’est pas le bon.

Dernière chose: La liste des commandes disponibles se trouve dans ce fichier: /usr/share/doc/dctc/tech/commands.gz et si vous cherchez un serveur (hub) Direct Connect en ligne de commande: OpenDCHub

Symfony2 tests: Benchmark de mise en RAM

Après l’article sur la mise en RAM de mysql j’ai effectué quelques tests de performances afin de voir quels sont les gains de performances lorsque l’intégralité des données sont en RAM.

J’ai donc, en plus d’y avoir mysql, placé les fichiers de mon projet dans la ram et exécuter les tests. Les résultats ne sont pas extraordinaire mais en voici le récapitulatif.

Tout sur disque, sans couverture du code:

Time: 02:36, Memory: 195.75Mb

OK (26 tests, 439 assertions)

Tout en RAM, sans couverture du code:

Time: 02:14, Memory: 186.75Mb
 
OK (26 tests, 439 assertions)

Tout sur disque, avec couverture du code:

Time: 22:12, Memory: 196.55Mb

OK (26 tests, 439 assertions)

Tout en RAM, avec couverture du code:

Time: 16:42, Memory: 189.00Mb

OK (26 tests, 439 assertions)

On constate que le gain de performance n’est pas énorme. Cependant il l’est suffisamment pour devenir significatif une fois votre projet très conséquent.

Mettre mysql entièrement en RAM

Mon projet étant maintenant assez avancé pour contenir une série de tests je dois régulièrement lancer la globalité de ces tests pour savoir ou en est la stabilité de mon code. Cependant l’exécution de tous ces tests prend du temps.

Une possibilité d’optimisation est de placer la base de donnée entièrement en ram. Voici donc un petit tutoriel que j’ai trouvé chez Laurent Besson qui vous permettra de mettre mysql en ram.

http://monblog.system-linux.net/blog/2011/08/25/mettre-entierement-mysql-en-ram-grace-a-ramfs-ou-tmpfs/

Attention: Il se peut que vous rencontriez cette erreur (/var/log/mysql/error.log):

InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.InnoDB: File name ./ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.

Sur certaine configurations pensez a vérifier qu’AppArmor est correctement configuré pour permettre le déplacement du datadir de mysql.

Pour cela éditez le fichier /etc/apparmor.d/usr.sbin.mysqld de façon a l’adapter au nouvel emplacement:

# /var/lib/mysql/ r,
# /var/lib/mysql/** rwk,
/var/tmpfs/mysql/ r,
/var/tmpfs/mysql/** rwk,

Dans mon cas, il va également peut-être falloir que je trouve une solution encore plus performante. Pourquoi ne pas mettre le code source de mon application php en ram également ? Je vais regarder ça en tout cas !