Prevenzione dei blocchi lato client

Esistono due modi in cui il client può bloccarsi: la connettività di rete può causare la perdita delle richieste del server o l'arresto anomalo del server stesso. Con le opzioni predefinite, RPC non eseguirà mai il timeout di una chiamata e il thread client attenderà per sempre una risposta.

Esistono due metodi per evitare questo problema: mantenere vivi e timeout.

TCP Keep Alives

Il client può essere configurato per eseguire periodicamente il ping del server per assicurarsi che il server sia attivo ed in esecuzione. I ping sono keep-alive TCP per le sequenze di protocolli di ncacn_ip_tcp e di ncacn_http e, di conseguenza, sono efficienti nell'utilizzo della CPU e nella larghezza di banda di rete. Per abilitare mantenere attivi in una determinata chiamata di procedura remota, usare la funzione RpcMgmtSetComTimeout prima dell'avvio della chiamata. Questa funzione accetta un handle di associazione e un timeout come argomenti. Ogni chiamata di procedura remota su questo handle di associazione dopo rpcMgmtSetComTimeout usa il timeout fornito.

Il parametro Timeout per la funzione RpcMgmtSetComTimeout specifica la durata dell'attesa del tempo di esecuzione RPC prima di attivarla. Il timeout è un valore compreso tra 0 e 10, dove 0 è il timeout minimo e 10 è timeout infinito (nessun timeout). Il timeout stesso non è in secondi; la traduzione dal valore di timeout fornito alla funzione RpcMgmtSetComTimeout viene eseguita in secondi dal tempo di esecuzione RPC ed è specifica dell'implementazione.

La tabella seguente fornisce la traduzione in secondi per Windows 2000 e Windows XP. Le versioni future di Windows possono modificare il mapping tra il parametro Timeout e il valore di timeout in secondi:

Parametro timeout	Timeout effettivo in secondi
0 (RPC_C_BINDING_MIN_TIMEOUT)	120
1	240
2	360
3	480
4	600
5 (RPC_C_BINDING_DEFAULT_TIMEOUT)	720
6	840
7	960
8	1080
9 (RPC_C_BINDING_MAX_TIMEOUT)	1200
10 (RPC_C_BINDING_INFINITE_TIMEOUT)	Timeout infinito

 

Dopo l'attivazione dei valori attivi, il client invia un pacchetto attivo ogni secondo. Se non è presente alcun riconoscimento dal server per tre o più mantieni attivo, il client dichiara la connessione non attiva e non riesce la chiamata di procedura remota. Se il server invia una risposta entro il timeout specificato, non verranno attivati i dati attivi. Se il server risponde a mantenere attivo, ma non risponde alla chiamata alla procedura remota, il client continua a inviare mantieni attivo. Una volta che il server risponde alla chiamata RPC, i keep alive vengono disattivati. Per Windows 2000, mantenere attivi vengono attivati solo per le chiamate RPC sincrone. Per Windows XP, mantenere attivi vengono attivati anche per le chiamate RPC asincrone.

Si sta tentando di impostare mantieni attivi al valore più basso per garantire che l'applicazione client risponda ai problemi di rete in modo tempestivo. Un'attenta considerazione deve essere data a tale tentazione e esame applicato al fatto che un valore aggressivo sia garantito. Un server che perde temporaneamente la connettività può trovarsi inondato con mantenere vivi da numerosi client una volta ripristinata la connettività. Inoltre, le attività di calcolo lunghe possono richiedere più di due minuti e il server può trovare più tempo per rispondere alla CPU rispetto all'esecuzione di operazioni utili. Pertanto, mantenere i vivi deve essere usato con moderazione. Se il client non può tollerare il thread collegato per periodi lunghi, deve essere considerato RPC asincrono.

Altre sequenze di protocolli possono implementare meccanismi diversi per rilevare server non rispondenti, a seconda del trasporto usato. Il trasporto ncalrpc non usa mantieni vivi. Poiché tutte le comunicazioni in ncalrpc sono locali, se il server diventa non risponde mentre una chiamata è in corso, l'ora di esecuzione RPC nel client ha esito negativo immediatamente.

Timeout delle chiamate

Se la connettività di rete viene persa o se il server si arresta in modo anomalo, il protocollo TCP mantiene attivo. Tuttavia, se il server deadlock viene eseguito in modalità utente, TCP mantiene i valori attivi restituiti correttamente, ma la chiamata non restituirà mai. Per gestire questo scenario, è stata aggiunta una nuova opzione di runtime per Windows XP: RPC_C_OPT_CALL_TIMEOUT. Questa opzione indica l'ora di esecuzione RPC per configurare un timer ogni volta che invia una richiesta al server. Se il timer scade, la chiamata viene annullata automaticamente e viene completata con RPC_S_CALL_CANCELLED. Purché il server risponda entro il limite di tempo specificato, il client non annulla la chiamata. Ciò significa che una chiamata multifragment può richiedere più del periodo di timeout da completare, poiché ogni risposta dal server viene ricevuta entro il periodo di timeout, anche se il periodo di tempo per tutte le risposte arrivava era maggiore del periodo di timeout.

Inoltre, quando una chiamata viene annullata, il server non riceve una notifica dell'annullamento. Il server, pertanto, eseguirà probabilmente la chiamata in un certo momento e il client ignora semplicemente la risposta dal server.

L'errore più pericoloso con i timeout delle chiamate sta creando un timeout breve e riprovare la chiamata nello stesso server. Lo scenario seguente illustra i pericoli di questo approccio:

Si supponga che un server che opera vicino alla capacità. Ha un numero di client con timeout molto breve, ad esempio cinque secondi. Una perdita temporanea della connettività di rete o della congestione in un router causa una scadenza nelle risposte del server per alcuni secondi. Nelle reti Ethernet questa situazione può essere facilmente causata da un burst di attività su un collegamento condiviso dal server con un altro computer. Il server non riesce a inviare tutte le risposte prima del timeout di cinque secondi. I client ricevono le chiamate annullate e riprovano immediatamente. Il server non è a conoscenza delle chiamate e li esegue anche. Pertanto, invece di eseguire il carico di lavoro normale delle chiamate, esegue 30-50% più chiamate, a seconda del numero di client timeout. Se supera la capacità e il server non può rispondere a tutti i client entro cinque secondi, un altro round di chiamate viene inviato al server. I client continuano a riemettere le stesse chiamate e poiché il server esegue l'overload delle chiamate precedenti, non è in grado di rispondere entro il timeout. Dopo aver risposto, i client hanno raggiunto il timeout, emesso una nuova chiamata e rimosso la risposta. In uno scenario peggiore, il server non verrà ripristinato fino al riavvio e, a seconda del modello di accesso client, potrebbe non essere ripristinato fino a quando non viene arrestato un numero sufficiente di client.

Nota

Il timeout delle chiamate funziona solo nelle sequenze di protocollo ncacn_ip_tcp e ncacn_http .