Author: bpoussin Date: 2010-10-15 16:40:35 +0200 (Fri, 15 Oct 2010) New Revision: 414 Url: http://nuiton.org/repositories/revision/wikitty/414 Log: add section about remote notification Modified: trunk/src/site/rst/Spec.rst Modified: trunk/src/site/rst/Spec.rst =================================================================== --- trunk/src/site/rst/Spec.rst 2010-10-15 12:02:05 UTC (rev 413) +++ trunk/src/site/rst/Spec.rst 2010-10-15 14:40:35 UTC (rev 414) @@ -40,6 +40,74 @@ Un wikitty en base a toujours un identifiant, dès instanciation. +WikittyServiceNotifier +====================== + +Tous les events passant par le WikittyServiceNotifier sont envoyé au +RemoteNotifier s'il est indiqué dans la configuration qu'il faut envoyer les +events (wikitty.service.event.propagateEvent). Il faut alors dans ce cas +définir le transporter à utiliser (wikitty.notifier.transporter.class). + +Le transporter sert à envoyer(serveur) et recevoir(client) les events. Le +même transporter doit être utilisé pour le client et le serveur. + +Il existe aujourd'hui deux types de transporter différent (jgroups, xmpp). +L'implantation jgroups pose quelque soucis (ne fonctionne pas toujours). Il +est donc préférable d'utiliser le transporter xmpp. + +Il est bien sur possible d'empiler deux couche de WikittyServiceNotifier +avec des transporters différents coté serveur pour permettre à différent +type de client de fonctionner en même temps (FIXME poussin 20101115 il n'est +pas actuellement possible de configurer ce fonctionnement) + +Pour utiliser le transporter xmpp il faut que vous ayez un serveur xmpp avec +une room acceptant le login anonyme. Pour cette fonctionnalité, il n'y a pas +besoin que la room soit archivée. + +Synchronisation de serveur +========================== + +On peut avoir besoin d'avoir deux serveurs qui soit synchronisé. +Actuellement il n'existe que du maitre/esclave. + +Pour mettre en place la synchronisation il faut que le serveur maitre +utilise la couche de notification avec le transporter xmpp. Il faut que la +room xmpp soit archivée. + +Pour que la synchornisation fonctionne il faut: +- garantir que tous les events soient bien envoyés +- garantir que tous les events soitent bien reçus + +et ceci même si le serveur xmpp s'arrête ou que le client s'arrête. Si le +serveur s'arrête plus aucun event ne sera produit. Il faut seulement +garantir que lorsqu'un event à été enregistrer sur le serveur il sera bien +envoyé aux clients. + +Lorsque le serveur envoie un event, il lui fixe un numero d'ordre qu'il +stocke et qu'il incrémentera et réutilisera pour l'envoi suivant. + +Lorsque le client réceptionne l'event, il vérifie qu'il n'y a pas de rupture +dans la séquence des numeros d'envois. Si c'est le cas, il doit récupérer +les numeros manquants. (il redemande l'historique des messages pour les N +messages qui lui manque) + + + + + + +Deux types de client: +- volatile: ceux intéressé pour récupérer les events lorsqu'ils sont présent +- persistant: ceux intéressé pour récupérer tous les events même lorsqu'ils sont non dispo (coupure réseau) + +Le client ouvre un socket et le serveur laisse la connexion ouverte pour pouvoir +envoyer régulièrement les infos de notification. +Si un client volatile disparait (impossible de lui envoyer l'info), on +l'enleve de la liste des clients a prevenir +Si un client persistant disparait, on met dans une file toutes les +notifications qu'on a pas pu lui envoyer et on lui renvera tout ce qu'il a +manqué lorsqu'il sera de retour. (utile pour la synchro serveur) + Gestion des droits ==================