Dans le cadre des travaux sur l'
Vu le contexte très spécial, les protocoles classiques de
distribution d'information ne convenaient pas forcément à ce type de
réseau, où il est crucial d'économiser l'énergie, et de fonctionner
malgré des liaisons physiques
sommaires. Trickle atteint ces
objectifs en ne diffusant l'information que lorsque elle a
changé. L'idée de base est de permettre à deux nœuds de
déterminer très rapidement s'ils ont la même version de l'information
distribuée et, sinon, de se synchroniser. S'ils sont synchronisés, il
n'y a plus beaucoup de communication. Lorsque de la nouvelle
information apparait, le trafic reprend. Trickle repose entièrement
sur les mécanismes de
Trickle est un algorithme générique : conçu à l'origine pour distribuer du code (pour mettre à jour le programme sur les autres machines), il a pu être adapté pour distribuer n'importe quel type d'information, par exemple une table de routage. Pour un nouveau type d'information, il suffit de définir ce que veut dire « être synchrone » ou pas et la partie générique de Trickle fait le reste.
Assez de publicité, place à l'algorithme (sections 3 e 4 du RFC). Le
travail de chaque nœud est de transmettre les données qu'il
connait jusqu'à ce que, en entendant les autres nœuds, il se
rende compte que ses transmissions sont inutiles (cela veut dire qu'un
nœud Trickle isolé continuera à parler tout seul). Pour prendre
l'exemple du protocole CTP (
La transmission se fait à une adresse
Lorsqu'un nœud reçoit les messages d'un autre, il y a deux
cas :
Pour décider ensuite de l'action exacte à entreprendre, les
nœuds Trickle ont besoin de quelques paramètres :
Ça, c'était l'algorithme. Simple, non ? Maintenant, si vous êtes
concepteur de protocoles et que vous voulez utiliser Trickle, que vous
reste-t-il à faire ? La section 5 liste vos tâches :
Il ne faut quand même pas oublier quelques considérations pratiques (section 6). D'abord, le bon fonctionnement de Trickle dépend d'un accord de tous les nœuds sur les paramètres à utiliser. En cas de différence, le résultat peut être sous-optimal voire faux dans certains cas. Par exemple, un nœud qui aurait une constante de redondance k supérieure aux autres pourrait se retrouver à émettre à chaque intervalle, vidant sa batterie. De même, un désaccord sur Imax pourrait mener certains nœuds à ne jamais transmettre, laissant les autres faire tout le travail. En outre, toutes les valeurs ne sont pas forcément raisonnables. Par exemple, la constante de redondance k mise à l'infini est théoriquement possible (Trickle travaillerait alors en mode bavard, n'économisant pas les transmissions) mais très déconseillée. Il faut donc trouver un moyen de distribuer la bonne configuration à toutes les machines.
Le pire problème serait évidemment une fonction de définition de la cohérence différente selon les nœuds, cela pourrait mener à une impossibilité de converger vers un état commun. C'est pour cela que le RFC demande qu'elle soit strictement définie pour un protocole donné, et non configurable.
L'auteur de protocole, ou le programmeur, pourraient vouloir « améliorer » Trickle en ajustant l'algorithme. Attention, avertit le RFC, cet algorithme a été soigneusement étudié et testé et la probabilité d'arriver à l'améliorer est faible. Il est conseillé de ne pas le toucher gratuitement. Trickle est extrêmement simple et la plupart des améliorations mèneraient à un code plus compliqué. Or, pour le genre de machines pour lesquelles Trickle est prévu, économiser en transmissions de paquets pour finir par faire davantage de calculs ne serait pas forcément optimal.
Enfin, question sécurité, c'est simple, Trickle n'en a pas (section 9). Un méchant peut facilement pousser tous les nœuds à transmettre, épuisant leurs ressources. Et il peut assez facilement empêcher le groupe de converger vers un état stable. Les protocoles qui utilisent Trickle doivent donc définir leurs propres mécanismes de sécurité.
Pour approfondir Trickle, notamment sur ses performances ou son
implémentation, les articles recommandés sont «
Plusieurs utilisations de Trickle sont mentionnées en section 6.8,
avec références. Trickle est par exemple utilisé dans
« Dans les travaux qui parlent de Trickle, on voit souvent cité Maté, une sorte d'environnement
qui permet de mettre en réseau des mini-machines virtuelles (si j'ai
bien compris), et certains documents indiquent que Maté contient une
implantation de Trickle.
Maté est distribué principalement sous forme de
« Par recoupements (c'est assez rare d'avoir à autant jouer les détectives
entre fichiers RPM, confusion sur les versions et vieux dépôts
dw@brouette:/storage/sandbox/tinyos-1.x$ ack -ai trickle
tos/lib/VM/components/MVirus.nc
118: MateTrickleTimer versionTimer;
119: MateTrickleTimer capsuleTimer;
153: void newCounter(MateTrickleTimer* timer) {
tos/lib/VM/doc/tex/mate-manual.tex
615:that has newer code will broadcast it to local neighbors. The Trickle
635:Trickle's suppression operates on each type of packet (version,
645:\subsubsection{Trickle: The Code Propagation Algorithm}
647:The Trickle algoithm uses broadcast-based suppressions to quickly
651:completes, Trickle doubles the size of an interval, up to
662:Trickle maintains a redundancy constant $k$ and a counter
tos/lib/VM/types/Mate.h
168:typedef struct MateTrickleTimer {
173:} MateTrickleTimer;
tools/java/net/tinyos/script/VMFileGenerator.java
524: writer.println(" * MVirus uses the Trickle algorithm for code propagation and maintenance.");
528: writer.println(" * \"Trickle: A Self-Regulating Algorithm for Code Propagation and Maintenance");
549: writer.println(" the timer interval for Trickle suppression, and the redundancy constant");
Cela donne donc des pistes, la partie principale semblant bien être le fichier