Protocoles de communication Service Broker

S’applique à : SQL Server Azure SQL Managed Instance

Service Broker utilise un protocole propre 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 pouvoir envoyer du trafic TCP/IP sur le port utilisé par l’autre instance pour les communications Service Broker. Par convention, Service Broker utilise souvent le port 4022 pour les communications broker à broker. Toutefois, le port exact est spécifié à la création du point de terminaison.

Couches de protocole

Service Broker utilise une approche en couches pour la communication. 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 génère des numéros de séquence pour les messages, génère des messages d’accusé de réception, remet les messages aux files d’attente appropriées, et 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 traite les tâches nécessaires pour assurer une remise fiable, notamment la génération et le traitement des messages d’accusé de réception.

Chaque côté d’une conversation est un point de terminaison dans la couche de protocole de dialogue. La vue de catalogue sys.conversation_endpoints montre 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 de protocole de broker adjacente traite le mécanisme de communication entre deux instances SQL Server. Cette couche encode 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 est un point de terminaison dans la couche de protocole adjacente. La vue de gestion dynamique sys.dm_broker_connections montre des informations sur les connexions réseau Service Broker. Service Broker gère la connexion réseau pendant l’échange actif des messages. Service Broker ferme la connexion réseau quand aucun message n’est envoyé ou reçu sur la connexion réseau pendant un instant.

Protocole de transfert

La couche du protocole de transport gère la transmission réseau réelle. Cette couche est extérieure à Service Broker. Par exemple, les messages adressé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 des options pour le protocole de transport. SQL Server ne contient pas de points de terminaison Service Broker par défaut. Pour plus d’informations sur la création d’un point de terminaison Service Broker, consultez Guide pratique pour activer le réseau Service Broker (Transact-SQL).

Traitement des messages Service Broker

Service Broker utilise deux catégories distinctes de message. 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 des messages séquencés pour tous les types de message 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 qui a le plus petit numéro de séquence. Service Broker utilise également le numéro de séquence de message pour détecter les messages en double. 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 des messages non séquencés pour les messages d’accusé de réception dédiés et les messages d’erreur créés par Service Broker. Service Broker ne prend aucune précaution particulière pour remettre un message non séquencé. Notez, toutefois, 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 divise les messages sortants en fragments et combine les fragments entrants pour former le message d’origine. Un message entier est contenu dans un seul fragment lorsqu'il est de petite taille, Pour les grands messages, Service Broker crée plusieurs fragments.

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). Si un fragment du message est perdu, le protocole retransmet uniquement un fragment plutôt que le message en entier. La fragmentation des messages peut aussi réduire le délai pour qu’un petit message atteigne la destination. Service Broker peut envoyer un fragment qui contient un petit message complet entre les fragments d’un grand message. 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. Si celle-ci n'est pas disponible, il est stocké dans la file d'attente de transmission. Une application ne peut pas réceptionner un message partiellement reconstitué. 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 du message

Service Broker accuse réception de chaque message reçu. Un accusé de réception peut notifier la réception d’un ou de plusieurs fragments de message. Si possible, l’accusé de réception est ajouté à l’en-tête d’un message renvoyé dans 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é. L’accusé de réception des messages est entièrement traité par Service Broker, une application qui utilise Service Broker ne reçoit pas ces messages.

L'expéditeur conserve les fragments de message pour lesquels le destinataire n'a pas accusé réception. Si aucun accusé de réception n’est reçu dans le délai d’attente défini par le système, l’expéditeur renvoie le fragment de message. Si aucun accusé de réception n’est reçu pendant le délai d’attente, Service Broker augmente ce délai de façon exponentielle (jusqu’à une valeur maximale) avant la prochaine tentative. La durée d'attente initiale entre deux tentatives est de quelques secondes mais elle peut atteindre une minute environ. Notez que ce délai d’attente est volontairement imprécis. En fonction du trafic réseau et des autres activités de l’instance SQL Server, un fragment de message peut ne pas être renvoyé pendant quelques secondes après l’expiration du délai d’attente.

Si un accusé de réception est perdu ou retardé, le destinataire peut 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 de message pour assurer une messagerie fiable sans transactions distribuées. 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. 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 que Service Broker utilise pour transmettre les messages comprend une vérification d’intégrité du message pour déterminer si un message donné a été endommagé ou modifié pendant le transport.

La vérification d’intégrité du message est une signature MD5 du contenu du message. SQL Server chiffre la signature avec la clé de session du message et ajoute la signature dans l’en-tête du message.

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 échoue à la vérification d’intégrité. SQL Server ignore le message et n’envoie pas d’accusé de réception à l’expéditeur. La classe d’événements Broker:Corrupted Message rapporte des informations quand un message échoue à la vérification d’intégrité.

Objets de transmission de Service Broker

Un objet de transmission Service Broker est un objet en mémoire qui gère et enregistre l’état des transmissions de message pour un dialogue. Chaque point de terminaison de conversation a un objet de transmission.

Un dialogue demande un objet de transmission lorsqu'il effectue les opérations suivantes :

• Envoi d'un message par le biais de la file d'attente de transmission. Notamment :

  • Tous les messages envoyés à une instance distante du moteur de base de données

  • Messages envoyés aux files d'attente dans l'instance locale si le message ne peut pas être inséré directement dans la file d'attente de destination

• Réception d'un message distant ou d'un message qui provient d'une file d'attente de transmission locale.

Un objet de transmission est créé la première fois qu’un dialogue en demande un. Service Broker utilise le même objet de transmission pour les demandes suivantes de cette boîte de dialogue. Les objets de transmission sont modifiés chaque fois que Service Broker doit enregistrer un changement d’état des transmissions pour le dialogue. La taille des objets de transmission est d'environ 1 Ko.

Pour libérer de la mémoire, Service Broker stocke périodiquement des lots d’objets de transmission inactifs dans des tables de travail tempdb. Lorsqu'un objet de transmission est d'abord modifié dans la mémoire, il est marqué comme modifié. Il reste marqué comme modifié jusqu'à ce qu'il soit vidé sur une table de travail.

Les objets de transmission ne sont pas utilisés pour l'envoi ou la réception de messages locaux qui peuvent être insérés directement dans la file d'attente de destination.

Flux des communications réseau

L’illustration suivante présente une vue générale des communications réseau Service Broker entre deux instances SQL Server.

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.

Les connexions réseau se produisent entre deux points de terminaison Service Broker. et utilisent le protocole TCP/IP. Si la connexion est inactive pendant un instant, SQL Server ferme la connexion réseau.

Pour remettre 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. La file d'attente du service expéditeur n'est pas impliquée dans cette opération. 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).

Voir aussi

• Routage Service Broker