Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Ève

RFC 5352: Aggregate Server Access Protocol (ASAP)

Date de publication du RFC : Septembre 2008
Auteur(s) du RFC : R. Stewart, Q. Xie, M. Stillman (Nokia), M. Tuexen (Muenster University of Applied Sciences)
Expérimental
Réalisé dans le cadre du groupe de travail IETF rserpool
Première rédaction de cet article le 30 septembre 2008


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.


Téléchargez le RFC 5352

Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)

Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)