Ricerca di endpoint

I programmi server sono in ascolto degli endpoint per le richieste client. La sintassi della stringa dell'endpoint dipende dalla sequenza di protocollo usata. Ad esempio, l'endpoint per TCP/IP è un numero di porta e la sintassi dell'endpoint per named pipe è un nome di pipe valido.

Esistono due tipi di endpoint: noti e dinamici. La scelta del tipo di endpoint usato dal programma determina se l'applicazione distribuita o la libreria di runtime specifica l'endpoint.

Questa sezione illustra gli endpoint e presenta informazioni su come trovarle. È organizzato negli argomenti seguenti:

• Uso di endpoint Well-Known
• Uso di endpoint dinamici
• Esportazione di endpoint Well-Known nel database di mapping degli endpoint

Nota

I termini endpoint statici ed endpoint noti sono equivalenti e usati in modo intercambiabile.

 

È possibile che l'applicazione client usi la mappa endpoint per determinare se un programma server è attualmente in esecuzione. Il client può chiamare RpcMgmtInqIfIds, RpcMgmtEpEltInqBegin e RpcMgmtEpEltInqDone per verificare se il server ha registrato l'interfaccia specifica richiesta nella mappa endpoint.

Uso di endpoint noti

Gli endpoint noti sono endpoint pre-assegnati che il programma server usa ogni volta che viene eseguito. Poiché il server rimane sempre in ascolto di tale endpoint specifico, il client tenta sempre di connettersi. Gli endpoint noti vengono in genere assegnati dall'autorità responsabile del protocollo di trasporto. Poiché i computer host server hanno un numero limitato di endpoint disponibili, gli sviluppatori di applicazioni sono fortemente sconsigliati di usare endpoint noti. Un altro vantaggio degli endpoint dinamici è che semplificano la gestione e la manutenzione a lungo termine del sistema.

Un'applicazione distribuita può specificare un endpoint noto in una stringa e passare tale stringa come parametro alla funzione RpcServerUseProtseqEp. In alternativa, la stringa dell'endpoint può essere visualizzata nell'intestazione dell'interfaccia file IDL come parte dell'attributo dell'interfaccia [ endpoint].

È possibile usare due approcci per implementare l'endpoint noto:

• Specificare tutte le informazioni in un'associazione di stringhe
• Archiviare l'endpoint noto nel database del servizio dei nomi

È possibile scrivere tutte le informazioni necessarie per stabilire un'associazione in un'applicazione distribuita durante lo sviluppo. Il client può specificare l'endpoint noto direttamente in una stringa, chiamare RpcStringBindingCompose per creare una stringa contenente tutte le informazioni di associazione e fornire questa stringa alla funzione RpcBindingFromStringBinding per ottenere un handle. Il client e il server possono essere hardcoded per usare un endpoint noto o scritti in modo che le informazioni sull'endpoint provenga dalla riga di comando, da un file di dati, da un file di configurazione o dal file IDL.

L'applicazione client può anche eseguire query su un database del servizio dei nomi per ottenere informazioni sull'endpoint note.

Uso di endpoint dinamici

Il numero di endpoint per un determinato server e una particolare sequenza di protocollo sono in genere limitati. Ad esempio, quando si usa la sequenza di protocollo ncacn_ip_tcp , che indica che la comunicazione di rete RPC avviene tramite TCP/IP, sono disponibili solo un numero limitato di porte (la maggior parte dei sistemi ha solo l'intervallo da 1025 a 5000 aperto). Le librerie di runtime RPC consentono di assegnare gli endpoint in modo dinamico, in base alle esigenze. Poiché il numero di UUID di interfaccia possibili è praticamente illimitato, l'uso dell'UUID dell'interfaccia per indirizzare la chiamata offre più spazio per l'espansione e maggiore flessibilità.

Per impostazione predefinita, le funzioni della libreria di runtime RPC cercano informazioni sull'endpoint quando eseguono query su un database del servizio dei nomi. Se l'endpoint è dinamico, il database del servizio dei nomi non conterrà informazioni sull'endpoint. Tuttavia, la query assegna al programma client il nome di un server. Può quindi cercare la mappa endpoint del server.

Se il client deve effettuare una chiamata di procedura remota usando un endpoint dinamico, il metodo preferito consiste nell'effettuare la chiamata su un handle di associazione parzialmente associato. Il runtime RPC risolve l'endpoint in modo trasparente. Questo metodo è superiore all'uso della funzione RpcEpResolveBinding , in quanto consente meccanismi di memorizzazione nella cache avanzati nel runtime RPC.

Se è necessario un controllo più specifico sulla selezione dell'endpoint, i client possono cercare nella mappa degli endpoint una voce alla volta chiamando le funzioni RpcMgmtEpEltInqBegin, RpcMgmtEpEltInqNext e RpcMgmtEpEltInqDone .

Esportazione di endpoint noti nel database di mapping degli endpoint

È possibile combinare i due approcci per trovare gli endpoint, soprattutto quando un sistema distribuito passa da un modello endpoint noto a un modello di endpoint dinamico. In tali transizioni, una versione intermedia del server userà un endpoint noto, ma registrerà anche l'endpoint noto con il database di mapping degli endpoint. Questo approccio consente ai client che usano endpoint e client noti che usano un endpoint dinamico per connettersi. Dopo l'aggiornamento di tutti i server, è possibile distribuire una nuova versione client che usa solo endpoint dinamici. Dopo l'aggiornamento di tutti i client, una versione finale del server può smettere di usare endpoint noti e iniziare a usare solo endpoint dinamici.

Questo approccio consente un percorso di transizione per le applicazioni che hanno iniziato con un endpoint noto, ma vogliono eseguire la migrazione a un endpoint dinamico senza richiedere un aggiornamento simultaneo di tutti i server e client.