Protocolli di comunicazione di Service Broker

Si applica a: SQL Server Istanza gestita di SQL di Azure

Service Broker usa un protocollo specifico per comunicare con i broker remoti. Il broker gestisce le connessioni separatamente dal normale pool di connessioni client. Per lo scambio di messaggi di Service Broker tra due istanze di SQL Server, è necessario che ogni istanza sia in grado di inviare traffico TCP/IP alla porta utilizzata dall'altra istanza per le comunicazioni di Service Broker. Per convenzione, Service Broker utilizza in genere la porta 4022 per le comunicazioni tra broker. Tuttavia, la porta esatta viene specificata quando viene creato l'endpoint.

Livelli di protocollo

Per le comunicazioni, in Service Broker viene adottato un approccio su più livelli. Ogni livello si basa sul livello sottostante per garantire un recapito affidabile. Questo approccio consente a un'applicazione di operare senza conoscere la posizione del servizio remoto o il trasporto fisico utilizzato dal broker per comunicare. Nella maggior parte dei casi, questi protocolli sono trasparenti per un'applicazione. Tuttavia, la comprensione del ruolo svolto da ogni livello di protocollo può contribuire alla risoluzione dei problemi relativi a un'applicazione.

Il protocollo di livello più alto usato dal broker è il protocollo del dialogo. Il livello del protocollo del dialogo gestisce la trasmissione affidabile e sequenziata dei messaggi. Il livello del protocollo di dialogo genera numeri di sequenza per i messaggi, genera messaggi di acknowledgement, recapita i messaggi alle code appropriate e provvede alla frammentazione e al riassemblaggio dei messaggi. Il protocollo del dialogo gestisce l'autenticazione e la crittografia per una finestra di dialogo.

Il protocollo del dialogo usa il protocollo broker adiacente per trasmettere frammenti di messaggio. Il protocollo broker adiacente gestisce le trasmissioni di rete scambiate tra due istanze broker.

Il protocollo broker adiacente usa un protocollo di trasporto, ad esempio TCP/IP, per spostare i messaggi dal broker al broker.

Protocollo del dialogo

Il protocollo del dialogo gestisce il modello di recapito EOIO (Exactly-Once-In-Order) per i messaggi in una conversazione. Questo protocollo non descrive il formato utilizzato dai messaggi di Service Broker in rete, Il protocollo specifica invece i passaggi logici necessari per una conversazione affidabile. Il protocollo di dialogo gestisce le attività necessarie per garantire l'affidabilità del recapito, compresa la generazione e l'elaborazione dei messaggi di acknowledgement.

Ogni lato di una conversazione rappresenta un endpoint nel livello del protocollo di dialogo. Nella vista del catalogo sys.conversation_endpoints sono riportate informazioni sugli endpoint del protocollo di dialogo. Esiste un endpoint di conversazione per la durata della conversazione.

Protocollo broker adiacente

Il livello del protocollo di Service Broker adiacente gestisce i meccanismi di comunicazione tra due istanze di SQL Server. Questo livello codifica ogni frammento di messaggio in un formato standard adatto per la trasmissione in rete. A differenza del livello del protocollo del dialogo, il livello del protocollo adiacente è a conoscenza del trasporto di rete usato e formatta i frammenti di messaggio in modo appropriato. In effetti, il livello del protocollo broker adiacente fornisce un livello di astrazione tra il livello del protocollo di dialogo e il livello del protocollo di trasporto.

Ogni connessione di rete di Service Broker costituisce un endpoint nel livello del protocollo adiacente. La vista a gestione dinamica sys.dm_broker_connections mostra informazioni sulle connessioni di rete di Service Broker. Service Broker mantiene la connessione di rete mentre i messaggi vengono scambiati attivamente. Service Broker chiude la connessione di rete quando per un breve periodo di tempo non sono stati inviati o ricevuti messaggi sulla connessione di rete.

Protocollo di trasporto

Il livello del protocollo di trasporto gestisce la trasmissione di rete effettiva. Questo livello si trova al di fuori di Service Broker. I messaggi destinati a un broker in esecuzione in un'altra istanza di SQL Server, ad esempio, utilizzano il protocollo TCP/IP come livello di protocollo di trasporto.

Gli endpoint di Service Broker impostano le opzioni per il protocollo di trasporto. SQL Server non contiene endpoint di Service Broker per impostazione predefinita. Per altre informazioni sulla creazione di un endpoint di Service Broker, vedere Procedura: Attivare la rete di Service Broker (Transact-SQL).

Elaborazione messaggi di Service Broker

