Ne pas invoquer simultanément deux rc5des, surtout s'ils emploient les
mêmes fichiers de données. Certains jugent préférable, afin d'éliminer tout
risque, de ne jamais démarrer le client que via un script commençant par un
killall rc5des, suivi d'une temporisation destinée à lui laisser
le temps de sauvegarder son contexte de travail, et enfin du démarrage
proprement dit. On pourra, pour ce faire, utiliser le script de la section
précédente.
Lorsque le client ne parvient pas à contacter de serveur il sélectionne des blocs au hasard et risque donc de travailler inutilement (en traitant des blocs déjà pris en charge par un autre client). Il faut donc éviter cela. Surveiller le fichier historique (rc5des.log) afin de peaufiner les paramètres 1/2 et 1/3 de façon à ne pas conserver trop de blocs dans les tampons (buffers) car les serveurs ne les allouent pas définitivement (ils les réallouent, à défaut de réponse, après un délai).
Pour stopper le client : kill son-PID (ou bien killall
rc5des).
On pourra aussi optimiser : explorer pour cela le document du
relevé d'activité des mandataires afin d'utiliser le
plus proche (au sens réseau, c'est-à-dire grâce à un examen préalable
réalisé par traceroute).
Avec certaines machines distantes ne pas oublier de le lancer par nohup
rc5des&. Utiliser en ce cas, si nécessaire, tail -c 0 -f
nohup.out pour examiner ses sorties.
À intervalles réguliers on pourra mettre à jour le client afin de profiter de versions de plus en plus optimisées.