L’idée du protocole CorDis est de disséminer des correspondances dans le système afin de partager les correspondances connues par certains pairs mais ignorées par d’autres. Le but est de diminuer l’hétérogénéité du système liée aux disparités entre les pairs.
Lorsque le processus démarre, chaque pair p connaît des correspon- dances. Il les conserve durant toute sa présence dans le système. Parmi les correspondances connues par un pair, un certain nombre impliquent sa propre ontologie. Nous introduisons la notion d’op-correspondances.
Définition 6.1 Étant donné un pair p, les op-correspondances sont l’ensemble des corres-
pondances connues par p et impliquant son ontologie :
{hid, e, e′, r, ni ∈κ(p): e ∈µ(p) ∨e′ ∈µ(p)}
Le but de disséminer des correspondances est de permettre à des pairs d’apprendre de nouvelles correspondances éventuellement utiles pour traduire les requêtes qu’ils reçoivent. Dans ce travail, nous disséminons les correspondances à l’aide d’un protocole épidémique (cf. section 2.3, page 40) : chaque pair p initie de manière régulière un échange avec un autre pair p′. Chacun d’eux sélectionne et envoie des correspondances à l’autre. Les pairs doivent être capables d’accomplir trois tâches :
1. la sélection aléatoire d’un pair dans le système, 2. la sélection de correspondances à envoyer, 3. le traitement de correspondances reçues.
Nous considérons que la première tâche est réalisée par un service ex- terne, comme par exemple le service d’échantillonnage de pairs (peer sam- pling service) présenté dans [JGKvS04]. Les algorithmes 3 et 4 présentent les instructions effectuées par le thread actif et le thread passif. Ils sont iden- tiques aux algorithmes des protocoles épidémiques classiques présentés en page 41. Les fonctions de sélection de correspondances (selectCorres- pondencesToSend) et de traitement des correspondances (storeCorrespon- dences) sont décrites en détail dans les sections 6.2.2 et 6.2.3. Avant de les présenter nous montrons comment les correspondances sont stockées lo- calement par les pairs.
6.2.1 Stockage des correspondances
Chaque pair doit stocker les correspondances dont il a connaissance dans un cache de taille limitée afin de ne pas stocker toutes les correspon- dances. Le choix des correspondances à conserver est fait à l’aide d’une fonction de score qui permet d’ordonner les correspondances : seules les
Algorithme 3 : Thread actif d’un pair p. while true do
1
p′ ←selectPeer() ;
2
// Sélection des correspondances à envoyer : corrs←selectCorrespondencesToSend() ; 3 sendTo(p′, corrs) ; 4 corrs′ ←receiveFrom(p′) ; 5
// Traitement des correspondances reçues : storeCorrespondences(corrs′) ;
6
wait(θ) ; // θ : délai entre deux cycles.
7
Algorithme 4 : Thread passif d’un pair p′ corrs←receiveFromAny() ;
1
// Sélection des correspondances à envoyer : corrs′ ←selectCorrespondencesToSend() ;
2
sendTo(p, corrs′) ;
3
// Traitement des correspondances reçues : storeCorrespondences(corrs) ;
4
meilleures sont gardées. En théorie, la fonction de score peut être spéci- fique à chaque pair. Dans ce travail, nous considérons qu’ils utilisent tous un historique des requêtes reçues pour déterminer le score de chaque cor- respondance.
Un historique de requêtes est composé de deux listes : L1 et L2. La
liste L1 contient les entités utilisées dans les k dernières requêtes reçues.
La liste L2contient quant à elle les ontologies utilisées pour exprimer les
k′ dernières requêtes. Notons qu’un élément peut apparaître plusieurs fois dans une liste s’il a été utilisé plusieurs fois dans les dernières requêtes.
Exemple 6.1 Après qu’un pair p a successivement reçu les requêtes q1, q2, q3 et q4
respectivement exprimées avec des entités des ontologies o1, o3, o1 et o2
telles que :
– q1 est composée de e1,
– q2 est composée de e3,
– q3 est composée de e′1et e′′1,
– q4 est composée de e2,
son historique est composé des listes L1= [e1, e3, e1′, e′′1, e2]
etL2 = [o1, o3, o1, o1, o2].
Intuitivement, la fonction de score permet aux pairs de favoriser les correspondances pouvant être utiles (localement ou pour d’autres pairs) pour traduire des requêtes. Par ailleurs l’historique de requêtes reflète dans une certaine mesure les intérêts des pairs. Il est donc préférable de favoriser les correspondances fréquemment utilisées.
Définition 6.2 Étant donné un ensemble de correspondancesC, nous définissons la fonc- tion de score sc :C → [0, 1]par :
où c = hid, e, e′, r, ni (e et e′ sont des entités de o et o′), et f donne la fréquence d’apparition d’un élément dans une liste.
Le coefficient ω ∈ [0, 1] est utilisé pour donner plus ou moins d’im- portance à une correspondance impliquant des entités qui n’apparaissent pas dans des requêtes récentes mais qui appartiennent à des ontologies utilisées récemment. Par défaut il peut être fixé à 0, 5.
Exemple 6.2 En considérant l’historique de requêtes présenté dans l’exemple 6.1, et en posant ω = 0, 5, le score de la correspondance hid, e1, e2′′′, r, ni (telle
que e1∈ o1 et e′′′2 ∈ o2) est :
sc(hid, e1, e2′′′, r, ni) = 0, 5· [f(e1,L1) + f(e′′′2 ,L1) + f(o1,L2) + f(o2,L2)]
= 0, 5· [0, 2+0+0, 6+0, 2] =0, 5
Si de nouvelles requêtes sont reçues, alors les scores des correspon- dances changent, donnant plus d’importance aux correspondances perti- nentes. Les scores des correspondances sont calculés régulièrement afin de prendre en compte la dynamicité.
Les correspondances impliquant l’ontologie d’un pair p (c.-à-d. les op-
correspondances) sont d’une importance cruciale pour ce pair car elles vont lui permettre de traduire les requêtes qu’il reçoit. Nous proposons d’en stocker autant que possible (toutes si possible) dans un dépôt. Le cache, distinct de ce dépôt, est dédié au stockage des autres correspon- dances. Si le dépôt (ou le cache) est trop petit pour stocker toutes les cor- respondances, le pair peut utiliser la fonction de score pour en éliminer certaines. Nous utilisons les notations repository(p)et cache(p)pour faire référence au dépôt et au cache du pair p. Ils sont respectivement limités à rmax et cmaxéléments.
6.2.2 Sélection des correspondances
Quand un pair doit envoyer des correspondances, il les sélectionne depuis le dépôt et le cache. Pour éviter de surcharger le réseau, nous limitons le volume d’information échangé : au plus mmax correspon-
dances sont sélectionnées et envoyées. Par ailleurs nous introduisons la va- riable π∈ [0, 1]pour représenter le ratio de correspondances sélectionnées dans chaque ensemble (par défaut elle peut être fixé à 0, 5). Ainsi, un pair sélectionne[π·mmax] correspondances dans son dépôt et[(1−π) ·mmax]
dans son cache. L’algorithme 5 explicite ce processus. Une sélection aléa- toire et uniforme est effectuée afin d’assurer que deux correspondances du dépôt (ou du cache) ont la même probabilité d’être envoyées (cf. algo- rithme 5, lignes 2 et 4).
6.2.3 Traitement des correspondances
Quand un pair p reçoit un message, il exécute deux tâches. Premiè- rement il stocke localement les correspondances contenues dans le mes- sage : les op-correspondances sont placées dans repository(p)et les autres
dans cache(p) (cf. algorithme 6, lignes 1 à 5). Deuxièmement il élimine certaines correspondances de son dépôt (si besoin) en conservant les rmax
Algorithme 5 : Fonction selectCorrespondencesToSend()
// Sélection des correspondances par un pair p Output : ensemble des correspondances à envoyer à un pair p′. r←π·mmax; 1 msg←selectRandomly(repository(p), r) ; 2 c← (1−π) ·mmax ; 3 msg←msg ∪selectRandomly(cache(p), c) ; 4 return msg ; 5
le cache (cf. algorithme 6, ligne 7). Pour cela la fonction de score est utili- sée.
Algorithme 6 : Fonction storeCorrespondences(corrs) Input : Un ensemble corrs de correspondances.
// Les correspondances sont ajoutées dans le dépôt ou dans le cache.
for c= hid, e, e′, r, ni ∈corrs do
1
if e∈µ(p) ∨e′ ∈ µ(p)then
2
// Si c est une op-correspondance repository(p) ←repository(p) ∪ {c}; 3 else 4 cache(p) ←cache(p) ∪ {c}; 5
// Limitation de la taille du dépôt et du cache. // rmax et cmax sont des paramètres d’application. if|repository(p)| >rmaxthen
6
sort(repository(p), sc) ; // sc est la fonction de score
7
repository(p) ←keepBest(repository(p), rmax) ;
8
if|cache(p)| >cmaxthen
9
sort(cache(p), sc) ;
10
cache(p) ←keepBest(cache(p), cmax) ;
11