Service Broker utilizza due categorie distinte di messaggi: Un messaggio sequenziato è un messaggio che deve essere recapitato a un'applicazione esattamente una volta, in ordine. Un messaggio non accodato è un messaggio che può essere elaborato immediatamente, indipendentemente dalla sequenza in cui arriva il messaggio.

I messaggi in sequenza vengono utilizzati da Service Broker per tutti i tipi di messaggi definiti dall'utente, i messaggi di fine dialogo e i messaggi di errore generati da un'applicazione. Ogni messaggio sequenziato ha un numero di sequenza. L'istanza che ha origine il messaggio crea il numero di sequenza del messaggio e lo assegna al messaggio. Il broker ricevente usa il numero di sequenza del messaggio per ordinare i messaggi forniti a un'applicazione. Per un determinato dialogo, l'applicazione riceve sempre prima il messaggio con il numero di sequenza inferiore. Service Broker usa inoltre il numero di sequenza dei messaggi per rilevare i messaggi duplicati. Quando il livello di protocollo del dialogo riceve due messaggi sullo stesso dialogo con lo stesso numero di sequenza, il livello del protocollo del dialogo considera i messaggi duplicati e ne elimina uno.

Service Broker usa i messaggi non in sequenza per messaggi di acknowledgment dedicati e messaggi di errore generati da Service Broker. Service Broker non prende particolari precauzioni per recapitare un messaggio non in sequenza. Si noti, tuttavia, che Service Broker crea messaggi non in sequenza in risposta ai messaggi in arrivo. Pertanto, se il messaggio non accodato viene perso, il mittente ritenta il messaggio originale; il destinatario genera quindi un altro messaggio non accodato.

Frammentazione dei messaggi

Service Broker suddivide in frammenti i messaggi in uscita e combina i frammenti in arrivo nel messaggio originale. Per i messaggi di piccole dimensioni, l'intero messaggio è contenuto in un frammento. mentre quelli di grandi dimensioni vengono suddivisi da Service Broker in numerosi frammenti.

La frammentazione dei messaggi presenta diversi vantaggi. L'invio di un messaggio di grandi dimensioni in frammenti di piccole dimensioni migliora la velocità e l'affidabilità complessive durante la comunicazione su reti relativamente lente e inaffidabili, ad esempio reti WAN (Wide Area Network). Se un frammento del messaggio viene perso, il protocollo ritrasmette un solo frammento anziché il messaggio completo. La suddivisione in frammenti dei messaggi di grandi dimensioni può anche ridurre il tempo necessario a un messaggio di piccole dimensioni per raggiungere la destinazione. Service Broker può inviare un frammento contenente un messaggio di piccole dimensioni completo tra frammenti di un messaggio di grandi dimensioni. Ciò rallenta leggermente il messaggio di grandi dimensioni per ridurre il tempo di attesa della trasmissione del messaggio piccolo.

Mentre un messaggio viene riassemblato, il messaggio parziale viene archiviato nella coda di destinazione. Se la coda di destinazione non è disponibile, viene archiviata nella coda di trasmissione. Un messaggio parziale non può essere ricevuto da un'applicazione. La colonna status di un messaggio parziale è impostata su 2 (disabilitato). Questo valore viene usato anche per i messaggi ricevuti non in ordine.

Accettazione di un messaggio

Service Broker invia un acknowledgement per ogni messaggio ricevuto. Un acknowledgement può riguardare uno o più frammenti di messaggio. Se possibile, un acknowledgement viene incluso nell'intestazione di un altro messaggio inviato nella stessa conversazione. Se non vi sono altri messaggi pronti per l'invio, Service Broker restituisce un messaggio di acknowledgement dedicato. L'acknowledgement dei messaggi viene gestito interamente da Service Broker; un'applicazione che usa Service Broker non riceve questi messaggi.

Un mittente conserva frammenti di messaggio che il destinatario non ha riconosciuto. Se non viene ricevuto alcun messaggio di acknowledgement per un periodo di tempo definito dal sistema, il mittente invia nuovamente il frammento di messaggio. Se durante il periodo di attesa non viene ricevuto alcun messaggio di acknowledgement, Service Broker aumenta in modo esponenziale il tempo di attesa prima del tentativo successivo, fino a raggiungere un limite massimo. Il tempo di attesa iniziale per un nuovo tentativo è di alcuni secondi. Il tempo di attesa massimo è di circa un minuto. Si noti che il tempo di attesa non deve necessariamente essere preciso. È infatti possibile che, in funzione del traffico di rete e di altre attività nell'istanza di SQL Server, un nuovo tentativo di invio di un frammento di messaggio venga prorogato di alcuni secondi dopo la scadenza del tempo di attesa.

