Protocoles de communication Service Broker
Service Broker utilise un protocole spécifique aux brokers pour communiquer avec des brokers distants. Le broker gère les connexions séparément depuis un pool classique de connexions clientes. Pour que deux instances SQL Server échangent des messages Service Broker, chacune d'elles doit être en mesure d'envoyer un trafic TCP/IP sur le port utilisé par son homologue pour les communications Service Broker. Par convention, Service Broker utilise souvent le port 4022 pour les communications de broker à broker. Toutefois, le port exact est spécifié à la création du point de terminaison.
Couches de protocole
Service Broker opte pour un moyen de communication multi-couches. Chaque couche est élaborée à partir de la couche sous-jacente afin de garantir une remise de messages fiable. Cette solution permet à une application de fonctionner connaître l'emplacement du service distant ou du transport physique que le broker utilise pour communiquer. Dans la majorité des cas, ces protocoles sont transparents pour une application. Malgré tout, la compréhension du rôle joué par chaque couche du protocole peut aider à la résolution d'éventuels problèmes rencontrés avec une application.
Le niveau le plus élevé du protocole utilisé par le broker se nomme le protocole de dialogue. La couche du protocole de dialogue gère la transmission séquencée et fiable des messages. Elle crée automatiquement des numéros de séquence pour les messages, génère les messages d'accusés de réception, remet les messages dans les files d'attente appropriées, enfin fragmente et reconstitue les messages. Le protocole de dialogue gère l'authentification et le chiffrement d'un dialogue.
Ce protocole utilise également le protocole de broker adjacent pour transmettre les fragments de message. Le protocole de broker adjacent gère les transmissions réseau qui sont échangées entre les deux instances de broker.
Le protocole de broker adjacent utilise un protocole de transport, tel que TCP/IP, pour déplacer les messages d'un broker à l'autre.
Protocole de dialogue
Le protocole de dialogue gère le modèle de remise EOIO (Exactly-Once-In-Order) pour les messages d'une conversation. Ce protocole ne décrit pas le format que les messages Service Broker utilisent sur le réseau. Il spécifie plutôt les étapes logiques qui sont requises pour assurer une conversation fiable. Le protocole de dialogue gère les tâches requises pour assurer une remise fiable, notamment la création automatique et le traitement des messages d'accusés de réception.
Chaque partie impliquée dans une conversation constitue un point de terminaison dans la couche du protocole de dialogue. L'affichage catalogue sys.conversation_endpoints permet d'afficher des informations sur les points de terminaison du protocole de dialogue. Un point de terminaison de conversation existe le temps que dure une conversation.
Protocole de broker adjacent
La couche du protocole de broker adjacent gère les aspects pratiques de la communication entre deux instances SQL Server. Cette couche code chaque fragment de message dans un format standard en vue de sa transmission sur le réseau. Contrairement à la couche du protocole de dialogue, la couche du protocole adjacent a connaissance du transport réseau utilisé et adapte les fragments de message en conséquence. En effet, la couche du protocole de broker adjacent fournit une couche d'abstraction entre la couche du protocole de dialogue et la couche du protocole de transport.
Chaque connexion réseau Service Broker constitue un point de terminaison dans la couche du protocole de broker adjacent. La vue de gestion dynamique sys.dm_broker_connections contient des informations sur les connexions réseau Service Broker. Service Broker gère la connexion réseau pendant l'échange actif de messages. Il ferme la connexion réseau lorsqu'aucun message n'a été envoyé ni reçu via cette connexion depuis un court laps de temps.
Protocole de transport
La couche du protocole de transport gère la transmission réseau réelle. Cette couche se situe à l'extérieur de Service Broker. Ainsi, les messages qui sont destinés à un broker s'exécutant dans une autre instance de SQL Server utilisent le protocole TCP/IP comme couche de protocole de transport.
Les points de terminaison Service Broker définissent les options du protocole de transport. Par défaut, SQL Server ne contient aucun point de terminaison Service Broker. Pour plus d'informations sur la création d'un point de terminaison Service Broker, consultez Procédure : activer le réseau Service Broker (Transact-SQL).
Les communications Service Broker
Service Broker utilise deux catégories distinctes de messages. Un message séquencé est un message dont la remise à une application doit être effectuée une seule et unique fois, dans l'ordre défini. Un message non séquencé est un message pouvant être traité immédiatement, sans tenir compte de la séquence suivant laquelle il arrive.
Service Broker utilise les messages séquencés pour tous les types de messages définis par l'utilisateur, les messages de fin de dialogue et les messages d'erreur créés par une application. Chaque message séquencé est pourvu d'un numéro de séquence. L'instance se trouvant à l'origine du message crée un numéro de séquence qu'elle attribue au message. Le broker récepteur du message utilise ce numéro de séquence pour ordonner les messages qu'il présente à une application. Pour un dialogue donné, l'application reçoit toujours en premier le message dont le numéro de séquence est le plus petit. Service Broker utilise également le numéro de séquence du message pour détecter les doublons. Lorsque la couche du protocole de dialogue reçoit deux messages avec des numéros de séquence identiques sur le même dialogue, elle estime qu'il s'agit du même message en double exemplaire et en ignore un.
Service Broker utilise les messages non séquencés pour les messages d'accusés de réception dédiés et les messages d'erreur créés par Service Broker. Il ne prend aucune précaution particulière pour remettre un message non séquencé. Remarquez cependant que Service Broker crée des messages non séquencés en réponse aux messages entrants. Par conséquent, en cas de perte d'un message non séquencé, l'expéditeur effectue une nouvelle tentative avec le message original et le destinataire crée un autre message non séquencé.
Fragmentation des messages
Service Broker scinde les messages sortants en fragments et combine les fragments entrants pour former le message original. Un message entier est contenu dans un seul fragment lorsqu'il est de petite taille, mais Service Broker le fragmente en nombreux morceaux lorsqu'il est volumineux.
La fragmentation des messages présente certains avantages. L'envoi d'un message volumineux en petits fragments améliore la vitesse globale et accroît la fiabilité lorsque la communication s'effectue sur des réseaux relativement lents et peu sûrs tels que les réseaux WAN (Wide-Area Networks). Qu'un fragment de message se perde et le protocole retransmet uniquement le fragment manquant plutôt que le message en entier. La fragmentation des messages volumineux permet également de raccourcir la durée d'acheminement d'un message de petite taille. Service Broker peut envoyer un fragment contenant un message complet de faible taille entre les fragments d'un message volumineux. Cela ralentit légèrement le message de taille importante, afin de diminuer la durée d'attente avant transmission du message de petite taille.
Un message en cours de reconstitution est stocké dans la file d'attente de destination ou dans la file d'attente de transmission de la base de données qui héberge la file d'attente de destination si celle-ci n'est pas disponible. Une application ne peut pas réceptionner un message partiellement reconstitué. La valeur de la colonne status d'un message partiel est définie sur 2 (Désactivé). Cette valeur est également utilisée pour les messages reçus dans le désordre.
Accusé de réception de message
Service Broker accuse réception de chaque message reçu. Un accusé de réception peut notifier l'arrivée d'un ou de plusieurs fragments de message. Lorsque cela est possible, l'accusé de réception est incorporé à l'en-tête d'un message renvoyé sur la même conversation. Si aucun autre message n'est prêt pour l'envoi, Service Broker retourne un message d'accusé de réception dédié. Le processus de notification d'arrivée des messages est géré dans son intégralité par Service Broker, aucune application utilisant Service Broker n'a connaissance de ces messages.
L'expéditeur conserve les fragments de message pour lesquels le destinataire n'a pas accusé réception. Si aucune notification de réception n'est reçue dans le délai imparti par le système, l'expéditeur renvoie les fragments de message concernés. Si aucun accusé n'est réceptionné durant le temps d'attente alloué, Service Broker augmente de façon exponentielle, et jusqu'à sa valeur maximale, le délai d'attente avant la prochaine tentative. La durée d'attente initiale entre deux tentatives est de quelques secondes mais elle peut atteindre une minute environ. Remarquez que ce délai d'attente est volontairement imprécis ; en fonction du trafic réseau et des autres activités en cours dans l'instance SQL Server, un fragment de message peut attendre quelques secondes supplémentaires, après l'expiration du délai d'attente, avant d'effectuer une nouvelle tentative.
Si un accusé de réception est perdu ou retardé, le destinataire peut éventuellement recevoir des messages en double. Dans ce cas, il notifie la réception du doublon, mais ne remet pas le deuxième exemplaire dans la file d'attente.
Service Broker utilise les accusés de réception pour garantir la fiabilité de sa messagerie sans transaction distribuée. Un destinataire envoie un accusé de réception uniquement après avoir ajouté le message ou le fragment de message à la file d'attente. L'expéditeur conserve le message dans la file d'attente de transmission jusqu'à l'arrivée du message d'accusé de réception le concernant. Bien que l'expéditeur et le destinataire ne partagent jamais une transaction, le protocole fournit la garantie que l'expéditeur ne supprime aucun message de la file d'attente de transmission tant qu'il n'a pas été correctement reçu par le destinataire.
Vérification de l'intégrité du message
Le format de transmission des messages utilisé par Service Broker comprend un contrôle d'intégrité afin de déterminer si un message donné a été endommagé ou modifié pendant son acheminement.
La vérification effectuée sur le contenu du message est une signature MD5. SQL Server chiffre la signature au moyen de la clé de session pour le message et l'inclut dans les en-têtes des messages.
Le message arrivé à destination est déchiffré, puis sa signature est comparée à la nouvelle signature calculée sur le contenu réellement reçu. Si les signatures ne correspondent pas, le message a été soit endommagé soit falsifié au cours de la transmission. Le message est refusé au contrôle d'intégrité. SQL Server ignore donc ce message et n'envoie aucun accusé de réception du message à l'expéditeur. La classe d'événements Broker:Corrupted Message fournit des informations sur l'échec du passage au contrôle d'intégrité du message.
Flux des communications réseau
L'illustration ci-dessous présente une vue détaillée des communications réseau Service Broker entre deux instances SQL Server.
.gif "Communication réseau Broker entre deux instances")
Remarquez que la conversation est une connexion logique et permanente. Sa durée n'est pas limitée et elle peut utiliser le nombre de connexions réseau qui lui sont nécessaires le temps de son déroulement.
Ces connexions s'établissent entre deux points de terminaison Service Broker et utilisent le protocole TCP/IP. Si la connexion est demeurée inactive l'espace d'un court laps de temps, SQL Server ferme cette connexion réseau.
Pour assurer la remise d'un message, Service Broker conserve le message dans la file d'attente de transmission de la base de données qui a envoyé le message. Le destinataire remet le message directement dans la file d'attente du service de destination. Si cette file d'attente est désactivée (OFF), le message est conservé temporairement dans la file d'attente de transmission de la base de données réceptrice. Remarquez que la file d'attente du service expéditeur n'est pas impliquée dans cette opération et que la file d'attente de transmission de la base de données hébergeant le service récepteur est concernée uniquement si la file d'attente de destination est désactivée (OFF).