Mon blog

Membre de la famille Rserpool (décrite dans le RFC 5351, ASAP (Aggregate Server Access Protocol) est le protocole de communication entre un client (le PU, pour Pool User) et le serveur ENRP (RFC 5353), ainsi qu'entre un élément du groupe de serveurs d'application (le PE pour Pool Element) et le serveur ENRP. ASAP permet aux PE de s'enregistrer auprès du serveur ENRP et aux PU de trouver l'adresse d'un PE avec lequel ils vont travailler.

Le groupe de serveurs de l'application, le pool, est identifié par un handle nommé PH (pool handle). ASAP permettra de résoudre cet handle en une ou plusieurs adresses IP. Le fait d'interposer cet intermédiaire entre le client et le serveur de l'application permet d'assurer des fonctions de répartition de charge ou de résistance aux pannes. Comme le rappelle la section 1.3, un handle n'a qu'une signification locale à une organisation, il ne prétend pas être unique pour tout l'Internet.

Les deux fonctions essentielles d'ASAP sont donc :

• Pour un PE, un des serveurs de l'application, de signaler sa disponibilité (message ASAP_REGISTRATION, section 2.2.1),
• Pour un PU, un client final, de trouver l'adresse IP d'un ou plusieurs serveurs du groupe, afin de le contacter (message ASAP_HANDLE_RESOLUTION, section 2.2.5).

ENRP, quant à lui (RFC 5353), est utilisé entre les serveurs ENRP, pour assurer leur synchronisation.

Une façon simple de décrire ce que fournit ASAP est de lire la section 6 qui décrit, en pseudo-code, les primitives d'ASAP. Par exemple, l'enregistrement d'un serveur dans le groupe est (section 6.1) :

         
Format: registration.request(poolHandle,
                             User Transport parameter(s))

La section 2 détaille le format des messages que portera ASAP. Le format de base est défini dans le RFC 5354. Ainsi, ASAP_REGISTRATION (section 2.2.1) porte le handle du groupe que le PE veut rejoindre. La réponse, ASAP_REGISTRATION_RESPONSE (section 2.2.3) comprendra un champ Reject qui, mis à 1, indiquera l'échec éventuel (un 0 signifiant le succès).

L'autre message important est ASAP_HANDLE_RESOLUTION (section 2.2.5) et sa réponse, ASAP_HANDLE_RESOLUTION_RESPONSE. Le premier permet de résoudre un handle en une adresse IP (ou une liste d'adresses IP, pour donner du choix au client, et lui permettre d'essayer d'autres serveurs en cas de défaillance, voir par exemple la section 6.8.1 et le RFC 5356).

Le principal protocole de transport utilisé par ASAP (sections 2.1 et 5) n'est pas TCP mais SCTP (RFC 4960), entre autres parce qu'il fournit déjà une certaine résistance aux pannes (plusieurs adresses IP peuvent être utilisées pour la même association). Le port par défaut est 3863 (3864 avec TLS). Notons qu'ASAP n'est pas purement requête-réponse : le serveur ENRP peut envoyer des messages non sollicités, par exemple si un pool change.

Il existe une implémentation d'ASAP en logiciel libre dans rsplib.