From Ape Wiki

Jump to: navigation, search

Contents

[edit] Protocole APE

[edit] Fonctionnement général

APE fonctionne sur un modèle de "Suscriber/Publisher". Le point centrale de toute souscription est une entité nommée channel.
Chaque utilisateur connecté représente lui aussi une entité.
Chaque entité dispose d'un tuyaux de communication appelé pipe et identifiable par un pubid (Clef de 32 caractères généré pseudo-aléatoirement par le serveur).

Un channel est différent d'un utilisateur par le fait qu'il est identifiable non seulement par un pubid mais aussi par un nom lui étant directement attaché.

[edit] Channels

Un channel est un tuyaux de communication pouvant directement être crée par le serveur ou directement par un utilisateur.
La création d'un channel se fait automatiquement si un utilisateur souscrit à un channel non existant. Le serveur lui répond directement en lui envoyant le pubid du channel. (Permettant donc à l'utilisateur de communiquer via le pipe du channel).
Chaque channel dispose d'une liste de propriétés qui dans le mode de fonctionnement par défaut de APE ne contient que le nom de celui-ci. Des propriétés peuvent être ajoutées via des modules du serveur ou par des entités autorisées.

Un channel dispose de deux modes de fonctionnement :

  • Channel interactif
  • Channel non interactif

Lorsqu'un utilisateur souscrit à un channel interactif déjà existant il reçoit la liste des autres utilisateurs qui ont souscrit à ce channel et peut directement communiquer avec eux via le pipe du channel.
Le tuyaux de communication d'un channel non interactif est en lecture seul, c'est à dire que les utilisateurs n'ont pas connaissance les un des autres et ne peuvent pas communiquer via le channel. Seul d'autre entités en ont le droit (nous y reviendrons plus tard).

La création d'un channel non interactif se fait automatiquement lorsque le premier caractère de son nom est * (étoile).

[edit] Utilisateurs

[edit] Résumé

Lors de la connexion d'un utilisateur un pipe lui est assigné (pour pouvoir communiquer avec les autres entités) ainsi qu'un sessid. Le sessid permet au serveur d'identifier l'utilisateur à chaque commande que celui-ci envoie.
Tout comme les channels un utilisateur a une liste de propriétés mais qui dans le mode de fonctionnement par défaut de APE est vide.

Un utilisateur peut effectuer des commandes qui par défaut lui permettent de :

  • Poster un message sur un pipe (channel ou autre utilisateur)
  • Souscrire à un channel (dit aussi "rejoindre un channel")
  • Désinscrire d'un channel (dit aussi "partir d'un channel")
  • Créer un channel (S'il s'inscrit sur un channel inexistant)


Cependant les modules du serveurs peuvent créer des commandes permettant une infinités d'actions possibles pour un utilisateur.

[edit] Messages queue

Chaque utilisateur connecté dispose d'une file d'attente ou plusieurs (voir multi-tabs, sous-users) de messages en attentes.
Cette file d'attente est vidée (envoyée à l'utilisateur) dans une intervalle (tick) définie par le serveur (généralement tout les 100ms) et empaquetée dans un objet JSON.

[edit] Communiquer avec le serveur

APE est un serveur HTTP écoutant par défaut le port 80.

[edit] Methodes HTTP supportées

  • GET
  • POST

[edit] Format des paramètres

Le serveur reconnait les paramètres passée en "query string" de la manière suivante :

GET /?COMMANDE&param1&param2&paramN&123456789 HTTP/1.1

La liste des paramètres est donc défini dans un ordre bien précis. Il faudra noter que le dernier paramètres (ici 123456789) doit toujours être une chaîne unique (anticache).
Un paramètre supplémentaire peut être ajouté automatiquement en tout premier (voir Utiliser APE avec mod_proxy)

Il est possible de passer ces paramètres en POST et auquel cas le header HTTP 'Content-length' est obligatoire.

[edit] Keep-Alive

Si la requête n'échoue pas, le serveur garde la connexion ouverte avec l'utilisateur jusqu'à ce qu'un message (voir RAW) ou plusieurs messages (empaquetés) lui soit envoyés.
La connexion peut être fermé si le même utilisateur se connecte une deuxième fois via le même sessid ET le même header HTTP Host: (voir multi-tabs, sous-user).

Exemples :
Connexion A :

GET /?CHECK&123456789 HTTP/1.1
Host: 0.ape.ape-project.org
 
[Connexion en attente]

Connexion B :

GET /?CHECK&123456791 HTTP/1.1
Host: 0.ape.ape-project.org
 
[Connexion en attente, mais connexion A est fermée]

Exemples 2  :
Connexion A :

GET /?CHECK&12345678109 HTTP/1.1
Host: 0.ape.ape-project.org
 
[Connexion en attente]

Connexion B :

GET /?CHECK&12345678942 HTTP/1.1
Host: 1.ape.ape-project.org
 
[Connexion en attente, mais connexion A reste ouverte]

A noter que 0.ape.ape-project.org et 1.ape.ape-project.org pointent vers la même IP/Server APE