In caso di perdita o di ritardo di un acknowledgement, il destinatario può ricevere messaggi duplicati. In questo caso, il destinatario riconosce il messaggio duplicato, ma non lo recapita alla coda.

Service Broker utilizza l'acknowledgement dei messaggi per garantire l'affidabilità della messaggistica senza transazioni distribuite. Un destinatario invia un acknowledgement solo dopo aver aggiunto il messaggio o il frammento alla coda. Il mittente mantiene il messaggio nella coda di trasmissione finché non riceve il relativo acknowledgement. Anche se il mittente e il destinatario non condividono mai una transazione, il protocollo garantisce che il mittente non rimuova il messaggio dalla coda di trasmissione fino a quando il destinatario non lo ha ricevuto correttamente.

Controllo dell'integrità dei messaggi

Il formato utilizzato da Service Broker per la trasmissione dei messaggi include un controllo dell'integrità dei messaggi per stabilire se un determinato messaggio sia stato alterato o danneggiato durante il trasporto.

Il controllo dell'integrità dei messaggi è una firma MD5 per il contenuto del messaggio. SQL Server crittografa la firma con la chiave della sessione per il messaggio e include la firma nelle intestazioni del messaggio.

La destinazione del messaggio decrittografa il messaggio e quindi confronta la firma nel messaggio con una nuova firma calcolata rispetto al contenuto effettivo ricevuto. Se le firme non corrispondono, significa che il messaggio è stato danneggiato o manomesso durante la trasmissione. Il messaggio non supera il controllo dell'integrità dei messaggi. SQL Server rimuove il messaggio e non invia un acknowledgement al mittente. Quando un messaggio non supera il controllo dell'integrità dei messaggi, le relative informazioni vengono riportate nella classe di evento Broker:Corrupted Message.

Oggetti di trasmissione di Service Broker

Un oggetto di trasmissione di Service Broker è un oggetto in memoria che gestisce e registra lo stato delle trasmissioni dei messaggi per un dialogo. Ogni endpoint di conversazione ha un oggetto di trasmissione.

Una interazione richiede un oggetto di trasmissione quando esegue le operazioni seguenti:

• Invia un messaggio tramite la coda di trasmissione. È incluso quanto segue:

  • Tutti i messaggi inviati a un'istanza remota del motore di database

  • Messaggi alle code inviate nell'istanza locale se il messaggio non può essere inserito direttamente nella coda di destinazione

• Riceve un messaggio remoto o un messaggio proveniente da una coda di trasmissione locale.

Un oggetto di trasmissione viene creato la prima volta che un dialogo ne richiede uno. Service Broker usa lo stesso oggetto di trasmissione per le richieste successive di tale dialogo. Gli oggetti di trasmissione vengono modificati ogni volta che Service Broker deve registrare una modifica nello stato delle trasmissioni per il dialogo. Gli oggetti di trasmissione sono di circa 1 KB.

Per liberare memoria, Service Broker archivia periodicamente batch di oggetti di trasmissione inattivi nelle tabelle di lavoro tempdb. Quando un oggetto di trasmissione viene modificato per la prima volta in memoria, viene contrassegnato come dirty, ovvero modificato ma non salvato. L'oggetto di trasmissione rimane contrassegnato come dirty fino a quando non viene scaricato in una tabella di lavoro.

Gli oggetti di trasmissione non vengono utilizzati per l'invio o la ricezione di messaggi locali che possono essere inseriti direttamente nella coda di destinazione.

Flusso di comunicazione di rete

Nella figura seguente viene illustrata una vista di alto livello delle comunicazioni di rete di Service Broker tra due istanze di SQL Server.

Si noti che la conversazione è una connessione logica persistente. La conversazione può verificarsi in qualsiasi periodo di tempo e, durante tale periodo di tempo, può usare qualsiasi numero di connessioni di rete.

Tra due endpoint di Service Broker vengono stabilite connessioni di rete Queste connessioni usano TCP/IP. In caso di inattività della connessione per un breve intervallo di tempo, SQL Server chiude la connessione di rete.

Per recapitare un messaggio, Service Broker lo mantiene nella coda di trasmissione per il database che l'ha inviato. Il destinatario recapita il messaggio direttamente alla coda per il servizio di destinazione. Se la coda è OFF, il messaggio viene mantenuto temporaneamente nella coda di trasmissione per il database ricevente. La coda per il servizio di invio non è interessata dall'operazione. La coda di trasmissione per il database che ospita il servizio ricevente è interessata solo se la coda di destinazione è OFF.

Vedi anche

• Routing di Service Broker